The Short Answer
A headless CMS separates content storage from content display, connecting the two through an API. A traditional CMS does both jobs in one system. Choose headless when content must reach several destinations, when performance matters commercially, or when you expect to redesign without re-entering everything. Choose traditional when one website is the whole requirement.
Most of the material written on this subject is aimed at developers and argues about GraphQL. This piece is aimed at whoever signs the invoice.
What "Headless" Actually Means
A traditional content management system — WordPress, Drupal, Squarespace — holds your content and decides how it looks. The database and the theme ship together. When someone visits a page, the system assembles it and sends back a finished document.
A headless CMS keeps only the content. It has no opinion about presentation. Your website requests what it needs over an API and renders it however it likes. The "head" that was removed is the display layer.
The consequence that matters commercially: your content and your design stop being welded together. You can rebuild one without touching the other.
Where The Difference Shows Up In Practice
Four situations expose the gap. Outside them, the two feel much the same to whoever is publishing.
- Publishing to more than one place. Website, mobile app, in-store display, partner feed. A traditional CMS treats everything beyond its own pages as an export problem. Headless treats them all as equal consumers of the same content.
- Redesigning without re-entering content. With headless, a redesign replaces the front end and leaves the content untouched. With a page-builder site, a redesign frequently means rebuilding pages by hand, because layout and copy were stored together.
- Performance under load. Headless front ends are usually pre-rendered and served from a CDN, which changes the cost profile of a traffic spike. This matters if you run campaigns, launches, or anything seasonal.
- Editorial workflow at scale. Structured content, defined fields, and predictable output are what stop a large site drifting into inconsistency. Below roughly thirty pages this is rarely the binding constraint.
What Each Actually Costs
Build costs run 20 to 60 percent higher for headless because the front end is written from scratch rather than configured from a theme. Running costs typically fall: static hosting is inexpensive, and there are no plugin licences. The decisive cost is people — headless needs a developer for changes a traditional CMS lets a marketer make alone.
Where businesses get the sums wrong is in counting only the build. The real comparison, across three years:
- Traditional. Lower build, plugin licences, more maintenance, higher risk of a rebuild when the theme is abandoned or a major version breaks compatibility.
- Headless. Higher build, cheaper hosting, fewer moving parts to break, but developer time for anything structurally new.
Neither is universally cheaper. A brochure site that never changes is cheapest on a traditional CMS forever. A site redesigned every two years is usually cheaper on headless by the second redesign. Our breakdown of annual website running costs covers the ongoing side in detail.
Three Situations Where Headless Is The Wrong Answer
Headless is oversold, and the honest cases against it are these.
- You need to launch in two weeks on a small budget. The theme ecosystem exists precisely for this. Buying speed with someone else's design work is a legitimate decision.
- Nobody on your side can brief a developer. If every change requires a technical intermediary and you have no relationship with one, you will find the site frozen within a year.
- Your site is genuinely one brochure. Five pages, changing twice a year. The flexibility you are paying for will never be exercised.
The same reasoning applies to bespoke work generally — we set out the fuller argument in custom website vs template.
The Question That Settles It
Ask what happens to your content the next time you redesign. If the answer is that somebody re-types it into a new theme, you are paying the headless premium already — just in labour, later, and without the benefits. If the answer is that it carries over untouched, your current setup is working.
The second question is who needs to change what, and how often. Marketing teams that publish weekly and need to reshape pages themselves are poorly served by an architecture that routes every layout change through an engineer. Teams that publish structured content — articles, products, case studies — into fixed templates are well served by it.
A Practical Middle Path
You do not have to pick a side permanently. Two hybrids work well:
- Structured content on a traditional CMS. Use custom fields rather than page builders, so content stays clean and portable. This is the cheapest possible preparation for a future migration.
- Headless for the parts that need it. A marketing site on a traditional CMS with a headless product catalogue is a common and sensible arrangement.
Whichever way you go, settle ownership at the start. Who holds the CMS account, the repository, and the hosting is a question that costs nothing to answer on day one and a great deal to answer later — the same trap described in who owns your website.
How We Decide
We build most client sites on Next.js with a headless CMS, and the stack reasoning is set out in our Next.js and headless CMS guide. But we have also talked clients out of it — when the site was small, the budget was tight, and the flexibility would have gone unused. Architecture that outruns the organisation using it is not a good outcome.
If you are weighing this for a specific site, tell us what you publish and how often, and we will tell you which side of the line you fall on — including when the answer is to keep what you have.