The CMS of the Future, Part II

Part II: Where the Website Ends

In part one of this piece, I covered some characteristics that the CMS of the future will need to do under three headings: enforced structure at the core, accurately focus AI and automation, and treat accessibility as infrastructure. In one fashion or another, all of these point to structured content as a foundational requirement, including structured metadata. To conclude that thread, we can weave a few more observations together to get a fuller picture, including the state of the content, its destination, and who controls access to it. With those in hand, we’ll grab some lessons from a mini case study of what is likely the most significant new CMS to appear as a greenfield project in the past decade before we can wrap up our list of requirements for the CMS of the future.

Your Content has a Half-Life

Any seasoned freelancer will tell you that getting content from a client is the most likely phase to delay or entirely scuttle a web project. They might tell you to use what’s on the old site, but when pressed, it comes out that they no longer offer two of the five services they feature, and one of the people on the staff page died four years ago, not long before they dropped the fax line shown on their contact page, and although they boast of being in business for “almost 15 years,” this is in fact their 25th anniversary. All of those are easy to catch. What’s harder to spot is arguably even more important.

As Olivier Dobberkau recently wrote, “Your content is not out of date. It has drifted.” He describes two helpful measures for evaluating your content:

• Salience asks how likely a piece of content is to answer a question somebody is asking today.
• Buoyancy asks how well that value holds over time.

He then introduces another concept:

• Drift is “the state where the world has changed and the content has not, where the page is still accurate in its own terms but no longer describes the thing it claims to describe.”

Salience and buoyancy are discoverable and measurable, but he notes that reliably detecting drift is “genuinely unsolved,” because while your CMS knows when it was last touched, it doesn’t know whether the content is still true. At the same time, AI agents can be consuming it and reporting it authoritatively in your name.

From an SEO perspective, Carolyn Shelby’s explanation for “Why Publishing More Content Is Making Your SEO Worse” is relevant here. While sprawling, repetitive, even low-quality content used to impress the search engines, it’s not very compelling to the AI agents that retrieve it.

The retrieval layer rewards clarity, consolidation, and semantic precision. It does not reward sprawling redundancy. That means the old “publish more” playbook can now create structural problems that actively weaken visibility.

She describes semantic dilution, calling out the misconception that more topical coverage strengthens authority for AI search with the opposite truth: “over-publishing weakens semantic precision."

Content dilution and drift are different failure modes, both reflecting a CMS whose editorial history can tells you nothing about the current “truthiness” of the content. As it turns out, content has a half-life, and detecting it is tricky, because as Olivier Dobberkau puts it, “Drift is not the same as being old.”

Where Does the Website End?

Returning to Mathias Bolt Lesniak’s piece, he calls for the loosening of ties to the website as sole destination for the content being managed, giving the example of kiosks, transit displays, and museum installations. An example from some of our own deployments is rec center event listings and room assignments displayed in common areas, repurposing the same content for different contexts.¹

In “The future of the website”, Joost de Valk suggests (spoiler: “Not dead. Not even close.”) the website’s role becomes an “interface bundle” with a human-orientated UI plus an MCP server at minimum. With more conversions happening off-site “in AI answers, in chat interfaces, in agent-mediated transactions”, the website

becomes the canonical source of truth about your business: the system of record that feeds every surface where the actual decision gets made. If an AI assistant recommends you, it’s because your home base gave it every reason to. Thin, stale, machine-hostile websites simply won’t be recommended.

To illustrate how his own site is being consumed, an earlier question Joost asked, “What’s a visitor in the age of AI?”, includes numbers: 536 AI-bot fetches against 254 human visitors in 24 hours. The inference here would be that his content is being consumed for use off-site, for any number of purposes that would still recognize his site as the canonical source of the material. Confirming the trend, his just-released AI Outlook for Q3-2026 gives the statistic: as of June 2026, 57.5% of web traffic is not human.²

Jono Alderson supplies a third perspective: “One website, one CMS”, saying the issue isn’t about where the website’s boundary sits, it’s the danger of fragmenting its content across multiple disconnected CMSs. His sequel, “Fragmentation is not reach”, highlights the importance of authoritative indexing when he sharpens his thesis for agents specifically: “you cannot be the third service an agent chooses when it only needs one.”

Governance, Sovereignty, & The Bill Nobody Itemizes

I’ve said that “Open Source is Not Enough”, a response to Joost de Valk’s post and Karim Marucchi’s followup about how open source projects could be funded with private equity if it was done with the right structures. This serves as added context for his keynote, where he warns that PE-backing of an open source project doesn’t automatically make it safer than a commercial vendor. This brings us to the subject of governance.

