Every page that explains headless is published by somebody who sells it, builds it, or built their own site on it. That is not a conspiracy, it is who bothers to write about the category, and it has a predictable effect: the gains are itemized and the losses are compressed into a sentence about “requiring developer resources.”
The losses are more specific than that, and they are not evenly distributed. They land almost entirely on the person who publishes, and almost not at all on the person who decides. Which is exactly why they survive the decision.
Here is the list, honestly, along with which ones you can buy back and which ones are structural.
1. Publishing stops being a single action you control
On a traditional CMS, you press publish and the page exists. The loop closes in seconds and you close it yourself.
Split the content from the presentation and publish means something narrower: the content is now available to whatever renders the site. Whether a reader can see it is a second event, and it belongs to a system you do not operate.
Sometimes that second event is fast enough not to notice. Sometimes it is a build that takes minutes. Sometimes it is scheduled. The variable that actually matters is not the duration, it is whether you can see the result of your own action without asking anyone.
Can you buy it back? Partly. Faster builds and on-demand rebuilds narrow the gap to the point where it stops mattering for most teams. What does not come back is the certainty. You go from knowing it is live to checking whether it is live, and that is a permanent change in the shape of the job.
2. Preview has to be built, and it is three separate things
This is the one that produces the most friction per week and gets the least attention in the decision.
A traditional CMS previews unpublished work because the same software holds the content and draws the page. Separate them and there is nothing to draw the page with unless somebody builds a preview path deliberately.
And it is not one feature. It is three, and they are commonly delivered one at a time:
- Previewing a draft that has never been live.
- Previewing something scheduled for the future.
- Previewing an edit to a post that is already live, without readers seeing the edit while you look at it.
The third is the one most often missing, and it is the one an editor needs most, because correcting a live post is a routine act and doing it blind is unpleasant.
Can you buy it back? Yes, and increasingly it comes in the box. Several platforms now ship a visual editing layer that handles most of this. Check on the specific plan you would buy, not on the marketing site, and check all three cases by name rather than accepting “yes, we have preview.”
3. Fixing how something looks stops being your job
On a traditional platform, a page that renders badly is often within reach: change a setting, adjust a block, edit a template part. Not always, but often enough that an editor develops a habit of fixing small things.
When the front end is separate software, presentation is code. A heading that wraps wrong, an image that crops badly, a list that lost its spacing: all of it is now a description you write for somebody else, in a queue, released when their work releases.
This is the loss that changes the job most and is written about least, because the people writing about headless are usually the ones who can make the change.
Can you buy it back? Only through process, not through product. Some teams keep a small set of editor-controlled layout options. That helps and it is worth asking for during the build, when it is cheap, rather than after, when it is a project.
4. The plugin answer disappears
Mature traditional platforms have an ecosystem where “we need a form”, “we need a table of contents”, “we need related posts” is often solved by installing something, in an afternoon, by a non-developer.
In a headless setup, most of those needs are front-end features, and the front end is bespoke. There is no directory to search. There is a ticket to write.
Some of that ecosystem is genuinely worth losing. Plugin sprawl is a real maintenance cost and a real security surface. But the trade is honest only if you say what you are giving up: the ability to answer a small need quickly, without a developer, at no cost. For a small team that answer was doing a lot of work.
Can you buy it back? No. This one is structural. What you can do is get honest before the decision about how often you used it, by going through your current site’s installed extensions and asking which of them solved a request from a non-developer.
5. Your content has to fit fields, and some of it will not
Headless platforms encourage structure: a title field, a summary field, an image with its own caption, a list of related items, each in its place.
The upside is real and this article is not going to pretend otherwise. Structured content is reusable, queryable, and renders sensibly in more than one context.
The cost is that a field is a constraint, and constraints are invisible until you hit one. The awkward piece that needs a layout the model does not have becomes a negotiation, and the honest answer is often that it cannot be published as intended.
And it applies backward as well as forward. An existing archive was written for a system that did not ask these questions. Fitting it into a model built for the content you plan to write is one of the more expensive parts of any move, and it is not a technical problem, it is an editorial one.
Can you buy it back? Partly, by designing the model against your actual worst-case content rather than your typical content. Take your five most awkward existing posts to the modelling conversation. If the model handles those, it will handle the rest.
6. Two vendors instead of one, and the boundary between them
A traditional platform is one thing that either works or does not. A headless setup is at minimum a content platform and a rendering layer, usually with a host and a build service alongside.
When something is wrong, the first question is which of them is wrong, and that question is harder than it sounds when the symptom is “the post is not on the site.” It might be the content platform, the build, the host, or the post itself.
The effect on you as an editor is not that you have to debug it. It is that you often cannot tell whether the problem is yours, which means you cannot tell whether to fix it or report it. That uncertainty is a small tax paid many times.
Can you buy it back? No, but you can reduce it. Ask, during the build, for one page that tells a non-developer whether the last build succeeded and what content it included. It is a modest thing to build and it removes most of the guessing.
What is not on this list, and why
“It costs more” is not on the list, because it depends entirely on scale, plan tier and who does the front-end work, and any figure here would be invented. What is worth saying is that the shape of the cost changes: less in licences and plugins, more in developer time, and more of it recurring rather than one-off. Price your candidate on your own traffic and your own team, and treat any published number, including a vendor’s, as an illustration.
“It is harder to learn” is not on the list either. The writing side of most headless platforms is unremarkable, and treating it as forbidding sets people up to be surprised by the real difficulty, which is the publishing side.
Vendor risk is real and it is a different subject. What happens when the platform you built on is acquired, repriced or shut down is a question about the years after the launch rather than about the model itself, and it deserves its own treatment.
How to use this list
Take the six and mark each one acceptable, buy it back, or that is our whole problem.
Most teams find four are acceptable, one is worth negotiating during the build, and one is a genuine objection. Which one is the objection tells you more about your team than any feature comparison will. A team whose editors fix their own layout problems will feel loss three every day. A team with an unusual, non-repeating archive will feel loss five on the first week of migration. A small team that leaned on extensions will feel loss four the first time somebody asks for a form.
None of these makes headless wrong. They make it a trade rather than an upgrade, which is what the pages selling it will not say, and what you needed to know before you agreed to the project.
And if the list makes you wonder whether the move is necessary at all, that is a legitimate conclusion rather than a failure of nerve. The switching cost is separate from all of this and it is not small: what actually survives a platform move, and in what condition, is the whole of the CMS migration guide, and it is worth reading before anyone signs anything.
