What is a headless CMS? An agency's answer
What is a headless CMS? Content stored separately from the site that shows it. What that means for an agency, in plain terms, without the developer jargon.
Somebody in a pitch meeting says the word "headless", the client nods, and nobody in the room is quite sure everyone means the same thing. It comes up in proposals, in RFPs and in developers' recommendations, usually without a definition. Here's one, written for the agency owner and the account manager rather than the developer.
The one-sentence version
A headless CMS stores your content separately from the website that shows it, and hands that content to any website, app or screen that asks for it.
The "head" is the part people see: the website's design, its pages, its layout. A traditional CMS like WordPress keeps the content and the head welded together. The content is stored in a shape that only that theme knows how to show, and the editor works on the pages directly. A headless CMS keeps only the content: a list of things, each with named fields, available to whatever needs it through an API. Something else has to draw the page.
Why it matters to an agency, not just a developer
Developers like headless for technical reasons. Agencies should care for three practical ones.
Redesigns without migrations. When the content isn't tied to the design, a redesign is a new head on the same content. You don't export four hundred posts from the old site and fix their formatting in the new one. You replace the part that draws them.
The same content in two places. A client's events, locations or team members can appear on the main site, a campaign microsite and a screen in reception, all from one source. Edit once, it updates everywhere. Without that, someone is copying and pasting, and copies drift.
No design in the client's hands. When the client edits in a headless CMS, they're filling in fields, not arranging a page. They can't break the layout because the layout isn't there. Content control, not design control goes into why that's the thing that saves agencies money.
The cost nobody mentions
"Headless" usually means you build and host the head yourself. The CMS stops at the API. Everything after that, the front-end application, the hosting, the preview of unpublished changes, the build and deployment pipeline, the staging site, the rollback when something goes wrong, is a separate project.
For a product company with a front-end team, that's fine; they want the control. For an agency, it's a hidden project on every client site. The proposal says "headless CMS" and the work turns out to be "headless CMS, plus a JavaScript app, plus a host, plus a deploy pipeline, plus keeping all four working for years". Contentive vs Contentful and Sanity is about exactly that gap.
The middle path
There's a third option between a traditional CMS and pure headless: a platform where the content is stored as structured data, separate from the design, but which also ships a head, so you don't have to build one.
That's how we built Contentive. Content lives in a content model, the client edits fields, and sites render through Liquid themes that we host, with a staging step before anything goes live. When a project genuinely needs its own front end, the same content is available through a generated GraphQL API. Liquid themes explained covers how the built-in head works. Other platforms take this middle path in their own ways too; the point is that it exists.
When headless is overkill
A five-page brochure site for a business whose content won't change much is not a headless project. Nobody will ever reuse its content elsewhere, there's no redesign coming soon, and the client edits it twice a year. A good site builder or a simple CMS will serve them well, cost less and be easier to hand over. Choosing headless there is choosing extra work for a benefit the client will never use.
Headless starts paying off when there's a lot of content of the same kind, when it will be shown in more than one place, when the client edits often, or when the design will change long before the content does.
A worked example
Take a restaurant group with three locations. On a traditional CMS, each location is a page someone wrote: address in a paragraph, opening hours in a list, menu as a PDF. On a headless CMS, each location is a record with fields: name, address, opening hours, phone number, menu items linked to it. The website shows each location on its own page and all three on a map. The booking app shows the same opening hours. The screen in each restaurant shows that location's specials. Change Sunday's hours once and all three update.
Nothing about that requires headless in particular. It requires content stored as fields, separately from the design. Headless is one way to get there.
What it's not
It isn't a speed guarantee; a slow front end is slow whatever feeds it. It isn't automatically more secure, though having less exposed software can help. And it isn't a reason on its own to choose a technology. It's an architecture, with costs and benefits like any other.
Three questions before you call a project headless
Will this content ever be shown anywhere other than this one website?
Who will build, host and maintain the front end, and for how long?
Is the client paying for the separation, or are we doing it because we like it?
If the answers are "no", "us, forever" and "because we like it", you have a traditional site project. Price it as one. If you're not sure what the content would even look like separated out, what is a content model is the place to start.