It’s true that an open source license can help avoid vendor-lock, but only if you’re willing to accept the burden of future code maintenance. David Steeb’s earlier article on building ecosystems raises the caution, saying the project’s governance model matters more than the software license. His notes from Atlanta pick up on the impact of the EU’s Cyber-Resilience Act (CRA) as well as AI Act and Accessibility Act compliance on open source projects,³ indicating that how those are handled by the project will matter greatly to site owners. Vendor-lock fits in here as an additional caution, since it will bind you to whatever governance you’re working under for as long as the switching costs can keep you there.

In selecting a CMS, the combination of governance, project structure, and funding model can quickly become more important than its out-of-the-box feature set, and yes, even more than the license. After all, the license is selected and managed within the role of project governance. It’s the first item Karim listed in his five-point checklist for a sustainable content ecosystem: “Governance — Who decides the roadmap, and who can’t sell it out from under you.” With a different nuance from selling the project, Joost de Valk asks bluntly, “Who can cut you off?” in his post declaring that stewarded open source is not enough, in response to Dries Buytaert’s License-only versus Stewarded Open Source.

As for what open source governance can look like, there is a very wide range of models and nuances between them, with many a cautionary tale to tell. I’ve looked at the whole survey, but model I’ve been introduced to over the past year and the one that continues to impress me is TYPO3’s. Apart from any technical or other criteria, the governance model itself is worth not just studying, but emulating. On that point, a recent interview with Daniel Fau addresses “TYPO3’s Unique Structure and Global Expansion in Open Source CMS” with an overview of TYPO3 governance and how it differs from other open source projects to consciously foster a strong layer of trust and resilience for the platform. The TYPO3 model addresses not only traditional governance concerns, but also stable ongoing project funding.

While I was writing this post, Automattic’s board put founder and CEO Matt Mullenweg on paid leave and appointed CFO Mark Davies as interim CEO, giving Matt less than an hour’s notice. The governance of the WordPress project itself is technically separate from that of Automattic as a corporation, but historically Mullenweg has run both, often making them appear synonymous, and the futures of both are bound together. Roger Montti’s piece on the WordPress co-founder being ousted as CEO highlights a declining share of the CMS market before concluding that this comes during “a painful slow-motion decline of the WordPress plugin ecosystem where many plugin developers are seeing their paid user base declining and an increase in the discovery of vulnerabilities, both due to AI.” The next day, Mullenweg was apparently back as CEO, after talking about moving his “stuff” off of Automattic servers, swearing, calling himself a pirate, posting around social media, and announcing he’s buying a boat. (CMSWire has a good in-depth piece on the ousting, with background, with a brief followup on the reinstatement.) On X, Mullenweg posted, “Founder advice: If you don’t have a coup attempt every few years, you’re not hiring strong enough leaders. I think this was my fifth.” In the context of governance, a lack of stability undermines all of it, so it’s not something to be proud of.⁴ This brings us back to Joost’s post on stewardship, governance, and sovereignty. He not only provides a set of test-questions for accountable stewardship, he specifically calls out WordPress as the cautionary tale.

Is EmDash Building the Future Now?

On April 1st, 2026, Cloudflare announced the launch of EmDash, a new CMS it dubbed the “spiritual successor” to WordPress, with a plugin-sandboxing pitch that reveals a different, nearly opposite, approach to plugin security. Despite the date, it was no joke. Joost de Valk called it “a CMS built for 2026” because of its design philosophy. He explains:

Content is stored as portable text — structured JSON, not HTML strings — which means an agent can read, modify, and generate content without parsing markup. Custom content types get their own database tables with typed fields, so an agent can reason about the schema programmatically. There’s an MCP server for direct CMS interaction, a CLI that outputs JSON, and documentation specifically structured for AI consumption.

He makes a sharp distinction when he calls it “agent-native, not agent-compatible”.

CMSWire’s “Meet EmDash, the Cloudflare CMS and WordPress ‘Spiritual Successor’” by Dom Nicastro offers thorough coverage of the release, including Matt Mullenweg’s reaction — or both of them, his objection and his praise of the Agent Skills documentation. In addition to quoting Joost’s comment that EmDash is “the most interesting thing to happen to content management in years,” he quotes a couple of insightful LinkedIn posts by James Gibbons and Dan Hinckley.

