A headless CMS stores your content in one place and delivers it through an API, so any front end (website, app, kiosk, whatever comes next) can pull from the same source. That’s the whole idea. The ‘head’ is the presentation layer, the templates and themes that turn content into web pages. Remove the head and you’re left with a content repository that doesn’t care where its output ends up. If your agency has proposed one and you’re not sure whether the recommendation is sound or self-serving, this piece will help you tell the difference.
How does a traditional CMS differ?
A traditional CMS bundles content management and content display into a single system. WordPress is the clearest example. You write a page in the WordPress editor, choose a theme, and the CMS generates the HTML your visitors see. Content and presentation live together, which is why WordPress powers roughly 43% of all websites: the setup is fast, the learning curve is gentle, and most marketing teams can publish without waiting for a developer.
The trade-off is coupling. Your content is tied to the way it’s displayed. Want the same product description on your website, your mobile app, and an in-store screen? A traditional CMS wasn’t designed for that. You’d copy the text, paste it into each channel, and hope nobody updates one version without updating the others.
A headless CMS breaks that coupling. Content goes in once. Wherever it needs to appear, a developer builds a front end that calls the API and pulls the content it needs. One truth, many outputs.
When does headless genuinely make sense?
We see four scenarios where a headless architecture earns its cost.
You publish to more than one channel and need consistency across them. A retail business running a website, a native mobile app, and digital signage in physical stores has a real multi-channel problem. Maintaining three separate content systems creates drift, duplication, and version-control nightmares. A headless CMS solves that by being the single source. If your content only appears on a website, this benefit doesn’t apply to you.
You need frontend performance that a traditional CMS can’t deliver. Headless architectures pair well with static site generators and modern JavaScript frameworks (Next.js, Astro, Nuxt). Pages can be pre-rendered and served from a CDN, which means load times measured in milliseconds rather than seconds. For high-traffic ecommerce or media sites where a 100ms improvement in page speed has a measurable effect on conversion, this matters. For a 20-page brochure site, it doesn’t.
Your development team wants to work in a modern stack. Developers building with React, Vue, or similar frameworks find headless systems easier to integrate with their existing tools. If you’re commissioning a complex web application rather than a content-led website, your technical team will probably push for headless because it fits the way they already work. That’s a legitimate reason, not an upsell.
You’re planning a composable architecture. Larger organisations are assembling ‘best of breed’ systems: one tool for content, another for search, another for personalisation, another for commerce. The headless CMS becomes one component in a stack where everything talks to everything else through APIs. This is a genuine enterprise pattern, and the headless CMS market is growing at roughly 22% a year partly because of it. But composable architecture is expensive, complex, and only worth the investment at a certain scale.
When is headless overkill?
More often than agencies will tell you. Here’s the honest version.
You’re building a content-led website with one audience in one language. A charity, a professional services firm, a mid-sized retailer with an online catalogue but no native app. WordPress, CraftCMS, or Shopify will do this job well, with lower build costs, lower ongoing costs, and a content editing experience that doesn’t require developer involvement for routine updates.
Your team doesn’t include developers who can maintain a separated front end. A headless CMS doesn’t generate your website. Somebody has to build and maintain that front end separately. If your entire digital operation is a marketing manager and a part-time contractor, a headless setup creates a permanent dependency on specialist developers for changes that would take five minutes in WordPress.
The agency proposing headless hasn’t explained who maintains the front end after launch. This is the question that separates a good recommendation from a self-serving one. If the agency builds you a headless site and the only people who can change the front end are that same agency, you’ve bought a dependency, not flexibility. Ask the question. If the answer is vague, the recommendation probably isn’t about your needs.
Your budget is under £30,000 / $40,000. A headless build for a mid-complexity site typically costs 40% to 80% more than a traditional CMS build because the front end has to be designed, built, and deployed as a separate project. If your total budget is tight, the extra spend on headless architecture eats into design, content, and testing, which are the things that actually determine whether the site works for your audience.
What does headless cost compared to traditional?
Costs vary by project, but the shape of the difference is consistent. We’ll use a mid-complexity business website (50 to 100 pages, some custom functionality, content managed by a non-technical team) as the reference point.
Traditional CMS build (WordPress, CraftCMS, etc.): £15,000 to £40,000 / $20,000 to $53,000 for design and build. Hosting runs £20 to £200 / $25 to $260 a month depending on traffic and the hosting provider. The CMS software itself is often free or low-cost.
Headless CMS build: £25,000 to £70,000 / $33,000 to $93,000 for the same scope because the front end is a separate development project. The CMS platform carries its own costs on top: Contentful’s team plan runs $300 / £230 a month, Sanity charges by usage starting at $15 / £12 per seat, and self-hosted open-source options like Strapi are free for the software but require server management. Hosting the front end adds another layer, typically on Vercel or Netlify, starting at £15 to £150 / $20 to $200 a month.
Ongoing costs tell a different story over time. Traditional CMS sites accumulate maintenance costs through plugin updates, security patching, and theme compatibility. Headless sites avoid some of those costs but replace them with front-end maintenance and API management. Over a three-year period, total cost of ownership for headless can be 30% to 60% higher for a standard website, though the gap narrows for multi-channel projects where headless removes duplication.
The numbers above are rough bands, not quotes. Specific pricing depends on the CMS platform, the hosting setup, the complexity of the front end, and how many integrations the project requires. But they give you the right shape: headless costs more upfront, costs more to run for a simple website, and only breaks even when the multi-channel or performance benefits are real.
Is there a middle ground?
Yes, and it’s where most projects should probably start.
Several traditional CMS platforms now offer API access alongside their standard page-rendering capabilities. WordPress has a built-in REST API. CraftCMS has a native GraphQL API. Shopify’s Storefront API lets developers build custom front ends against the same Shopify backend. These aren’t fully headless setups, but they give you API access when you need it without forcing you to build and maintain a separate front end for everything.
The practical version: you run a normal CraftCMS or WordPress website for your marketing team to manage. When a specific need arises (a mobile app, a data feed to a partner system, a custom checkout flow), a developer builds that one piece against the API. You get the flexibility where it matters without paying the headless tax everywhere.
This hybrid approach suits the majority of mid-market digital projects. It keeps the editorial experience simple, the maintenance costs manageable, and the architecture open enough that you can go fully headless later if the project genuinely demands it.
Five questions to ask if your agency recommends headless
These will tell you whether the recommendation is architectural advice or an upsell.
‘Which channels beyond the website will use the CMS?’ If the answer is only the website, ask why headless is necessary. A single-channel project rarely justifies the additional cost and complexity.
‘Who maintains the front end after launch?’ If the answer is ‘us, on retainer,’ you need to understand what that retainer costs and whether it’s a dependency you’re comfortable with. If the answer is ‘your in-house team,’ you need to know whether your team has the skills.
‘What does this cost compared to the same project on WordPress or CraftCMS?’ An agency confident in its headless recommendation should be able to show you the cost difference and explain what you’re getting for the premium.
‘Can we start with a traditional CMS and add API access later?’ If the agency dismisses this option without engaging with it, that’s a signal. The hybrid path is a legitimate choice for most projects, and a good agency will acknowledge it even if they believe headless is the better fit.
‘What’s the editorial experience like for our content team?’ Headless CMS platforms have improved their editing interfaces significantly, but most still lack the live visual preview that traditional systems provide. If your content team publishes daily and needs to see exactly what a page looks like before it goes live, this matters. Ask for a demo of the actual editing workflow, not a slide deck.
The honest answer for most organisations commissioning a website, an app, or a digital platform in 2026 is that headless is a real and maturing technology with genuine use cases, and those use cases are narrower than the pitch decks suggest. If your project fits one of the four scenarios above, headless is worth the investment. If it doesn’t, a well-built traditional CMS with API capabilities will serve you better, cost less, and leave you with more control over your own content.