Headless CMS or Traditional: Which One Are You Actually Ready For?
Headless is a delivery decision, not a storage one. It buys front-end freedom and a second surface, and it charges you in preview, editing experience and front-end capacity you have to already have.
On This Page
Somebody on the team has asked for a headless CMS. Ask what they mean by it and you will get one of three answers: the site should be faster, the editors should stop breaking layouts, or the content needs to feed an app as well as a website. Those are three different problems. Headless solves one of them cleanly, one of them partly, and one of them not at all.
The word names one thing only: the CMS supplies content and does not render your pages. That is the whole definition. It says nothing about where the content is stored, nothing about who is allowed to publish, and nothing about whether your editors will still be able to see what they are doing on Tuesday afternoon.
Which is why headless vs traditional CMS arguments go in circles. Two decisions are being made at once and only one of them gets discussed. Delivery is one axis. Storage is the other, and our parent company has written about that half directly in Git-based or API-based content storage. Separate them and the shortlist shortens considerably.
What follows is what headless genuinely buys, what it costs and where that cost lands, the team it quietly assumes you have, and a readiness test you can run in an afternoon.
Two decisions, dressed as one
Delivery asks whether the CMS produces the page a visitor sees. Storage asks where the words physically sit. Those axes are independent, which means there are four positions available, and most evaluations behave as though there are two.
A traditional platform serving its own themed pages is one corner. The same platform with its templates ignored, feeding a separate front end over its REST API, is a different corner entirely, and it is a common and sensible arrangement that almost never appears on a shortlist because it has no marketing category. A hosted content service feeding a built site is a third. Files in a repository, rendered at build time, is the fourth.
Underneath both axes sits the decision that outlives them, which is how the content is modelled. A page stored as one enormous rich-text field is trapped in whatever design it was pasted into, whichever architecture holds it. Fields that survive the next redesign is the piece to read first, because a good model makes this choice reversible and a bad one makes it permanent.
What headless genuinely buys you
Four things, and they are real. It is worth being precise about them, because the reasons people give for wanting headless are usually not on this list.
- A front end with no ceiling. You are no longer bounded by a theme system, a plugin that injects markup, or a template language designed in a different decade. What you can build is what you can code.
- More than one surface, without a second pipeline. A website, an application, a screen in a shop and a partner feed can consume the same entries. This is the strongest argument in the list, and the least frequently the actual reason.
- Release cycles that stop colliding. The front end ships when it is ready and the content system upgrades when it needs to, instead of both being held hostage by one deployment.
- A smaller public attack surface. When the editing application is not the thing serving traffic, the administration interface stops being a public door with a login form on it.
The multi-surface case deserves the weight. If there is genuinely a second consumer of this content, headless stops being an architectural preference and becomes the obvious answer. If there is only a website, and the second surface is something a stakeholder mentioned once, you are paying for optionality nobody has costed. Whether that second surface should exist at all is worth settling first, and native app, web app, or neither is where we set out how we decide it.
What it does not buy
Three things get attributed to headless that it does not supply. Speed is one: rendering pages ahead of time is available in most modern stacks, and a decoupled front end assembled carelessly in the browser can be slower than the theme it replaced. Editorial discipline is another, because nothing about an API prevents somebody pasting a formatted table into a rich-text field. Governance is the third, since roles and approval states become things you specify rather than settings you switch on.
What it costs, and where the cost lands
The costs are real too, and they land on people who were not in the evaluation meeting. That is the pattern worth watching: the team choosing the architecture is rarely the team paying for it daily.
Preview is the hard part, every time
In a traditional CMS, preview is free and exact, because the thing rendering the preview is the thing rendering the page. Decouple them and preview becomes a feature somebody has to build: a draft-aware route, a secure token, a way to see an unpublished entry inside the real layout, and a way to see it on the page it will actually appear on rather than in an abstract card.
It is buildable. It is also the most common source of quiet unhappiness after a headless launch, because it is never quite finished and it degrades every time the front end changes. If you take one warning from this piece, take that one. The related workflow question, where drafts live and what is allowed to stop them, is covered in where drafts live and what stops them.
The editing experience is now yours
In a traditional platform, the editing interface arrives finished, along with the media library, the revision history, the role system and a plugin for whatever you forgot. Go headless and every one of those becomes a decision, a configuration, or a build. The front end is not a website any more. It is an application you maintain, with the release process, dependency upgrades and support implications that come with one.
| Concern | Traditional | Headless |
|---|---|---|
| Who renders the page | The CMS, through its template layer | Your application, from an API or a build |
| Preview | Native, exact, free | Something you build and keep building |
| A new page type | Often a configuration change | A model change plus front-end work |
| Front-end freedom | Bounded by the theme system | Whatever your team can build |
| Second surface | An add-on, an export, or a plugin | The default assumption |
| Editor onboarding | Familiar to most marketing teams | Entirely dependent on what you built |
| Fixing a broken layout | A theme developer, sometimes same day | Your front-end queue and release cycle |
| Ecosystem | A plugin for most requirements | Libraries, plus code you own |
Any architecture handles the launch. What separates them is what happens six months later when marketing wants a page type nobody planned. In a traditional platform that is often an afternoon. In a decoupled setup it is a model change, a front-end component, a preview update and a release. Neither answer is wrong. Only one of them is usually the one people assumed they were buying.
The team headless quietly assumes
Every headless architecture assumes a front-end capability that exists continuously, not once. Not a launch team, not an agency engagement that ends in March, but somebody who will still be there when a dependency needs upgrading and the preview route breaks on a Friday.
Our position is unpopular in engineering rooms and we will defend it anyway: if your front end is maintained by whoever happens to be free, a traditional platform is the safer choice, and it is not a compromise. It is a correct reading of the constraint you actually have. Architecture that assumes capacity you must borrow becomes a liability the moment the borrowing stops.
Headless also removes the governance you inherited. Roles, approval states and the ability to genuinely refuse a publish are platform features in a traditional CMS and design work in a decoupled one. Decide early who can stop a page from going out, because rebuilding that later is expensive and nobody budgets for it. Who can refuse to publish goes through the mechanics of designing those gates deliberately.
Headless does not remove work. It moves it from a vendor’s roadmap onto your backlog, and it stays there.
A readiness test, in six questions
Answer honestly, in order, about the next two years rather than the next two months. Two or more no answers means the traditional route is the better decision today, and today is the only decision you are making.
- Is there a second consumer of this content, funded and dated? An app, a kiosk, a partner feed, a second brand site. Not a wish, not a slide. Something with a date on it.
- Do you have front-end capacity that persists? Somebody who owns the front end next year, by name or by retained arrangement. If the answer names a project rather than a person, the answer is no.
- Can you build and keep a real preview? Drafts visible in the actual layout, on the actual page, without a deploy. This is a build item, so put it in the estimate rather than the assumptions.
- Is your content modelled, or pasted? Typed fields with names and rules can be rendered anywhere. A wall of stored markup can only be reformatted by hand, and it will punish you in either architecture.
- Do your editors rely on anything the platform gave them free? Scheduling, localisation, workflow states, a media library people can search. Each one is now scope.
- Does the front end need freedom the theme genuinely cannot give? Sometimes yes, emphatically. Often the honest answer is that the current site is slow for reasons a rebuild on the same platform would fix.
The test is deliberately conservative, and one override is worth naming. If the front end is already an application, maintained by a team that ships it every week, most of the costs above are paid and the questions answer themselves. In that case, keeping content locked inside a template system is the expensive option, and the test is confirming something you already knew.
The middle options nobody shortlists
The debate is usually framed as two products, and the useful answers tend to sit between them. Three are worth naming.
The first is a traditional platform used headlessly for one surface only. Editors keep the interface they know, the website keeps native preview, and the app consumes the same content over an API. You carry two rendering paths, which is a genuine cost, but you carry it for a stated reason instead of on principle.
The second keeps content in the repository and puts a structured workspace in front of it, so editors work in forms rather than in files. A workspace like Acrosite takes that shape: it generates the required files, commits them to GitHub and triggers the configured deployment. Delivery is headless, storage is version control, and the editing experience is an ordinary application. The third option is staying where you are and fixing the content model, which resolves more complaints than any migration does.
Whichever direction you take, two questions decide how much it hurts: how the archive moves, and what happens when you leave again. Migrating ten years of pages covers the first. What happens to your content when you leave the CMS covers the second, and it should be asked during the trial rather than during the argument.
What the choice changes for everyone else
This decision reaches further than the engineering team. It sets how quickly a landing page can exist: hours, or a sprint. It sets whether content and organic growth work can ship a metadata fix without a release. It sets whether a writer can see their own draft in context, which is the difference between editing and guessing.
It also sets who gets blamed. In a traditional platform, a broken layout is a support request. In a decoupled one it is a ticket in a queue with other tickets, and the marketing team gradually learns to stop asking. That shift is rarely discussed during selection, and it is consistently what people describe when they say the new system is worse, even while every technical measure says otherwise.
What we would choose, and when
For a marketing site with one surface, a small team and no permanent front-end engineer: traditional, modelled properly, with the editing experience treated as the deliverable it is. That is not a lesser choice. A well-run website build on a familiar platform beats a decoupled one that nobody maintains.
For a genuine second surface, a front end with requirements a theme cannot meet, or a team already shipping application code every week: headless, with preview scoped as a real feature and the editing experience budgeted before the front end. Teams that fund the visitor-facing build and leave the editor interface to the last sprint end up with a fast site their own colleagues avoid using.
And the condition that reverses all of it: if the complaint is that publishing is slow, check whether the bottleneck is the software or the approval habit before you buy anything. New architecture does not fix a queue with one person in it. If you would like an outside read on which of the two you have, tell us what you are running and who publishes on it.
Common questions.
What does headless CMS actually mean?
A headless CMS stores and manages content but does not render the pages a visitor sees. Your own application requests the content over an API, at build time or on request, and decides how it looks. The term describes delivery only. It says nothing about where content is stored, who may publish, or what the editing interface is like, which is why two headless products can feel completely different.
Is a headless CMS faster than a traditional one?
Not automatically. Headless removes a ceiling rather than adding speed, because you control the whole front end and can render pages ahead of time. A carelessly built decoupled front end can easily be slower than a well-tuned traditional site. Performance follows from what you build, how much of it runs in the browser and how pages are cached, not from the architecture label.
Can WordPress be used as a headless CMS?
Yes. WordPress exposes content through its REST API, so a separate front end can consume entries while editors keep the interface they already know. The trade is that preview, some plugin output and anything relying on themes now need handling in your application. It is a common and reasonable middle option, and it rarely reaches shortlists because it is not sold as a category.
Why is preview so difficult with a headless CMS?
Because the system holding the draft is no longer the system drawing the page. Preview has to be built: a draft-aware route in the front end, a secure token, and a way to render unpublished entries inside the real layout. It works well when it is scoped as a proper feature, and it degrades whenever the front end changes, so it needs an owner rather than a one-off task.
Does a headless CMS require a bigger team?
It requires a front-end capability that continues after launch, which is different from a bigger team. Someone has to maintain the application, upgrade dependencies, repair the preview route and build each new page type. If that responsibility falls to whoever is available in a given month, a traditional platform will serve the organisation better, because more of the work stays with the vendor.
When is a traditional CMS still the better choice?
When there is one surface to serve, a small editorial team, and no permanent front-end engineer. In that situation the native preview, the built-in roles, the media library and the plugin ecosystem are doing work you would otherwise fund yourself. Choosing it deliberately is a correct reading of your constraints rather than a compromise, provided the content underneath is still modelled as structured fields.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.