Gibbons framed his comments as “5 Architectural Decisions in Cloudflare’s EmDash That Tell You Where Content Infrastructure Is Heading”, calling x402 micropayments a sleeper feature and portable text an “underrated decision”, which he explains by comparing it to Gutenberg:

an AI agent consuming Portable Text gets typed, queryable data it can reason about. An agent consuming Gutenberg content still has to parse HTML to extract the structured attributes buried inside it. Same insight behind materialized data lakes vs. runtime API queries. Content born structured compounds in value. Content that requires extraction to become structured creates a parsing tax for every downstream consumer.

Earlier I referred to “text-on-page” in contrast to structured content; Gibbons explains the cost. “Content that requires extraction to become structured creates a parsing tax for every downstream consumer.” His bottom line: “EmDash made every correct architectural decision.”

Meanwhile, Dan Hinckley says, “For GEO, it’s the first CMS where AI agent accessibility is a first-class feature.” Along with other features already mentioned, he calls out “Structured JSON content, not HTML blobs.” and “Custom content types as real SQL tables, not crammed into wp_posts.”

The upshot is that EmDash is showing a lot of astute architectural decisions in its design, many enable by the fact that it started without needing to offer legacy support for anything. Its downside is an ecosystem that also starts from scratch, empty, something every reaction post points out. It also relies heavily on Cloudflare’s edge runtime infrastructure for hosting it, something Mullenweg calls out as lock-in, saying, “If you want to adopt a CMS that will work seamlessly with Cloudflare and make it hard for you to ever switch vendors, EmDash is an incredible choice.”

To be fair, the week after an initial launch is a bit early to complain about planned things that aren’t there yet. EmDash launched with native support for Jamstack deployments from providers like Vercel and netlify, and portability is a stated priority. It only took six weeks for WPMU DEV to start offering it, and other options are available as well. On the empty ecosystem side, there is an EmDash marketplace now. A decentralized plugin registry was in discussion just three weeks after EmDash launched, where I did some work alongside Matt Kane (of Cloudflare, EmDash, and Astro) to bring the architecture of EmDash’s Registry RFC and the FAIR Protocol into closer alignment to enable compatibility between them. True, EmDash doesn’t have the ecosystem that WordPress has — but nobody does, and there’s evidence that it’s shrinking. All that said, the governance structure for the EmDash project isn’t fully clear yet, and ultimately it’s still a Cloudflare-sponsored project.

EmDash may or may not be the CMS of the future, but it’s certainly designed to be a CMS of the future, with fundamentally different design principles than most CMSs of the past.

Envisioning the CMS of the Future

We can now pick up from the first three items in the list we began in part one to wrap up our requirements for the CMS of the future. Since we’re adding non-technical criteria now, It’s worth saying explicitly that the list items are not intended to be equally-weighted in their importance.

4. Content Lifecycle

• Tracks whether content has drifted from the world it describes, not just when it was last edited.⁵ “Last modified” and “still gets traffic” are the only signals most CMSs can surface, but neither indicates whether a page is still true. This remains an unsolved problem, which makes it an interesting one with a high value on its resolution.
• Approximates measures like salience and buoyancy as ongoing, queryable signals.⁶ These need to be surfaced routinely rather than as a one-time audit. Given an extensive corpus, an full content audit may be outdated before being completed. Drift detection must therefore not be left to a periodic project.
• Feeds drift signals into review and republishing workflows.⁷ Given how many requirements already put governance and workflow at the center of the future CMS, drift detection becomes a natural extension of that machinery to actively surface and drift signals from within the CMS rather than from a separate tool or process.

5. Distribution & Reach

• Stops assuming the website is the only destination for content.⁸ For use beyond the browser in kiosks, transit displays, museum installations, and all manner of whatever comes next, content needs to be channel-agnostic from the data model up, not adapted from the web page as primary with everything else exported as an afterthought.
• Ships as a bundle of interfaces, not just a website.⁹ Human UI plus machine-readable endpoints like an MCP server and structured API generated from the same canonical content layer, not a parallel system that can drift out of sync to die with AMP and m-dot sites.
• Treats files and documents as first-class content.¹⁰ Both have their own structure, lifecycle, and rights tracking that live independently, not as a stepchild of the page model. This may not need to replace a dedicated DAM at scale, but the architectural line between “content” and “file attachment” shouldn’t matter.
• Has a native answer for how publishers get paid when agents do most of the reading.¹¹ EmDash’s built-in support for per-request micropayments is one design for this need, where an agent requests content, gets a price, pays, and gains authorized access with no subscription infrastructure required. It doesn’t need to use this specific mechanism, but the underlying problem won’t be solved by better structure alone: something needs to replace the advertising and subscription-funded models that assumed a human was clicking on a page.

