Content platform

A content platform is the system an organisation uses to model, manage, and deliver its content, treated as structured data that can be published to many destinations. It is a broader idea than a single website. Where a website is one place content is shown, a content platform is the source that feeds every place it appears: the marketing site, the mobile app, the in-product help, the email system, and whatever comes next.

The term is used loosely, and most of the confusion comes from treating it as a product category. No vendor ships the whole thing. What follows sets out the parts a content platform is assembled from, what the word “platform” claims that “website” does not, where the boundary sits against the neighbouring terms, and how to tell whether the description fits a given requirement.

Content is stored as typed fields

The defining idea is that a piece of content exists as data before it exists as a page. An article is a set of typed fields: a title, a body, an author, a publish date, a set of related items. None of it is HTML. Because the content is structured, it can be requested by any application and arranged to fit that application’s needs. The same product description can appear on a web page, inside a native app, and in a printed catalogue feed without being rewritten for each.

This is what people mean when they say content is reusable. The work of writing and structuring it is done once, and the platform delivers it wherever it is needed.

How much of that reuse is genuinely available depends on the modelling, and the label guarantees none of it. A model built around one page layout hands every other destination that layout’s fields and little else, which is why structured content and the content model decide what the platform can do long before any front end is written.

The parts a content platform is made of

A content platform is an arrangement of six parts. Each one is a decision somebody makes, and each one constrains what the others can do afterwards.

Part	What it does	What it settles for years afterwards
Content model	Defines the types, the fields they carry, and the relationships between them	Which destinations can be served without remodelling, and how much of a redesign the content survives
Editing experience	The interface non-technical staff use to create and change content	Whether publishing needs a developer, and how many review rounds an ordinary change costs
Governance and permissions	Roles, workflow states, review and approval	Who can publish what, and whether structure and tone hold across many contributors
Delivery layer	Serves content to whatever asks for it, usually over REST or GraphQL	How many surfaces can be added without touching the content system, and how a publish becomes visible
Front ends	The applications that render content for each destination	The cost of a redesign, and the maintenance line each surface carries for as long as it is live
Infrastructure and operations	Hosting, environments, backups and monitoring for all of the above	Where the data sits, who patches, and whose schedule version upgrades land on

A CMS purchase covers the second, third and fourth rows, and part of the first. The model itself, the front ends and the operational arrangement are supplied by the organisation or by whoever builds on its behalf. That split is the practical reason “we need a content platform” costs more than a licence comparison suggests, and CMS TCO sets out where the remaining lines land in a budget.

What “platform” claims that “website” does not

Calling it a platform rather than a website is a statement about ownership and reach. Three claims sit inside the word.

Content outlives the design wrapped around it. A website is a design plus the content inside it, and replacing the design has historically meant re-entering the content. A platform holds the content independently of any presentation, so a redesign becomes a front-end project rather than a migration.

The content model becomes an interface other teams build against. Once content is served over an API, applications the content team does not own begin consuming it: a mobile app, an in-product help panel, a partner feed, a retrieval layer for an AI assistant. Each consumer depends on the shape of the content, which turns the model into an interface that has to be versioned, where it had been a private arrangement the content team could change at will.

Someone has to own it after launch. A platform carries an upgrade path, an on-call arrangement and a budget line that continue once the launch is over. Where none of that is held by anyone, the organisation has a website that happens to serve JSON.

A headless CMS is often the content-management part of a content platform, and the platform is the wider whole, including how content is modelled, where it is hosted, and how it reaches each destination.

Where the boundary sits against the neighbouring terms

Four terms overlap with this one, and each differs on a single axis.

A CMS is one component. It manages content and, in the traditional case, renders it too. The platform is the assembly the CMS sits inside. See headless vs traditional CMS for what changes when the rendering half is removed.

A DXP is a purchasing model. It bundles content management with personalisation, campaigns, analytics, asset management and a customer profile store on one contract. An organisation that uses a suite this way has a content platform built from a suite. The category name describes how the parts are bought, and it says nothing about what the system does with content.

MACH and composable architecture describe how the parts are assembled and hosted. A content platform may follow those principles or may not. A platform running one self-hosted CMS behind one front end diverges from the cloud-native SaaS letter of the acronym and still delivers structured content to several destinations.

Content operations is the practice around the system, covering who writes, who reviews, who approves, and how consistency holds across contributors. The platform supplies capabilities; content operations decides how they are used and who answers for each step. Teams frequently arrive at a platform decision when the binding limit is on that side instead.

When the term describes the actual requirement

The shift from “we need a new website” to “we need a content platform” usually reflects a change in what the organisation has to publish. Four situations make it the accurate description.

A second destination with an owner and a date. The same content has to appear in an application, a partner feed, in-product help or a physical display, and somebody is accountable for that destination on a known timeline. A place on a roadmap wish list does not count. The modelling cost is recovered on the second surface, so a surface that never arrives never repays it.

A front end expected to be replaced more than once. Where the organisation intends to redesign while keeping the content, holding content independently of presentation is what makes the second redesign cheaper than the first.

Publishing that cannot wait on a developer. A team that needs to change copy, add a page and run a campaign without a release is buying an editing experience and a block library, both of which have to be designed, and neither of which arrives by default.

Several sites or brands sharing one content set. Shared components, shared governance and per-market variation are the multi-tenant CMS case, and the model has to carry the tenancy from the start.

Where none of those hold, and the requirement is one rarely-changing site with a small number of pages, a full content platform is more than the situation calls for. A campaign or event site whose content is inseparable from its design is the clearest instance: the structure gets built for a reuse that never happens, and the site is retired before a second destination exists.

Where WAYF’s content platforms sit

WAYF builds content platforms on Payload, a headless CMS where WAYF holds a Partner and Top Contributor position, with Next.js on the front end. Payload is self-hostable, so the platform can run in infrastructure the organisation controls, which suits data-residency requirements and moves version timing onto the team that runs it. The trade underneath that choice is set out in self-hosted vs SaaS CMS.

Two of the six parts take most of the attention in that work. The content model is settled before the build: on Ingersoll Rand’s platform for China, that meant nine page types and tens of reusable blocks across more than twenty brand tenants, modelled and approved in writing before implementation. The delivery boundary is treated as a contract rather than a direct dependency: that build introduced a Content Provider Service inside the Next.js front end, validated with Zod, with adapters written for both Contentstack and Payload against the same interface, so the front end does not need to know which system a page came from. The Council of Europe Development Bank’s events platform runs on Payload today. How WAYF builds content platforms covers the engagement shape.

Where it connects

A content platform is assembled, and the parts are chosen separately. Each one constrains the others, which is why the model is worth settling first and the front end is worth treating as a second application with a budget of its own.

For the content-management component most often at its centre, see headless CMS, and for the architectural split underneath it, headless vs traditional CMS. For the principles a platform may or may not be built along, see MACH and composable architecture. For the suite model it is usually weighed against, see DXP. For the practice of running one day to day, the roles, review and governance around it, see content operations. Where the live question is a move from an existing system, replatforming sets out the phases and what each one risks.