---
title: "The CMS of the *Future*, Part I"
canonical: "https://toderash.net/blog/the-cms-of-the-future-part-i/"
pubDate: "2026-09-08T23:00:00.000Z"
description: "After 15 years of CMS architecture feeling settled, \"the CMS quiet years are over.\" AI has made the structural layer *beneath the content* not only matter again, but with increased importance. Across CMS ecosystems, it's becoming clear: content is the asset, structure makes it usable, and the presentation layer on top is disposable — to the point that many content-consumers will never even see it. Operating below the UI as a consumer of good structure, AI *depends* on this arrangement. AI is now reading the accessibility tree, and it breaks at the points where structure has always been lacking.
"
---

## Part I: Structure is the Advantage

::pullquote\[AI has been more *accelerator* than *innovator*.]I've been thinking a lot over the past few months about content management systems, and resonating with several posts and presentations over that time. I tend to gather threads like this, sometimes related directly and sometimes only tangentially, and weave them together to find the patterns. 2026 has been a transformative year in the CMS arena, and a lot of ink has been spilled on it already. It seems that something died, and maybe something killed it, but nobody seems to quite agree about the *what*, in either case. It's easy to wave your hand over the confusion and murmur something about AI, but from everything I've seen in the space, AI has been more *accelerator* than *innovator*.

All of this stopped being theoretical on April 1st, but we'll come back to that. I had a lot of take-aways from the TYPO3 North America Summit in May, so we'll start there.

## "The *CMS Quiet Years* Are Over."

![Karim Marucchi at a podium in front of a graphic with a title slide](/src/assets/media/Karim-Marucchi-CMS-Quiet-Years-Are-Over.jpg){.right}

**What's past is prologue**, as they say.:fn\["They" in this case beginning with William Shakespeare in *The Tempest*, Act 2, Scene 1.] In his opening keynote at the TYPO3 Summit in Atlanta, Karim Marucchi framed CMS history around three inflection points:

* 1995 — Beginning of the commercial CMS era.:fn\[I would note open source CMSs were gaining increasing influence from the early 2000s on.]
* 2010 — CMS category matures; with architecture settled, roadmaps stopped moving much.
* 2025 — Generative AI makes the layer underneath the content matter again.

The last half of those 30 years have treated CMS architecture as essentially "settled," a status that's now being revoked. "[The CMS Quiet Years are Over](https://news.typo3.com/article/the-cms-quiet-years-are-over)", he said, and offered a five-point checklist for a sustainable content ecosystem: governance, composability, AI-readiness, long-term support, and community.

David Steeb sums up the prescription from the talk, "[Stop Buying Platforms. Start Building Ecosystems.](https://b13.com/blog/stop-buying-platforms-start-building-ecosystems)" He's referring to the observation that composable architecture has gone from theoretical to table stakes, and enterprises need to stop thinking in terms of *platforms* — things you buy — and start thinking in *ecosystems* — foundations you build on and swap components within. Data ownership is a strong point here, since an enterprise whose data lives in vendor's silo can't build private, custom AI tooling that requires a unified source of truth.

