What is a headless CMS — when you need one, and when you do not
A headless CMS is not a trend but the answer to a specific problem. When WordPress is enough, and when separating content from presentation actually pays.
A traditional CMS does two jobs: it stores content and it renders that content into HTML. A headless CMS drops the second. It stores content, gives editors an interface, and serves the content over an API. How the page gets drawn is up to you.
That is where the name comes from: the body (content) stays, the head (presentation) is cut off.
What it solves, and what it does not
Headless architecture solves three concrete problems:
Publishing the same content to more than one place. Website, mobile app, in-store screen, partner API. Content lives once and each client reads what it needs. In a traditional CMS this means updating the same text in three places.
Freeing the presentation layer. You build what you want, not what the theme system allows. The performance budget is yours; no unknown plugin adds 300KB of script to the page.
Structural multilingualism. When languages are not translations but structurally different pages, plugin-based translation layers treat that as a “missing translation” and force you into one template. In headless, language is a field on the content model.
There are things it does not solve: it does not make content easier to write, it does not improve SEO by itself, and it does not reduce cost.
The real cost
The most overlooked part of headless is that you now have to build what a traditional CMS gave away free:
- Preview. How does an editor see a draft before publishing?
- Media library and image derivatives.
- Revision history and rollback.
- Role-based permissions.
- Redirect management (a 301 when a page’s URL changes).
- On-site search.
WordPress ships all of these out of the box. In headless you either pick a service that provides them (with a monthly fee) or write them yourself. Neither is free.
Preview matters most. If editors cannot see what they are writing, they stop using the system — this is where headless projects most often stall.
Decision table
| Situation | Recommendation |
|---|---|
| One language, one channel, a standard blog | Traditional CMS |
| Corporate site, content changes a few times a month | Static site + Markdown |
| Same content on web and in a mobile app | Headless |
| Five languages that differ structurally | Headless |
| Strict performance target, full control needed | Headless or static |
| Non-technical content team, no support budget | Traditional CMS |
| Product catalogue comes from an ERP | Headless |
The last row matters: if the source of truth is already another system, having the CMS render pages is an unnecessary layer.
The middle option: a static site generator
There is a commonly skipped middle ground. Content lives as Markdown files in the repository and pages are compiled to HTML at build time.
For a technical team this is the cheapest and fastest option: no database, no running server, almost no attack surface. Changes sit in version control and rolling back is one command.
The constraint is clear: whoever edits content has to use Git. If your content team is not technical, this option is out — or you add an editing interface on top, at which point you have started walking toward headless anyway.
Five questions before choosing
- Who edits the content? If it is someone non-technical, preview and a media library are not negotiable.
- How many channels consume it? With one channel, headless loses its main justification.
- Are the languages translations of each other? If not, a traditional CMS’s translation plugins will constrain you.
- How often does content change? A few times a month and static generation is enough; dozens of times a day and an editing interface is mandatory.
- Who maintains it? A headless setup means more moving parts, and parts nobody maintains decay.
Summary
A headless CMS is the right call when content goes to more than one place, or when you need full control over presentation. Chosen for a single website, it usually creates more work than it removes.
The deciding criterion is not architectural elegance. It is this: how many places does the content go, and how technical is the person editing it?
