Headless vs traditional CMS
Separating content from presentation, and what it costs.
Headless is frequently sold as the modern answer and bought as an identity rather than a decision. It is a genuinely better architecture for some situations and a way of making a brochure site expensive for others.
Start with the shape
of the problem.
Headless is frequently sold as the modern answer and bought as an identity rather than a decision. It is a genuinely better architecture for some situations and a way of making a brochure site expensive for others.
The trade is straightforward once stated plainly. Headless gives you structured content that can serve several surfaces, a front end unconstrained by the CMS, and a clean performance ceiling. It costs you the thing editors care about most: seeing their change in place before publishing it, without a developer nearby.
The question we ask first is never technical. It is how many surfaces the content has to feed, and how confident the people who publish it are.
| Criterion | Headless CMS | Traditional CMS | Edge |
|---|---|---|---|
| Editor experience | Structured and disciplined, but preview and in-place editing need deliberate engineering to feel natural. | Edit in context, see it immediately. Familiar to almost everyone who has published a page. | Traditional CMS |
| Multi-channel reuse | One content model serving web, app, email, kiosk and partner feeds without duplication. | Content is coupled to page templates. Reuse means copy-paste and drift. | Headless CMS |
| Performance ceiling | You own the front end entirely — static generation, edge delivery, no theme weight. | Achievable, but plugins, themes and server rendering set a lower practical ceiling. | Headless CMS |
| Initial build cost | Higher. Content modelling, a separate front end and preview infrastructure are all real work. | Lower. A great deal is solved before you start. | Traditional CMS |
| Ongoing maintenance | Two systems to keep current, but far less plugin surface and a smaller security footprint. | One system, larger attack surface, and plugin churn that never quite stops. | Line ball |
| Publishing independence | Content changes are free; new layouts usually need a developer. | Editors can build new page types themselves — which is a strength and, eventually, a mess. | Line ball |
| Hiring and handover | Needs front-end engineering capability in-house or on retainer. | Enormous talent pool at every level and price point. | Traditional CMS |
| Vendor lock-in | Content lives in a structured, exportable API. Swapping the front end does not touch the content. | Content is entangled with themes, plugins and shortcodes. Export is rarely clean. | Headless CMS |
- The same content must serve a site, an app and at least one other surface
- Performance is a competitive requirement rather than a preference
- You have front-end engineering capacity, in-house or retained
- Content is genuinely structured — products, locations, courses, people
- You expect to redesign the front end without re-migrating the content
- One website, one audience, and a marketing team that publishes daily
- Editors need to build and rearrange pages without a developer
- Budget is better spent on content and campaigns than on architecture
- There is no engineering capacity to own a separate front end
- The site is largely conventional pages rather than structured records
Our honest
recommendation.
If you run one website with a publishing team that needs autonomy, a traditional CMS handled well beats a headless build handled adequately — and it will cost less to run. Most of the performance gap can be closed with caching, image discipline and plugin restraint.
Go headless when content genuinely feeds more than one surface, when structured records are the point, or when the front end has performance and design requirements a theme cannot meet. Budget properly for preview: a headless build that editors cannot preview in context is the single most common cause of regret we see.
Headless WordPress and similar hybrids are a legitimate middle path. Editors keep the interface they know, you own the front end, and you accept one extra moving part in exchange. We recommend it more often than either pure position.
What teams ask next.
Only indirectly. It removes the theme weight that drags on Core Web Vitals and gives you complete control over markup, metadata and rendering strategy — all of which help. But a well-run traditional CMS with disciplined caching and images ranks perfectly well, and a headless build with client-side-only rendering can rank worse than either. Server-render or prerender your pages and the architecture question largely stops mattering.
Yes, but it has to be built. Draft preview against a live front-end deployment is a first-class requirement in any headless project we run, because the alternative — publishing blind and checking afterwards — is the thing that makes teams resent the architecture.
Expect a meaningfully higher initial build: you are paying for content modelling, a bespoke front end and preview infrastructure instead of inheriting them. The cost tends to converge over three to five years, because plugin maintenance and theme upgrades are a recurring tax the headless side does not pay.
No. The most reliable route is incremental: model and migrate one content type, serve it headlessly on one section of the site, and expand once editors are comfortable. Big-bang CMS migrations fail for the same reason big-bang anything fails.
Web development
Custom, WordPress and Shopify builds for teams who need a site that sells, not just one that exists.
Website redesign
A structural rethink of a site that has outgrown its story, its stack or its conversion rate.
Speed & performance optimisation
Core Web Vitals, bundle size and server response times taken seriously enough to move revenue.
Database design & development
Schemas, queries and migrations that stay fast and honest as the data grows.
Rather not decide in the abstract?
Send us the situation. We will tell you which we would choose in your position, including when that answer earns us less.