A headless content system separates where content is stored from how it is displayed. It solves a genuine problem for organizations publishing to several places at once, and creates work for everybody else.
Short answer
A headless system stores content without deciding how it looks. A separate app then draws it. That split helps when the same content feeds a website, an app and a partner feed. For a business with one website it adds a build, a second vendor, and nothing a visitor can see.
Content lives in one system as plain data. A separate app fetches it and decides how it looks. The two are joined by a link rather than being one product.
That split is the whole idea. Change the look without touching the words, feed several places from one source, and let two teams work on their own half.
It is a sound way to build, and a crawler or an answer engine cannot tell which way a page was made. Whether you have that problem is the only question that matters here.
The word itself is unhelpful. It only means the content system has no front end of its own, so it has no head. Nothing about it is more modern or more capable than a system that includes one.
Sending the same words to more than one place. A website, a phone app, screens in a shop, a partner feed and a printed catalogue, all drawing on one source.
A big writing team working next to a separate build team, where each needs to move without waiting for the other.
And firms that expect to rebuild the front of the site every few years while keeping years of words untouched. That is a real and costly problem at a certain size.
A build. There is no site until somebody writes the app that draws the content. That means a developer, a timeline and a budget before anything is visible.
Two vendors and two bills, with the faults of both. When something breaks, the first question is which half did it, and nobody owns the whole thing.
And editing is usually worse for an owner who is not technical, because the content system cannot preview a page it does not control.
It also costs speed of change. A small edit that would take a minute in a hosted tool can need a developer, a build and a deploy, and that friction is what stops sites being kept current.
The list below is the honest test. A business matching most of these is being sold an architecture rather than a solution to anything it currently has.
The strongest case made to small firms is about the future: keep the words, replace the look later. It sounds good and it rarely holds up.
Content on any reasonable platform can be exported. Our page on moving a site covers what actually makes migrations hard, and it is rarely the content format.
What makes them hard is addresses, redirects, forms and the hundred links to other tools nobody wrote down. Headless helps with none of those.
When the content feeds more than one place today, not one day. That single test settles most cases correctly, either way.
When you have a build team whose time is better spent on the look than on a content system, and a writing team that needs to work on its own.
And when the firm is big enough that one combined system costs more to coordinate than two separate ones.
And when the content really is structured. Products with fields, events with dates, listings with attributes. Pages of prose gain very little from being stored as data rather than as pages.
Which places besides the website will use this content, and when. If the answer is one day, the design is being chosen for its own sake.
Who maintains the rendering application after launch, and what happens when they are unavailable. Our page on questions to ask a provider covers the rest.
And what the owner can change without a developer. If the answer is nothing, the site will stop being updated, which costs more than the design ever gains.
One that stores content as structured data without deciding how it looks, with a separate application rendering it. The separation lets one source feed several destinations and lets teams work independently.
Almost never. The benefit appears when content feeds more than one destination today. With one website and no application, it adds a build project, a second vendor and nothing a visitor can see.
Less than claimed. Content on any reasonable platform exports. What makes migrations hard is addresses, redirects, forms and undocumented integrations, and headless does not help with any of those.
Which destinations besides the website will use the content and when, who maintains the rendering application afterward, and what the owner can change without a developer. Hypothetical answers mean the architecture was chosen for itself.
15-day free trial. Card required. Cancel before day 15 and you pay nothing.