6. Governance

• Operates under governance that can’t be quietly sold out from under you.¹² Protections beyond just an open-source license need to exist, including funding and ownership structures (foundation-owned, cooperatives, or other insulating legal structures) that a buyer can actually conduct due diligence on in a structural form, not just a badge or tick-box. The same scrutiny needs to extend to infrastructure lock-in, not just corporate ownership. Features dropping out with a platform switch trade one vendor-lock for another, even with a permissive license on the code itself.
• Commits to a support runway measured in years and published in advance.¹³ CFOs and CTOs need to be able to plan and budget upgrade cycles instead of guessing at vendor whims, so predictability becomes a procurement criterion.

7. Adoption Path

• Is composable around a single coherent model.¹⁴ The CMS can’t be fragmented across several disconnected systems even if they happen to sit on the same domain. Plugging in a DAM, a search engine, or an AI tool is acceptable, but letting each department stand up its own CMS for the same content domain is a failure mode.
• Is adopted through augmentation, not rip-and-replace.¹⁵ Realistic ETL and migration tooling, genuine coexistence with an incumbent system, and the ability to prove value on one slice of friction before committing to a full swap is table stakes for actually getting selected. Gradual progressive migrations will win out over monolithic conversions that don’t surface issues until the deed is done.

What Goes on the Tombstone?

Back to where this started. Something died, and AI didn’t really kill it so much as it made the body impossible to keep ignoring. What’s replacing it isn’t a feature checklist, but a much more difficult set of questions:

• Is your content actually structured, or just formatted to look like it is?
• Does the project governance survive contact with a board vote?
• If an agent instead of a person shows up asking for your content, does your CMS know how to answer?

EmDash is a real attempt at the first and third. Whether anyone — including WordPress, this past week, playing out in real time — has a good answer to the second is still very much unsettled. For what it’s worth, I did make reference to a governance model in use by one CMS that I think is one of the strongest in all of open source. Anyone wanting to create the CMS of the future needs to start with the foundations: governance and architectural structure, and both of those are extremely difficult to back-port. What died is very likely a concept of the CMS that no longer passes muster, one that’s simply becoming the Ghost of CMS Past, if you will.

Notes

1. Also recall the unawarded RFP from earlier: failing to imagine different uses of the same canonical source content dooms you to “managing” it multiple times, with more work for a worse result.↩
2. This happened quickly. Remember the gradual climb for mobile page views to overcome desktop views?↩
3. Also catch the mention of the FAIR project’s work on federated/verified distribution to address the same trust issues at the supply chain layer.↩
4. I served for a while on a dysfunctional board once, and by my observation, there’s not much that will hamstring a company’s ability to make good decisions and move strategically more than board dysfunction.↩
5. Olivier Dobberkau, “Your content is not out of date. It has drifted.” LinkedIn.↩
6. Olivier Dobberkau, “Your content is not out of date. It has drifted.” LinkedIn.↩
7. Extrapolated from Olivier Dobberkau, “Your content is not out of date. It has drifted.” — he names the problem, this is the operational implication.↩
8. Mathias Bolt Lesniak, “The Website Builder Is Dead, Long Live Content Management,” TYPO3 News.↩
9. Joost de Valk, “The future of the website”↩
10. Mathias Bolt Lesniak, “The Website Builder Is Dead, Long Live Content Management,” TYPO3 News.↩
11. James Gibbons, “5 Architectural Decisions in Cloudflare’s EmDash That Tell You Where Content Infrastructure Is Heading,” LinkedIn; Joost de Valk, “The future of the website,” on conversion leaving the site.↩
12. Karim Marucchi, five-point checklist in “The CMS Quiet Years are Over,” TYPO3 News; David Steeb, “Stop Buying Platforms. Start Building Ecosystems.,” b13, on PE-backed open source; Matt Mullenweg’s own leave of absence, reported by TechCrunch, is the case in point.↩
13. David Steeb, “Notes from Atlanta,” b13, on TYPO3’s 18-month cycle and up to seven years of Extended Long-Term Support; Karim Marucchi, “The CMS Quiet Years are Over.”↩
14. Jono Alderson, “One website, one CMS” and “Fragmentation is not reach.”↩
15. Pat Ramsey, quoted in David Steeb’s “Not a Technology Problem,” b13 (“Soften the blow. Start with augmentation…”); Victoria Fleischer, “Inside the First TYPO3 North America Summit,” Crowd Favorite.↩