First of a trilogy on the content layer, the part of the stack that decides what an experience is allowed to say and show. Read it alongside the DAM, the asset layer that became a supply chain, and the DXP, the category that tried to contain the whole experience.
The first web content management systems solved a problem that sounds almost trivial now but was not trivial then. Organisations wanted to publish more pages, more often, without asking a developer to edit HTML every time a product description, a press release or a corporate address changed. The early web was built from files, with content, layout, navigation and code often mixed together, so publishing meant changing a document, checking links, moving files to a server and hoping nothing broke. As websites grew, that model stopped scaling.
The CMS separated the content from at least part of the code around it, introducing templates, workflows, permissions, versioning and an interface that people outside the development team could actually use. That separation created one of the most durable operating contracts in digital technology: business teams manage content, technical teams manage the system that presents it. For a long time the page sat at the centre of that contract, and then content stopped being page-shaped. It had to appear in mobile applications, commerce experiences, product interfaces, emails, customer portals, voice assistants and connected devices, and now it also needs to be retrieved, interpreted and assembled by AI agents. The CMS survived each of those transitions, but it changed meaning every time. What began as a page publishing engine became a structured content repository, then a headless platform, then part of a composable architecture, and now vendors increasingly describe it as the content layer for agentic experience. The acronym stayed the same. The architectural role did not.
I have watched most of that evolution from inside it. In the late 1990s I was building content management systems in Allaire ColdFusion, now an Adobe technology, back when separating content from code still meant writing the database queries and the page templates yourself. My university thesis was a blog platform I wrote from scratch and called AVBlog, a project that outlived the thesis far enough to ship a 2.0 version in the mid-2000s with several people using it live, and building it meant reinventing by hand, and often badly, every abstraction this article is about: a content model, templates, an editing workflow, permalinks. Later I ran enterprise web estates on Adobe Experience Manager Sites and Assets, and kept smaller dynamic sites alive on WordPress and Joomla. The through line across all of it is the one thing that never changed. The moment you stop editing files and start managing content, you have made an architectural decision, whether or not you noticed it at the time.
What it actually solved
The original CMS problem was not content strategy, it was publishing dependency. Before content management became a software category, updating a website usually required access to the underlying files and enough technical knowledge not to damage the presentation or navigation around them, so even simple changes depended on a webmaster, a developer or an agency. As corporate websites expanded from a few static pages into product catalogues, newsrooms, investor sections, multilingual sites and customer-service destinations, that bottleneck became impossible to ignore.
A CMS broke the bottleneck by introducing a set of abstractions that together changed how publishing worked. Content could be entered through forms rather than written directly into HTML, templates could control presentation separately from the words and images inside them, and roles and approvals could determine who was allowed to create, review and publish. Version history made changes traceable and reversible, navigation and page relationships became something the system managed rather than something maintained by hand, and publishing itself turned into a controlled workflow instead of a file-transfer task.
The important shift was organisational as much as technical. A marketing, communications or editorial team could now own the publishing calendar without owning the codebase. Developers still built the templates and integrations and designers still defined the presentation system, but day-to-day publishing moved closer to the people responsible for the message. That is why the CMS became so widespread. It did not merely make websites easier to build, it changed who could operate them.
There is a longer lineage here worth naming, because the web itself was proposed as a response to information-management complexity. Tim Berners-Lee’s 1989 proposal at CERN described a way to connect information distributed across people, systems and documents, and the CMS arrived later as one practical answer to a narrower version of the same problem: how to organise, maintain and publish a growing body of web information without letting its structure collapse. That original requirement still exists. Only the scale changed.
The market that shaped it
The CMS market was shaped by two different forces that eventually met in the middle. The first was enterprise web content management, where large organisations needed governance, multilingual publishing, multisite management, complex permissions, scheduled releases, integrations and reliable operation across large digital estates, so vendors built systems around corporate websites, portals and high-volume publishing teams. The second was open web publishing, where platforms such as Drupal and WordPress made content management accessible to a much wider market, lowering the cost of running a site, creating large developer ecosystems and establishing the expectation that publishing should be possible through a browser rather than through a deployment process. WordPress alone still runs somewhere north of forty per cent of all websites, and close to sixty per cent of every site built on a recognisable CMS, which is the clearest measure there is of how completely the browser-based publishing model won. These two markets differed in scale and operating model, but they shared the same architectural assumption: the website was the primary destination, and the page was the primary unit of content.
That assumption shaped the data model. A page had a title, a body, an image, a position in a hierarchy and perhaps a collection of components, templates determined where those elements appeared, navigation reflected the page tree, and preview meant seeing the page as it would look on the website. For the market that created the CMS, this was exactly right. The website was the centre of digital experience, mobile applications were secondary or did not exist, email content was usually assembled somewhere else, commerce platforms managed product presentation independently, and customer-engagement systems delivered messages through their own templates. The CMS owned the site, and the rest of the stack owned everything around it.
Over time that clean boundary became harder to sustain. Content teams wanted to reuse the same product story across web, app, email and commerce, brands wanted one approval process for every channel, developers wanted modern front ends without replacing the editorial workflow, and regional teams wanted local flexibility without recreating the same content in every market. The page-centric model started showing its limits, because a piece of content that only exists as a block inside a page is difficult to reuse elsewhere, a campaign message stored as formatted HTML is not easily assembled into a mobile card or a personalised email component, and a product claim embedded inside a template is difficult to govern independently from the page where it appears. The CMS had made publishing scalable. Now the market needed content itself to become portable.
How vendors changed the meaning
The first response was expansion. Web content management vendors added forms, portals, personalisation, analytics, campaign tools, commerce integrations and digital asset management until the CMS became the centre of a broader web-experience suite. This made sense commercially and technically, because once a platform already controlled the page it was natural to add more of the capabilities required to optimise that page, but it also stretched the category to the point where a CMS could mean a lightweight publishing tool, an enterprise web platform, a commerce content engine or the content component inside a much larger experience suite. The analysts noticed the category dissolving before most buyers did. In January 2020 Gartner retired its Web Content Management Magic Quadrant after running it for roughly twenty years, judging the market commoditised and client demand shifting to the broader scope of the DXP, and it folded what survived into a lighter Market Guide. When the research firm that built its reputation ranking a category decides the category no longer deserves a quadrant, that is the clearest possible signal that CMS had stopped being a thing you buy and become a layer inside something larger. This is the actual root of the CMS-versus-DXP confusion that still muddies procurement: the boundary is blurred because Gartner itself dissolved it.
The second response was separation. Headless CMS platforms decoupled content management from presentation, and instead of assuming that the CMS would render the final page, they exposed structured content through APIs and allowed websites, applications and other channels to consume it independently. This changed the unit of design, because the important object was no longer always the page. It could be a product benefit, an event, a legal disclaimer, a campaign proposition, a store location, a support answer or a reusable promotional module, and content modelling became more important than template configuration. The promise was straightforward, model content once, manage it centrally and deliver it anywhere, and the architectural value was real. A decoupled content layer let development teams use different front-end frameworks, release experiences independently from editorial workflows and serve multiple channels from the same governed repository, and it aligned naturally with the API-first, cloud-native and headless principles later grouped under MACH and composable architecture.
But headless introduced a new problem, because it removed assumptions from the platform and then asked the organisation to replace them with architecture. Preview, routing, page composition, localisation, search, caching and editorial experience did not disappear when the rendering layer was decoupled, their responsibility simply moved, and organisations that adopted headless without designing those responsibilities sometimes discovered they had replaced a restrictive CMS with a flexible repository and a large amount of custom work. This is where the market shifted again, toward what vendors now call composable content platforms, hybrid CMS or visual headless systems, all of which try to keep structured, API-delivered content while restoring enough context for marketers and editors to assemble and preview complete experiences.
And now a third change is underway, because the content layer is becoming agent-addressable. Salesforce’s 2026 agreement to acquire Contentful makes this direction unusually explicit, with Salesforce describing Contentful’s structured content architecture as a layer that Agentforce can query, assemble and deliver dynamically across channels. That framing matters, because the CMS is no longer only the place where a human editor prepares something for publication. It is becoming the governed source from which a machine can retrieve approved facts, claims, offers and content fragments at runtime. In that model the content model is not just an editorial convenience, it is the vocabulary available to the agent; the permissions are not just publishing controls, they define what the agent may read, combine, adapt or expose; and the metadata is not just there to improve search, it gives the agent the context required to decide which content is valid for a market, audience, language, channel or regulatory situation. The CMS has moved from publishing interface to runtime infrastructure.
What it means architecturally today
A modern CMS is best understood as a governed system for reusable structured content, which is more precise than calling it a website platform and more useful than classifying it as headless or traditional before the requirements are understood. Its architectural responsibilities usually run across defining the structure and relationships of content, managing authoring, review, approval and publication workflows, controlling versions, localisation and market variants, exposing content to websites, applications and downstream systems, preserving enough context for editors to understand where content will appear, enforcing governance around who can create, change, publish and retire content, and making approved content discoverable to people, applications and agents.
What it should not automatically own is equally important. A CMS does not need to become the master customer profile, it does not need to decide which audience receives a message, it does not need to own channel pressure, next-best action or journey arbitration, and it does not need to replace the DAM for every binary asset or the PIM for every product attribute. The clean architectural question is what content is reusable, who governs it, and how every experience retrieves the right version, and that question leads to a series of practical design decisions. The failure I see most often sits upstream of all of them: teams model content to fit the website they happen to have today, so the first genuinely new channel forces a rebuild of the entire model, and the CMS that was supposed to make content portable becomes the reason it is not.
The first is the smallest meaningful content unit. If the model is too coarse, content remains trapped inside pages, but if it is too atomic, editors must assemble every sentence from fragments and the authoring experience becomes unusable. The second is which relationships belong in the CMS, because a product story may reference an offer, a legal disclaimer, an image and a market, and yet the CMS should not silently become the master for pricing, inventory, consent or customer eligibility simply because those values appear in the experience. The third is where experience composition is performed, since in some architectures the CMS assembles pages and components while in others a front-end application, commerce engine or DXP composes the final experience from multiple services, and that boundary needs to be explicit. The fourth is how personalisation works, because the CMS can store variants but another layer usually decides which variant is appropriate, and when both the CMS and the engagement platform contain targeting logic, governance becomes difficult quickly. The last is what agents can do, because reading approved content is different from editing source content, and as agentic interfaces spread the access design has to distinguish retrieval, recommendation, composition, modification and publication as separate permissions with separate risks. The architecture is not complete when the content can be delivered through an API. It is complete when ownership, modelling, governance, delivery and runtime decisioning all agree on what that API means.
What it gets confused with
CMS is regularly used as a loose label for several adjacent capabilities, and pulling them apart is most of the value in understanding the category. It is not a DAM, because a CMS manages structured editorial content and its relationships while a DAM manages digital assets, their metadata, rights, versions and renditions; the two often integrate closely and some suites sell both, but they solve different governance problems. It is not a DXP, because a CMS is usually one of the core components of a digital experience platform while a DXP claims a broader role across composition, delivery, personalisation, optimisation and integration, and calling a CMS a DXP does not create those additional capabilities. It is not a CEP, because the CMS manages what can be said while the CEP decides who should receive an interaction, when it should happen and through which channel, and although a journey may retrieve content from the CMS, content governance and engagement decisioning should not be treated as the same function. It is not a PIM, because a product information management system governs product attributes, classifications and commercial information while a CMS may add narrative and editorial context around those products without becoming the source of truth for the catalogue. And it is not a knowledge base, although it may feed one, because knowledge systems require their own models for authority, evidence, retrieval and answer quality, and storing articles in a CMS does not automatically make them suitable grounding material for customer-service or AI systems. The category boundaries are not perfectly clean and they do not need to be. What matters is that the ownership boundaries are.
Does it still matter
Yes, and here is the part I find genuinely strange about the CMS. It has survived thirty years not by defending its original definition but by repeatedly abandoning it. Every time the CMS mattered more, it was because it had stopped being about the page: first when it separated content from code, then when it went headless and stopped rendering anything at all, and now as it becomes a source that machines read rather than a place that humans publish. The old definition is no longer enough, because the need to manage content did not disappear when websites became applications, it became more important when content had to move across channels, markets and interfaces. Headless did not make the CMS obsolete, it removed the assumption that the CMS should own the final presentation; composable architecture did not remove the content layer, it made the contracts around that layer more visible; and agentic experience will not remove content management either, it will make structured content, provenance, permissions and governance more consequential, because machines will consume the repository at a scale and speed that human publishing teams never did.
The acronym still matters because the capability still matters, but a CMS should no longer be evaluated mainly by asking how easily it creates a page. The better test is whether the content model can represent the business clearly, whether people can govern it without becoming dependent on developers, whether channels can retrieve it without duplicating it, whether agents can use it without bypassing approval, rights or brand constraints, and whether the organisation can change the presentation layer without rebuilding the content itself. The CMS began as the system that let organisations publish without touching the code, and its next role is more strategic, because it is becoming the contract that lets every channel, application and agent use content without losing its meaning.
The CMS stopped being the thing that renders your pages and became the governed source every channel and agent reads from, so evaluate it as the contract that keeps content meaningful across the whole stack, not as a page editor.
Sources
W3C
- Information Management: A Proposal (Tim Berners-Lee’s 1989 proposal, framing the web as a response to distributed information-management complexity.) · A Little History of the World Wide Web (The original proposal, first browser-editor and early web architecture.)
Drupal and WordPress
- Drupal: Our history (Drupal’s evolution from an experimental community site to an open-source CMS.) · WordPress: About (The open-publishing mission that helped make browser-based content management widely accessible.) · W3Techs: Usage statistics of WordPress (WordPress share of all websites and of CMS-built sites.)
Gartner
- Gartner Retires the Magic Quadrant for Web Content Management (The 2020 retirement of the WCM Magic Quadrant as the market commoditised and demand shifted to DXP.)
Contentful
- Headless CMS explained (The separation of content management from the presentation layer and the role of APIs in multichannel delivery.) · Content modelling basics (How content types, fields and relationships replace page-bound content models.)
MACH Alliance
- The MACH Manifesto (The microservices-based, API-first, cloud-native SaaS and headless principles behind many composable architectures.)
Salesforce and Contentful
- Salesforce Signs Definitive Agreement to Acquire Contentful (Contentful positioned as structured content infrastructure that Agentforce can query, assemble and deliver dynamically.) · Scaling Our Vision with Salesforce (The founders’ account of the shift from page-centric CMS to structured content for the agentic web.)
