Est.2016
→
∞
Headless CMS for Publishers: When It Is Worth It and When It Is Overkill
development
Headless means the content lives in one system with an API, and the presentation lives somewhere else entirely. The pitch is flexibility. The reality is that it solves one problem very well and creates several others if that problem is not yours.
The problem it actually solves
Headless is worth it when the same content has to appear in more than one place.
A publisher whose title data feeds a website, a printed catalogue, a rights portal, and a partner feed has a genuine content distribution problem. Maintaining that in four places produces four versions that disagree with each other. One structured source with an API is the correct answer.
It is also right when your content is genuinely structured rather than prose. Book records with two dozen fields, contributors as related entities, series relationships, format variants. A traditional CMS models pages; a headless CMS models data, and a book catalogue is data.
What it costs you
The most underestimated cost is that publishing becomes a technical act. In a traditional CMS an editor writes, previews the actual page, and publishes. In many headless setups the editor fills in fields, cannot see how it will look, and waits for a build.
For a team where a marketing person needs to publish a post on a Friday afternoon, that difference is not a detail. It is the difference between the site being updated and the site quietly going stale.
Preview can be solved, but it has to be built deliberately and it is often the part that gets deprioritised. If you go headless, treat editor preview as a requirement rather than a nice to have.
The second cost is that you now own the front end entirely. There is no theme, no plugin for the thing you forgot, and every feature is a development task. Search, related content, redirects, sitemaps, and structured data are all yours to implement.
When it is overkill
If you publish blog posts and book pages to one website, and that is the whole picture, headless is very likely the wrong choice. A well configured traditional CMS or a modern site builder with a content collection will do the job with a fraction of the ongoing cost, and your team can use it without help.
Rewriting a perfectly functional site as headless because the architecture is more current is the most expensive kind of tidiness.
The middle option people forget
You do not have to choose one system for everything. A common and sensible arrangement for publishers is a structured product or title database serving the catalogue, sitting alongside a straightforward CMS or site builder handling marketing pages and the blog.
The catalogue gets the structure it needs. The marketing team keeps the ability to publish without a deployment. The two connect where they need to.
How to decide
Three questions. Does the same content need to appear in more than one destination. Is your content structured data rather than pages. Do you have ongoing development capacity, not a one time build budget.
Two or three yes answers, headless is probably right. One or none, and the traditional route will serve you better and cost less every year afterwards.
