This is an open question for anyone who might have experience using Elements on a medium to large website. I am asking how this has worked for you.
My parameters:
The bulk of the content (300 pages) is 400–2000 words.
About 40 pages are 5000 words.
These are all going to be interlinked pretty heavily.
I would like to have a single photo on each page.
The reason I ask about Elements rather than the CMS is that Elements has the page database for me to reference in the drop-down to build the links with, rather than me referencing a hand-made list or visiting the website to grab the URL.
The ideal solution would be for the CMS to handle links better, perhaps one day.
Let’s put it this way: I think I currently have a relatively large website with around 1,500 pages, of which roughly 800 are still running on RW Classic and the rest have already been migrated to Elements.
The majority of the pages are populated exclusively through Markdown files for the content. That also includes the header and footer.
Since ECMS 1.0 wasn’t really optimal and there were especially issues with indexing (canonical issues), I had to manually create every page in Elements as well. That resulted in my project growing to almost 1.8 GB unzipped — although a large portion of that is probably resources such as images, logos, and similar assets.
Now, if you consider that in the future all resources can be managed and uploaded directly through the ECMS Editor, this should have a positive effect. The same applies to pages themselves. You no longer need to create a separate page in Elements for every Collection because the canonical issue has been fixed. So now only one page per Collection is needed.
Internal linking should also not be a problem. A lot depends on how you structure your frontmatter.
I also work heavily with internal linking through Markdown files — if you have specific ideas or requirements, let me know. I may be able to suggest a few possible approaches or solutions.
The downside of my “large” project is that saving and loading the project now takes almost 30 seconds. Publishing is also not always ideal, and the CPU usage becomes quite heavy when all files need to be republished. Of course, it’s understandable that this process takes some time with a project of this size.
Other than that, the project runs extremely stable despite its size, and the crash-to-work ratio is significantly better than it ever was under RW Classic.
May I burden you to ask what your workflow looks like for building internal links?
Currently have a list of 500+ page titles, page sub-titles and the slugs. These are all alphabetized. But this is a long list. I do have a tendency to use the search in my markdown editor to find the right one.
The Page Title → the-page-title
The Page Title/Sub Title → the-page-title#sub-title
Here is my interest in doing this in Elements. If upon some chance I change the name, intentionally or unintentionally, Elements will propagate the change throughout the doc get fixed on the next publish. Changing a link is not good for SEO but a broken link is arguably worse.
You’ll probably need to send me an example of your frontmatter so I can better understand what exactly you’re trying to link, where the links should point to, and how your overall structure is set up.
Here’s a small excerpt of one of my frontmatter setups. In principle, you can define pretty much any link target directly in the Markdown frontmatter and then output it dynamically later on.
My example, for instance, always outputs a Sunday in different date formats. After that, it includes the previous Sunday and the next Sunday, along with their corresponding URL paths.
And finally, it outputs the direct URL link for that specific Sunday.
I hope that makes sense to you and that you might be able to derive some ideas or approaches from it for your own setup.
I have not upgraded to the new version. I am reading the documentation and watching the videos trying to get a better idea of how the new version of the CMS works. From there I might be able to adjust my workflow to better accommodate what CMS 2 is capable of. Let me do more research.
Here is a way some other CMS’s handle links. Perhaps @dan or @ben might be able to give this some thought and consideration. I intentionally did not link this AI response about how to use the competitor’s product this was explaining. I am trying desperately to encourage the Elements CMS to meet this challenge.
Page-to-Page (External Links)
For linking to outside websites (e.g., [``https://google.com``](``https://google.com``)), Sanity uses a standard URL field.
The Editor Experience: The author highlights the text, clicks the link icon, and pastes the destination URL into a pop-up field.
The Data Structure: Sanity saves this as a standard link annotation containing a simple string variable for the URL.
2. Page-to-Page (Internal Links)
Linking to another page within your own website is where Sanity shines compared to a traditional WYSIWYG editor. Instead of asking the author to paste a hardcoded URL like /blog/my-first-post, Sanity uses a Reference Field.
The Editor Experience: When an author wants to link to an internal page, they click a custom “Internal Link” button. A search bar appears right inside the editor, allowing them to search through existing CMS documents (such as Articles, Pages, or Products) and select the exact item they want to reference.
The Major Advantage: This prevents broken links. If a developer later changes the URL slug of the targeted article from /blog/old-slug to /blog/new-slug, the link will not break. Because the text points directly to the underlying document ID rather than a hardcoded text path, the frontend automatically pulls the latest URL.
Deletion Protection: Sanity knows a document is linked inside an article. If a user tries to delete the target page, the CMS will warn them that another piece of content is currently referencing it, preventing accidental 404 errors.
3. On-Page Links (Anchor Links)
If you want to link to a specific section on the exact same page (e.g., jumping down to a specific subhead), you typically handle this by adding a custom field to your header blocks.
How it works: You can configure your heading blocks (H2, H3) to automatically generate or manually accept an ID string (slug).
Linking to it: The author can then use an internal link annotation to target that specific block, or use a standard link annotation with a hash identifier (e.g., #our-mission).
That’s a lot of AI generated waffle Probably would have been more succinct if you just wrote what you actually wanted.
What I think you want is a way for the online CMS/Markdown files to handle links the same way Elements does when linking pages. Is that right?
So… I’m also curious as to why you don’t use any of these other site builders that already do what you need? Why are you trying to get Elements to be the product you want?
I supplied that in case an alternate idea was needed. Bottom line, you interpreted what I needed well. Obviously, figuring out a specific post from a list of hundreds of pages can become a real issue if they all show up as a long dropdown list in the UI (which could happen with any blog over time; I assume this applies to the target market of Elements CMS.)
Now, on to your actual problem, I’m wondering if the MCP server in the new CMS will be able to help you with future linking updates, should the need arise…
If you changed a URL, and needed to update a bunch links in various markdown files, you could tell Claude or ChatGPT to go through your site and update them… this is a stop-gap solution or peace of mind if you do decide to use Elements to build your site.
We’re working all the time on improving Elements, making it more suitable for large documents sites is on our list to tackle, but when and in what form that will take I can’t say yet.
Well, at least you said it out loud. Having an attitude back is sometimes a hard pill to swallow. I am not very good at it myself. However, I am learning to read past the emotion and understand what is being asked or said. So that is the reason I am back here. I love the “idea” of Elements. I just happen to be pushing in areas that perhaps you don’t want to be pushed.
That’s a fair answer. So while I finish writing all this documentation—about 200,000 words in total—I will wait to see what develops with Elements.
Apparently, much to your chagrin. Have a good day and thank you answering.
Probably would have been more succinct if you just wrote what you actually wanted.