::pullquote\[By the time you've integrated it, something else is worth chasing. *— Karim Marucchi*] Crowd Favorite's Victoria Fleischer [frames it as an architecture question](https://crowdfavorite.com/insights/inside-the-first-typo3-north-america-summit/) rather than a platform one. "The harder problem the room kept circling was tool sprawl. The list of new tooling keeps growing (MCPs, agents, skills, vector databases, private models), and integration takes months... Enterprises are spending the cycle deciding \[on tooling] instead of shipping."

What's being described here is the way stress fractures are appearing in the CMS models we've had for the past 15 years, kicking off new efforts to come up with a stronger one that addresses the future. So far, most CMS platforms are responding with bolt-on AI-powered features. Is that the right response, or is it based on a misdiagnosis that targets the symptom rather than the cause? The strain of AI is revealing the issues, but is it causing them?

Bill Bernbach famously said, "A great ad campaign will make a bad product fail faster." He could have said something very similar about AI. They're much the same — the effect of both is to highlight existing flaws and stress-test them at breakneck speed. AI is not the smoking gun here.

::pullquote\["It was an AI strategy in the same sense that repairing a leaking roof is a weather strategy." *— Carolyn Shelby*]Reviewing a basket of issues with AI-indexing of a website, Carolyn Shelby writes, "[Most AI visibility gains are just technical debt repayment](https://searchengineland.com/ai-visibility-gains-technical-debt-484755)", saying that AI didn't create new problems, it just stopped covering for the ones search engines used to compensate for. The company in her example called it an "AI Strategy," but as she points out, the remedies she describes fall squarely in the range of technical SEO. Essentially, this is simply the application of stronger fundamentals, but calling something new. Or, as she wryly puts it, "It was an AI strategy in the same sense that repairing a leaking roof is a weather strategy."

## Content is the Asset. *Structure is the Advantage.*

A lot of SMBs have a view of their website as an asset, a marketing tool. When the site has embedded functionality, from revenue-generating ecommerce or membership services to portal-style SaaS or account management, its value is sometimes viewed as being in its revenue-generation or business processes. What very few recognize is the value of its content as the asset itself. 25+ years ago, I advised clients that their sites should feature good content, which could help them create community, leading to commerce. At the time, few people opened their web browsers looking to plug in a credit card somewhere. Despite the shift to ubiquitous online commerce since then, at various times in the intervening years I've thought of those "Three C's," and how that advice never really went stale at any point. "It's the content, stupid" — and 'twas ever thus.

![Benni Mack at a podium in front of a graphic with a title slide](/src/assets/media/atl26-typo3-summit-benni-mack-480w.webp){.right}

Enter Benni Mack's insight: "[Content is the Asset. Visual is the Skin.](https://news.typo3.com/article/content-is-the-asset-visual-is-the-skin)" He describes the three-tier model of the Enterprise Content Management (ECM) philosophy:

* **Content** — *The Asset*

  Layer One: Factual, human-created content that requires time and expertise for development.
* **Content Design** — *The Architecture*

  Layer Two: The structure, meta schema, relationships and governance that create discoverability for content.
* **Visual Presentation** — *The Skin*

  Layer Three: The layout and design, the presentation element. While disposable and subject to iterations and redesigns, layer one and two must be treated as sacred and governable to ensure long-term value.

As I've framed the SMB viewpoint, the perceived value is in the skin, and the architecture is thought of as the website's functionality, a byproduct of not placing value in the content itself as an asset.

Benni outlines a cycle where organizations adopt flashy new platforms or approaches, treating their content as disposable. As a result, teams waste time on manual tasks, neglecting content architecture, perhaps spending months tagging metadata by hand because the CMS doesn't treat metadata as a foundational element. "It's what happens when a company treats content like a problem instead of an asset." In the better approach he describes, permissions are treated not just as a security feature, but an organizational design tool, with "software support that thinks in decades, not quarters."

### It Matters How you *Treat Your Content*.

"Own your content model, and your options stay open," writes David Steeb while making the case that "[AI-ready isn't a feature](https://b13.com/blog/ai-ready-isnt-a-feature)" to be listed, but a property of *structure*.

::pullquote\["AI is the new UI" *— Dries Buytaert*]This isn't a strictly TYPO3 observation. Dries Buytaert explains "[Why Drupal is built for the AI era](https://dri.es/why-drupal-is-built-for-the-ai-era)", makes same case, saying "Drupal accidentally prepared for AI" through architectural decisions made for Drupal 8 based on what new digital agencies needed. Calling AI "the new UI," he makes it a way for Drupal to be accessed by AI-driven workflows rather than attempting to make AI into a retro-fitted bolt-on feature. He concludes,

> The question isn't whether AI will change digital agencies and content management. It already has. The question is which platforms will help agencies and developers thrive in that new reality.

Dries also did an interview with Matthew Garrepy recently (CMS Critic, "[Hard? Hardly.](https://cmscritic.com/hard-hardly-drupal-cms-20-evolves-open-source-content-management-with-ai-visual-building-and-simplicity)") where he states it quite plainly:

> “The reason Drupal was seen as hard is because we have things like content modeling and content relationships and advanced content workflows... But now, in the age of AI, these weaknesses, they become incredible strengths – and I think that's pretty exciting for a project like Drupal.”

The lesson is that manually creating these types of structured content in an easily-manageable way can be a chore, but it's the kind of thing that AI will excel at as creator and consumer of the format, provided the underlying architecture supports it. For the WordPress ecosystem, Joost de Valk has said, "[If WordPress gets CPTs in Core, we also need custom fields](https://joost.blog/wordpress-custom-fields-in-core/)", since "a custom post type without custom fields is just a renamed post." And of course he's right — the postmeta from custom fields, not just custom taxonomies, is necessary for making it a properly-modeled content *type*, with structured meta, schema, and relationships.:fn\[Don't get me started on the database design of `wp_post` and `wp_postmeta`, which will make a seasoned DBA cry heavy, salty tears into their beer.]

![Pat Ramsey presenting at TYPO3 North America Summit](/src/assets/media/Pat_Ramsey_NA-Summit.webp){.right}

Pat Ramsey's TYPO3 Summit talk, "[TYPO3 vs. WordPress: Why Native Features Matter More Than Plugins](https://news.typo3.com/article/typo3-wordpress-na-summit)" gets to the same place from a different angle: native content modeling is a better approach than "plugin sprawl" that attempts to create something native-looking and foundational with a bolted-on piece of third-party software — or several add-ons, that likely don't use or enforce the same model. As David Steeb summarizes it in "[Not a Technology Problem—A WordPress Agency Looks at TYPO3](https://b13.com/blog/not-a-technology-problem)", what Pat is looking for is something the b13/TYPO3 team refers to as "composable, integrated, baked in from the beginning." He includes this tidbit:

> The most visceral observation in Pat’s talk: “As a longtime WordPress user, I’m looking at the WordPress plugin ecosystem and the TYPO3 extension ecosystem and going—I like the TYPO3 extension ecosystem because instead of twenty thousand plugins to do something, I have four. And those four are there because they’re good and they work and they’ve been tested. It’s not just market share. It’s the quality game, and it’s the architecture game.”

![Part of the Cloudfest Hackathon team that worked on FAIR for TYPO3](/src/assets/media/cloudfest-hackathon-pub-quiz-winners.jpeg){.right}

This mirrors my own experience with TYPO3's Extension Repository (TER), which I got a crash course in this spring while co-leading the [FAIR Package Management for TYPO3 project](https://www.cloudfest.com/blog/cloudfest-hackathon-2026-recap) at the CloudFest Hackathon alongside Benni Mack, with Joost de Valk and Karim Marucchi on the team.:fn\[If it feels like this piece keeps running into the same half-dozen people, it's not a coincidence, just a fairly small town where you can keep tripping over the same people. That, and I like to quote the smart people I work with.] (Three days inside TER's structure with the person who coined "content is the asset" will changes how you see a plugin ecosystem.) To Pat's point about how many plugins you need, the plugin count in the official WordPress repository is touted as a sign of health and robustness, but there's a point at which — hear me out — it actually becomes a sign of weakness, not strength.:fn\[I've been saying for quite a while now that the number is a falsehood: of 60-70,000 listings, only 10,000 have an install-count large enough to be matter to more than a small handful of users. Three plugin options doing something very well covers the space, and adding another dozen that do the same thing doesn't make the ecosystem any stronger, just more confusing. Add in the metric for plugins that haven't been updated within the past 12-24 months, and you realize very quickly that the plugin ecosystem is effectively not quite as claimed.]

Benni's phrasing really stuck with me: *"Content is the asset"*, perhaps because that same day, I'd gotten notice that we hadn't been selected for a project we'd recently been invited to pitch in response to an RFP. The major pain point they disclosed was that their content archives (decades of them) were not organized, leaving the content mostly inaccessible and hard to keep current. The proposal, rather than describing CMS features, went into detail about devising a content model with the architecture to support it. Irony can be painful.:fn\[The prospective client runs a major annual event for which they're well-known, alongside a series of smaller ones, which have trouble getting traction because they're overshadowed by the annual one. Content for the annual event is housed in a hosted app and inserted into the website with an iframe. They liked my prescription for the archives, but not enough to overcome the explanation for the cause of their problem: they're very committed to their app, and had trouble with source-of-truth framing.]

## AI Belongs *Below the UI*, not Instead of it

Remember, something died. Is the CMS the victim? Even notable luminaries have re-asked the recurring question, "[Do you *need* a CMS?](https://joost.blog/do-you-need-a-cms/)" (Joost's answer isn't *no*, it's not always.) Chris Reynolds' answer is "[The CMS is dead. Long live the CMS.](https://next.jazzsequence.com/posts/the-cms-is-dead-long-live-the-cms)", where he argues that AI is not a replacement for the CMS, and for the 24 years of content on his own site, his answer was “abso-fuggin-lutely KEEP the CMS.”:fn\[I also appreciated Chris' warning about vendor-lock with an example of an AI builder gone wrong. We'll return to that theme.] So no, the CMS isn't dead, because there's still content that must be managed.

::pullquote\["The website builder is dead, long live content management." —  Mathias Bolt Lesniak]Mathias Bolt Lesniak identifies a different victim, saying, "[The Website Builder Is Dead, Long Live Content Management](https://news.typo3.com/article/the-website-builder-is-dead-long-live-content-management)", doubling-down on the importance of content management (from the TYPO3 perspective), with the website builder taking the hit. Page builders have been around the WordPress ecosystem for a number of years now, with Elementor arguably fueling WordPress growth through the years where Gutenberg wasn't perceived to be mature yet. The thing is, every popular page- or site-builder is primarily concerned with *presentation*, not with data or content structures, which must still be manually-applied and enforced, or else accept the absence of structure with the visual builder's orientation toward simple text-on-page. Where Mathias nails it is in his core claim that AI should sit *below* the UI rather than *replace* it with a prompt — that's the AI-powered builder that Chris Reynolds warns about.

Over in Drupal-land, Dries Buytaert agrees. "[AI flattens interfaces and deepens foundations](https://dri.es/ai-flattens-interfaces-and-deepens-foundations)". He writes that historically,

> the *visible layer* of a CMS, the page builders and content creation workflows, is where most people spend their time. But the *invisible layer* is what makes organizations trust the system: structured content models, permission systems, audit trails, web service APIs, caching layers, translation workflows, design systems, component libraries, regulatory compliance and more.

He gives it a 70/30 split between the invisible CMS layer and the visible one, noting that for more than 20 years, the work started with a blank page at the visible layer. With AI, he argues that the job of the invisible (CMS) layer "shifts from 'content management' to 'context management', giving AI what it needs to do the job right. For this reason, he contends that CMSes have to evolve to become a reliable foundation that both humans and AI agents can build on, changing its role. "The invisible layer does more work but doesn't disappear." In other words, the CMS has more work to do, not less — and it happens in the background at the foundation, where the CMS becomes *more* important, not less.

::pullquote\[The CMS has *more* work to do — and it's *at the foundation*, where it's *more* important, not less.]Changing contexts (see what I did there?) to web accessibility, Slobodan Manic points out that "[The Accessibility Tree Is How AI Agents Read Your Site & It's Breaking](https://www.searchenginejournal.com/the-accessibility-tree-is-how-ai-agents-read-your-site-its-breaking/578171/)". The accessibility tree is "a semantic version of your page that the browser computes from the DOM so non-visual software can understand it." In other words, it's structured content, and it's used not *just* by screen readers, but by AI agents. He offers steps for improvements, but the real nugget is in the where and the why: a warning from the 2026 [WebAIM Million](https://webaim.org/projects/million/) report that accessibility regressed for the first time in six years with a corresponding 22.5% leap in home page complexity (DOM elements), which is partly attributed to AI-assisted "vibe coding." With ARIA-soup creating more confusion than it solves, it looks like AI-generated pages aren't being well-written for AI consumption. Why? It's at least partially because they're relying on an unstructured text-on-page format. This is precisely where the bolt-on solutions fail: they're only touching the presentation layer.

Alt text is already a target for using AI to address accessibility compliance, but on "[Accessibility and Artificial Intelligence](https://www.joedolson.com/2023/06/accessibility-and-artificial-intelligence/)", accessibility expert Joe Dolson says AI can assist the process, but shouldn't produce the end product. For that, the CMS must let editors accept or alter AI-suggested alt text, not auto-apply it. Independently illustrating the point by "[Comparing local large language models for alt-text generation](https://dri.es/comparing-local-llms-for-alt-text-generation)", Dries Buytaert tested 12 models for AI-generation of alt-text, and found the results to be inconsistent.

## Envisioning the *CMS of the Future*

![The post content as material for the cover of a pulp magazine](/src/assets/media/the-cms-of-the-future-pt1.34-400w.webp){.right}

We're ready now for a midpoint summary of requirements for the CMS of the Future. Our first three criteria are that it needs to enforce structure at the core, accurately focus AI and automation, and treat accessibility as infrastructure. In practice, here's what that will look like.

### 1. *Structure*

* **Separates content from presentation as a hard *architectural* rule rather than a style guideline.**:fn\[Benni Mack, "[Content is the Asset. Visual is the Skin.](https://news.typo3.com/article/content-is-the-asset-visual-is-the-skin)" TYPO3 News.] A visual redesign should never need to touch the content model. This only works if the model is genuinely relational and typed rather than a flat blob whose pattern you're disciplined about maintaining. Separation of layers means nothing if it's not done architecturally. Failing that, it's merely a convention.
* **Treats metadata, provenance, and relationships as core infrastructure.**:fn\[Benni Mack, "[Content is the Asset. Visual is the Skin.](https://news.typo3.com/article/content-is-the-asset-visual-is-the-skin)" TYPO3 News; David Steeb, "[AI-ready isn't a feature](https://b13.com/blog/ai-ready-isnt-a-feature)," b13.] The editorial flow of who authored and who approved a page, which translation is derived from which source, and what the content relates to need to be first-class, queryable metadata fields, not free tags bolted on afterward.
* **Handles permissions as an organizational-design problem instead of a simple access-control checkbox.**:fn\[Benni Mack, "[Content is the Asset. Visual is the Skin.](https://news.typo3.com/article/content-is-the-asset-visual-is-the-skin)" TYPO3 News.] At scale, (editors, departments, languages) a basic role-based CRUD permission model doesn't accurately mirror the organization. Getting this right is largely an unsolved problem in most CMS permission systems that don't handle mapping organizational complexity.

### 2. *AI & Automation*

* **Achieves AI-readiness from its content structure, not by shipping an AI feature.**:fn\[David Steeb, "[AI-ready isn't a feature](https://b13.com/blog/ai-ready-isnt-a-feature)," b13.] AI tooling should be able to plug in for things like search, translation, and classification, interacting with a stable, structured core. The core can't be chasing whatever AI framework is trendy in a given quarter.
* **Keeps AI below the UI rather than replacing it with a prompt.**:fn\[Mathias Bolt Lesniak, "[The Website Builder Is Dead, Long Live Content Management](https://news.typo3.com/article/the-website-builder-is-dead-long-live-content-management)," TYPO3 News; Dries Buytaert, "[AI flattens interfaces and deepens foundations](https://dri.es/ai-flattens-interfaces-and-deepens-foundations)."] Prompts hide structure, context, and whatever's actually happening. Editors must be able to see and audit what the AI touched. Watching a progress bar and trusting the result is not enough.
* **Makes provenance verifiable.**:fn\[David Steeb, "[AI flattens interfaces and deepens foundations](https://dri.es/ai-flattens-interfaces-and-deepens-foundations)," on the invisible layer's audit trails; Benni Mack, "[Content is the Asset. Visual is the Skin.](https://news.typo3.com/article/content-is-the-asset-visual-is-the-skin)"] If the content was AI-assisted, by what, and who signed off all need to be exposed internally (compliance, legal, audit) and possibly externally to the agents deciding whether to trust or cite the content.
* **Publishes with restraint.**:fn\[Carolyn Shelby, "[Why Publishing More Content Is Making Your SEO Worse](https://www.searchenginejournal.com/why-publishing-more-content-is-making-your-seo-worse/576047/)," Search Engine Journal.] Since AI retrieval rewards semantic clarity and coherence over page count, the CMS of the future needs to surface near-duplicate content and push toward consolidation. It's the exact opposite instinct from over a decade of SEO tooling built to reward volume-based publishing.

### 3. *Accessibility as Infrastructure*

* **Treats semantic markup as an API surface for both assistive technology and AI agents to consume.**:fn\[Slobodan Manic, "[The Accessibility Tree Is How AI Agents Read Your Site & It's Breaking](https://www.searchenginejournal.com/the-accessibility-tree-is-how-ai-agents-read-your-site-its-breaking/578171/)," Search Engine Journal; [WebAIM Million](https://webaim.org/projects/million/), 2026.] Accessibility is more than a compliance item. Since agents read the accessibility tree, native HTML elements, accessible names on controls, and accessibly-rendered content aren't parts of a separate workflow from AI-readiness, but the same one, recreated twenty years on.
* **Keeps a human in the loop for AI-generated accessibility fixes.**:fn\[Dries Buytaert, "[Comparing local large language models for alt-text generation](https://dri.es/comparing-local-llms-for-alt-text-generation)"; Joe Dolson, "[Accessibility and Artificial Intelligence](https://www.joedolson.com/2023/06/accessibility-and-artificial-intelligence/)"] Alt text is the obvious one, with AI alt-text generation produces results that are inconsistent enough to require review every time, the CMS must let editors accept or alter AI-suggested alt text. Filling it confidently with wrong information is worse for an agent (and a screen-reader user) than the gap it's fixing.
* **Resists patching structure with ARIA attributes and fixes the underlying markup instead.**:fn\[Slobodan Manic, "[The Accessibility Tree Is How AI Agents Read Your Site & It's Breaking](https://www.searchenginejournal.com/the-accessibility-tree-is-how-ai-agents-read-your-site-its-breaking/578171/)," Search Engine Journal.] Because a wrong or empty attribute fills the tree with a falsehood rather than leaving a gap, pages with ARIA present now average more errors than ones without it. The CMS of the future needs to turn the correct native element into the path of least resistance rather than bolting on attributes after the fact.

## Next: Where the *Website Ends*

So far, we're pointing at an enforceable structured content model with first-class content metadata from all directions. I would contend that most CMSs have gradually allowed their presentation layers to drift into the content layer, which reneges on the promise made 25 years ago by "database-backed websites", that separating them would mean the site could be easily reskinned without touching the content. It was the right idea, but the promise eroded to the point that liberating and parsing content for a site rebuild has become an onerous task.

That's the structural half of the argument: content as asset, architecture as the advantage the asset depends on, and AI as a tenant of that structure rather than its landlord. But none of it says where the content actually needs to *go*, who gets to decide how the platform underneath it is governed, or what happens when that platform answers to someone else. That's all in Part II.