A headless CMS separates where content is stored and managed from where it is displayed. That is the whole idea, and it is a genuinely good idea for organisations that need to publish the same content to more than one place. It is also, for a large number of UK businesses running a single website, a more expensive way to end up with the same outcome and a marketing team that can no longer add a page without a developer.
This guide is the decision, not the explanation. If you want a primer on what headless architecture is and how API-first delivery works, we covered that in our guide to headless CMS and when your business needs it. What follows is the harder question: what you actually give up when you decouple content from presentation, what the three-year cost genuinely looks like for a UK SME rather than an enterprise, where the break-even sits, when a traditional CMS remains the correct answer, and how to tell whether the benefit you are being sold is a property of headless architecture or a property of finally modelling your content properly — which you can do either way.
What actually changes when you go headless
The architectural description is simple enough: content lives in a repository and is exposed through an API, and a separate front-end application requests it and renders it. What that produces operationally is less often spelled out, and it is where most disappointment originates.
You now run two systems with a contract between them. Before, one platform owned content and rendering and the vendor was responsible for them working together. Now you have a content platform, a front-end application, and an API contract joining them. When something breaks, the first question is which side. This is entirely manageable and it is not free — it is a permanent addition to the surface area you maintain.
Editors lose what-you-see-is-what-you-get by default. This is the single most underestimated consequence. In a traditional CMS the editor works in something resembling the page. In a headless CMS the editor fills in structured fields and the result appears somewhere else, rendered by an application the CMS knows nothing about. Preview has to be deliberately built. In-context editing has to be built or bought. Several modern platforms have made real progress here and none of them give it to you for nothing.
Front-end change becomes a development task. In a traditional CMS with a page builder, a marketer can assemble a new landing page on a Tuesday afternoon. In a headless setup, they can create content in any shape the model already supports — and a genuinely new layout or page type needs a developer. If your marketing team currently ships pages without involving anyone technical, headless removes that capability unless you deliberately rebuild it.
Content modelling becomes an upfront decision with a long tail. Traditional platforms let you defer structure indefinitely by dropping everything into a rich-text body. Headless forces the model early, which is a real benefit and a real risk: a model that fits badly is expensive to change once there is content in it and a front end depending on it.
Search visibility and accessibility become your responsibility rather than a plugin’s. Metadata, canonical tags, sitemaps, redirects and structured data all arrive free-ish in a mature traditional ecosystem. In headless they are things your front end must implement. Done properly the result is usually better. Done carelessly — particularly with client-side-only rendering — it is materially worse.
Before evaluating any platform, count your delivery channels. Not planned ones — ones that exist, funded, with an owner: the website, a mobile app, in-store screens, a partner data feed, an email system pulling content programmatically. If the honest count is one, the primary benefit of headless architecture does not currently apply to you, and any business case has to rest on performance, security or editorial structure instead. Those are legitimate arguments. They are also arguments that a well-structured traditional CMS behind a CDN can often answer at a fraction of the cost.
CMS architecture in UK businesses — the numbers
The figures below reflect what we see across UK organisations of 20 to 500 staff commissioning or rebuilding websites. They describe the SME and mid-market band rather than enterprise or publishing businesses, where the economics differ substantially.
The first and third figures together are the whole argument. Roughly three-quarters of UK SME websites publish to one place, and headless architecture earns its additional cost principally by serving several. That does not make headless wrong for a single-channel business — there are other reasons to choose it — but it means the headline justification has been removed and something else has to carry the case.
The build multiple deserves explanation, because it is not vendor greed. In a traditional build, a substantial part of the presentation layer arrives with the platform or a theme, and the project configures and styles it. In a headless build, the entire front end is bespoke: every template, every component, every state, plus preview, plus the deployment pipeline. You are commissioning a web application rather than configuring a website, and web applications cost what they cost.
The fourth figure is the one that predicts editorial unhappiness. Two in five headless implementations we look at have shipped without a working preview, meaning the people who use the system every day cannot see what they are publishing before it is live. It is almost always descoped late in the project when budget is tight, on the reasonable-sounding basis that it is not user-facing. It is the feature the actual users need most.
Where the architecture decision goes wrong
The grid below groups the recurring failures we see in UK CMS projects of both kinds. The badges reflect how much each issue costs to live with or unwind, rather than how often it occurs.
The second row of the first card is the pattern worth naming explicitly, because it is so common and so avoidable. An organisation finds its website hard to maintain: content is inconsistent, the same product description exists in nine slightly different forms, nothing can be reused, and every page is a bespoke slab of rich text. That is a content modelling problem. Headless architecture forces you to solve it, which is why re-platforming often does help — but the improvement came from the modelling, not the architecture, and the modelling was available in the existing platform at a fraction of the cost.
The developer capacity row is the one that determines whether a headless site is still working in three years. A headless site needs somebody able to deploy it, keep dependencies current, and build a new page type when marketing needs one. Organisations without in-house capability need a retained arrangement with a development partner, and that ongoing cost belongs in the business case at the outset. A headless site with no available developer degrades into a site nobody can change.
On the third card, the residency row is rated lower for project risk but should not be skipped. Your content platform stores your content and, depending on what you collect, possibly personal data. Knowing which region it is stored and processed in, what the vendor’s sub-processor position is, and what your exit looks like is ordinary diligence rather than a specialist concern.
Where the build budget actually goes
The chart below shows how effort distributes across a headless build for a UK SME marketing site, as a share of total project cost. It is worth reviewing against a traditional build, where the presentation layer arrives substantially complete and the project spends its budget differently.
A third of the budget going on front-end templates and components is the defining economic fact of headless delivery, and it is the line that does not exist in comparable form on a traditional build. It is also the line most likely to expand, because a component library is only finished relative to the designs it was asked to support, and the first request for a layout nobody anticipated arrives about a fortnight after launch.
The eleven per cent on editorial preview is the figure to protect. It is the line most often cut when the project runs over, it is invisible to anyone approving the budget, and removing it is what produces the forty-one per cent of implementations whose editors are publishing blind. If budget pressure arrives, cut a page template and keep the preview.
The five per cent on search and redirect plumbing looks trivial and is where the most damaging single mistake lives. A rebuild that does not carry forward its redirect map loses accumulated search equity, and a front end that renders content only in the browser can be effectively invisible to some crawlers and assistive technology alike. Both are entirely preventable at this cost and expensive to recover from afterwards — the mechanics are covered in our guide to website migration without breaking links.
Three-year cost for a UK SME
The table below models total cost of ownership over three years for a mid-sized UK marketing site — roughly 60 to 200 pages, a blog, forms, and two or three integrations. Figures are indicative, exclude VAT, and assume UK agency rates. The comparison assumes equivalent design ambition, because comparing a bespoke headless build against a template-based traditional build is not a comparison of architectures.
| Cost line | Traditional CMS | Headless CMS | Note |
|---|---|---|---|
| Initial build | £14,000–35,000 | £30,000–75,000 | Entire front end is bespoke in headless |
| Platform licensing, 3 years | £0–3,000 | £0–40,000+ | Self-hosted is free; SaaS tiers step sharply with seats and records |
| Hosting and delivery, 3 years | £1,800–9,000 | £700–7,000 | Static and edge delivery is often cheaper |
| Maintenance and updates, 3 years | £4,500–15,000 | £9,000–30,000 | Dependency currency and framework upgrades are ongoing |
| Indicative three-year total | £20,000–62,000 | £40,000–150,000+ | Overlap exists at the edges; the centres are far apart |
The honest summary is that for a single-channel UK SME marketing site, headless usually costs roughly twice as much over three years to produce a comparable result. That is not an argument against it. It is an argument that the additional spend needs a purpose, and “it is the modern approach” is not one. Where the second channel exists, the calculation inverts quickly, because the marginal cost of delivering existing structured content to a new surface is a fraction of building a second site.
Two lines deserve a closer look. Platform licensing has the widest range in the table because the model varies enormously: self-hosted open-source options cost nothing in licence and something in operational effort, while hosted platforms price on seats, records, API calls or environments, and the step between tiers can be abrupt. Model your licence cost at three years of expected content volume and editor count, not at today, because outgrowing a tier mid-contract is a common and unwelcome surprise.
Maintenance is higher for headless for an unglamorous reason: a bespoke front end has dependencies, and dependencies need keeping current. A traditional platform concentrates that burden on the vendor and the plugin ecosystem, which brings its own problems, but does mean a site can sit largely untouched for a year without accumulating security debt in the way a neglected application front end does. Broader build-cost context sits in our guide to website design cost in the UK.
What a headless build actually involves
The sequence below is a realistic headless delivery for a UK SME marketing site. The ordering matters: content modelling before design, and preview treated as a first-class deliverable rather than a late addition.
Roughly nineteen weeks for a mid-sized site with an agency and an engaged client. The phase that most often slips is migration, because content never fits the model as neatly as the model suggested. The phase that most often gets cut is preview, and cutting it is the decision most likely to be regretted.
A comparable traditional build for the same site typically runs ten to thirteen weeks, with the difference concentrated almost entirely in the front-end and preview phases. That time difference is itself a cost worth counting, particularly where a site rebuild is blocking a campaign or a rebrand.
The two architectures side by side
The comparison below highlights the traditional column, and the reason needs stating plainly: for the roughly three-quarters of UK SMEs publishing to a single channel with a marketing team that expects to build its own pages, a well-structured traditional CMS is still the more common correct answer. The highlight marks the better default for that majority, not a judgement that headless is inferior. Where the multi-channel or performance drivers genuinely exist, the right column wins decisively and the rest of this guide explains how to tell.
Traditional CMS
Content and presentation in one platform
Headless CMS
Content via API, presentation separate
The two rows that decide most real cases are the second and the sixth. If your marketing team currently creates pages without a developer and values that, headless takes it away unless you invest specifically in preserving it — and preserving it properly costs a meaningful share of the build. If you have no in-house or retained development capacity, a headless site becomes something nobody can change within about eighteen months, which is a worse outcome than a slightly dated traditional site that anyone can edit.
The plugin sprawl risk on the traditional side is real and should not be waved away. A mature traditional site accumulates extensions, each an independent maintenance and security dependency, and that is the genuine long-term weakness of the model. The mitigation is discipline about what gets installed rather than a change of architecture, but organisations that have already lost that discipline sometimes find re-platforming is the practical way to reset it.
Notice that performance does not appear as a row. That is deliberate: both architectures can be fast and both are commonly slow, and the determining factors — image handling, caching, third-party scripts, render-blocking resources — are largely architecture-independent. A traditional site behind a CDN with disciplined asset handling will outperform a carelessly built headless site. We cover what actually moves the numbers in our guide to Core Web Vitals and website speed.
Headless readiness — where most UK SMEs sit
Combining the decision factors gives an indication of how well placed an organisation is to get value from headless architecture specifically. A low score is not a criticism of the business — it is a signal that the traditional route is likely to serve it better.
A score around thirty is the normal and appropriate position for a single-channel business. It breaks down predictably: channel count scores low because there is one, development capacity scores low or moderate because most SMEs have no in-house front-end capability, content reuse scores low because content was authored per page rather than as reusable structures, and editorial tolerance for a fields-based authoring experience scores low because the team is used to a page builder.
What raises the score is rarely a decision to adopt headless. It is the arrival of a genuine second channel, the hiring or retaining of development capacity, or a shift to design-system-driven delivery across several properties. Organisations sometimes reach a high score gradually and only then find that the architecture question has answered itself.
This is the one benchmark in our series where a low score should generally be left alone. Elsewhere a thirty means a gap to close; here it usually means headless is not currently the right investment, and the money is better spent on content structure, performance and accessibility within the platform you have. The organisations that most regret going headless are the ones that scored around thirty and treated the score as a challenge.
Most of the benefit is content modelling, and it is portable
This is the point that reframes the decision more than any cost comparison. When organisations describe what improved after moving to headless, the answers are strikingly consistent: content is consistent, things can be reused, the same product description appears identically everywhere, editors know which fields to fill in, and translations are manageable. Almost none of that is a property of API delivery. All of it is a property of having modelled content as structured data rather than as pages of formatted text.
Structured content means separating what a thing is from how it looks. A case study is a set of fields — client, sector, challenge, approach, outcome, quotes, related services — not a slab of rich text with headings in it. Once modelled that way, it can be rendered as a full page, summarised in a listing, pulled into a proposal, syndicated to a partner, or reformatted entirely without touching the content. That is the capability people buy headless for.
And it is available in every mature traditional CMS. Custom content types, defined field sets, relationships between entities, reusable blocks and component-based page assembly are all standard features of the major traditional platforms, and have been for years. They are simply not the default, because the default is a body field that accepts anything, and the default is what most sites use.
The practical implication
Before committing to a re-platform, try modelling your content properly in the platform you already have. Pick the two or three content types that matter most, define them as structured types with real fields, and rebuild their templates to render from those fields. If that solves the problem — and for single-channel businesses it frequently does — you have obtained the benefit for a small fraction of the cost and kept the editorial experience your team already knows.
If it does not solve the problem, the exercise is not wasted. You now have a content model, validated against real content, which is the artefact a headless project needs most and the phase it most often rushes. Either way the modelling work comes first, which is why the build timeline above puts it before platform selection rather than after.
Benchmarks — what UK SME websites actually have
The figures below reflect how often each capability is present across UK organisations of 20 to 500 staff, across both architectures. They are useful for deciding whether your problem is architectural or something considerably cheaper to fix.
Capability presence in UK SME websites
Read the second and fifth rows together and a pattern emerges that should give any prospective headless buyer pause. Twenty-four per cent are genuinely multi-channel, which is the condition headless exists to serve. Forty-seven per cent have a CDN, which is one of the cheapest performance interventions available and is missing from over half. If a business is considering a five-figure re-platform for performance reasons while running without edge caching, the sequencing is wrong.
The structured-content row at twenty-nine per cent is the number that most predicts whether a re-platform will feel transformative. Organisations at twenty-nine per cent will experience enormous improvement from modelling their content — and they will attribute it to whatever platform they happened to be moving to at the time.
The bottom two rows are worth acting on regardless of architecture. Seventeen per cent testing accessibility with assistive technology is low given that WCAG conformance is a legal requirement for UK public sector bodies and an expectation in much of the private sector procurement chain; the practical approach is in our guide to website accessibility compliance. Fourteen per cent maintaining a redirect map is the reason so many rebuilds lose search visibility for reasons nobody connects to the rebuild.
The number that settles most cases
If one figure decides whether headless architecture is likely to pay for itself, it is how many delivery channels genuinely consume your content. Everything else in the business case is secondary, negotiable, or achievable more cheaply another way.
Seventy-six per cent publishing to one place means that for roughly three businesses in four, the central justification for headless architecture is absent. This is not a claim that those businesses have made a mistake if they have gone headless — there are secondary reasons that can carry a case — but it does mean the case has to be made on those secondary grounds explicitly rather than by reference to multi-channel benefits that will not materialise.
Be strict about what counts as a channel. A responsive website viewed on a phone is one channel. A website plus a separate native mobile application consuming the same content is two. A website plus digital signage in branches is two. A website plus a partner receiving a structured product feed is two. A website plus a planned app that has no budget, no owner and no date is one, and planning decisions built on the hypothetical second channel are the most reliable route to paying twice.
Where the count genuinely is two or more, the economics change fast and in headless favour. The marginal cost of serving existing structured content to an additional surface is small, whereas doing the same from a traditional platform typically means either a second build or an awkward API layer bolted on afterwards. At three channels the argument is usually settled before cost is discussed.
The middle paths most buyers are never shown
The decision is routinely presented as binary, and it is not. Three intermediate options cover a substantial share of real UK SME requirements and are worth evaluating before committing to either extreme.
Structure and cache what you have
Model your content properly in the existing platform, put a CDN in front of it, tighten image handling and remove accumulated plugins. For a single-channel business with a performance or consistency complaint, this addresses the actual problem at perhaps a tenth of a re-platform cost and keeps the editorial experience intact. It is unglamorous and it is frequently the correct recommendation.
Decoupled or hybrid mode
Several traditional platforms can serve content through an API while retaining their own rendering and editing experience. That means the website continues to be produced by the platform your editors know, and a second channel — an app, a feed, a kiosk — consumes the same content through the API. You gain the multi-channel capability at the point you need it without rebuilding the website, and you avoid the editorial regression. For a business acquiring its second channel, this is often a better first move than a full re-platform.
Headless with a visual editing layer
If headless is the right destination, several platforms now offer genuine in-context or visual editing rather than bare field forms. It costs more, both in licence and in build, because the front end has to cooperate with the editing layer. It also removes the objection that sinks most headless implementations in the eyes of the people using them daily. If you are going headless with a non-technical editorial team, treat this as a requirement rather than an enhancement.
The broader point is that architecture should be the last decision rather than the first. Establish the channel count, the editorial requirements, the performance targets and the available development capacity, and in most cases the architecture is then implied rather than chosen. Buyers who start from the architecture end up reverse-engineering requirements to fit it, and the requirements lose. The comparison across hosted and custom approaches more generally sits in our guide to WordPress against Shopify against custom development.
Lock-in and what leaving actually costs
Every CMS is a commitment, and the shape of the commitment differs between the two architectures in ways worth understanding before signing rather than after.
Traditional platform lock-in
The content is usually retrievable — mature platforms have export routes and the database is accessible — but the presentation layer is not portable at all. Themes, templates and page-builder layouts are platform-specific, so leaving means rebuilding the front end from scratch. The deeper lock-in is the extension ecosystem: a site depending on a dozen plugins for forms, memberships, events and commerce has a dozen behaviours to reproduce, several of which nobody has documented. The practical effect is that leaving a traditional platform is a rebuild, and organisations therefore tend to stay a long time.
Headless platform lock-in
Superficially lighter and in one respect genuinely so: the front end is yours, written against an API, and survives a change of content platform. Content is normally exportable as structured data, which is a considerably better position than exporting formatted pages. But two couplings are easy to underestimate. The first is schema coupling: your front end queries a specific content structure in a specific query language, and a different platform exposes a different shape, so the data layer needs rewriting even though the components do not. The second is platform-specific features — visual editing integrations, asset transformation pipelines, workflow behaviour — which are exactly the features you chose the platform for and exactly the ones with no portable equivalent.
What to check before committing
Ask any platform three questions. Can you export all content, including assets and their relationships, in a documented structured format without professional services involvement? Is the query interface standard enough that a migration would be a data-layer rewrite rather than a front-end rebuild? And what happens to pricing at the next tier up, since outgrowing a tier mid-contract is a more common exit trigger than dissatisfaction. Write the answers down; they are rarely volunteered and they are the difference between a three-week migration and a three-month one.
The broader point is that neither architecture is lock-in free, and the relevant question is not which is freer but which lock-in you would rather have. A traditional platform ties your presentation to the vendor and keeps your content fairly loose. A headless platform frees your presentation and ties your data access. For an organisation expecting to redesign more often than it changes content systems, that trade favours headless. For one expecting the opposite, it does not.
The security trade runs in both directions
Security is regularly offered as a headless advantage and the picture is more mixed than the pitch suggests. Both architectures have real strengths and the risks simply relocate rather than disappear.
The headless case is genuine. A statically generated or edge-rendered front end has very little attack surface: there is often no application server processing requests, no database reachable from the public internet, and no plugin executing untrusted code in the rendering path. The content platform sits behind authentication and is not the thing serving your visitors. For an organisation whose previous site was compromised through an out-of-date extension, this is a material improvement and the main reason security appears in headless business cases at all.
The counter-case is less often stated. You now depend on two vendors rather than one, each with its own security posture and breach history. You have API tokens to issue, scope, rotate and keep out of client-side code — a credential class that did not previously exist, and one that shows up in public repositories with some regularity. Your front end has a dependency tree that needs keeping current, and a neglected application front end accumulates vulnerable packages exactly as a neglected plugin set does. The difference is that plugin updates arrive with a notification in an admin panel, whereas dependency updates require somebody to be looking.
Traditional platforms carry the opposite profile: a larger public attack surface and a well-understood maintenance routine, with updates surfaced where an administrator will see them. The failure mode is neglect rather than complexity, and neglect is easier to detect and cheaper to fix than a structural misconfiguration.
The practical conclusion is that architecture is a weaker determinant of security outcome than maintenance discipline. A well-maintained traditional site is safer than a neglected headless one, and the reverse is equally true. If security is the stated driver for a re-platform, the honest question is whether the organisation will maintain the new thing better than it maintained the old one — and if the answer depends on somebody being available to keep dependencies current, that is the same capacity question that decides the architecture anyway. Either way, a site holding personal data brings data protection obligations that follow the data rather than the platform, so confirm where content and form submissions are stored and processed.
What this looks like in practice
A UK specialist equipment distributor with 90 staff came to a rebuild decision with a website it had outgrown. The site ran on a traditional CMS, had accumulated fourteen plugins over six years, was slow on mobile, and had a product catalogue of about 400 items whose descriptions existed in inconsistent forms across category pages, the main catalogue, and a PDF price list that someone maintained separately in a word processor.
The incumbent agency proposed a headless rebuild at £58,000, on the grounds that the content inconsistency and performance problems were architectural and that the business would want an app eventually. The board asked for a second opinion, which is where we became involved.
The audit found three things. The content inconsistency was a modelling problem: products had never been defined as structured entities, so each appearance was hand-written. The performance problem was not architectural at all — there was no CDN, images were being served at full resolution and resized in the browser, and two marketing scripts were blocking rendering. And the app was aspirational: no budget, no owner, no date, mentioned in a strategy document from 2024.
The delivery channel count was one. But there was a genuine second consumer nobody had counted: the PDF price list, maintained by hand, perpetually out of date, and sent to roughly 200 trade customers quarterly. That is a real second channel wearing a disguise.
The recommendation was staged. First, model products as structured content types in the existing platform, with proper fields, and rebuild the catalogue templates to render from them — about £9,000. Second, fix performance properly: CDN, image pipeline, deferred scripts — about £3,500. Third, generate the trade price list automatically from the same product data rather than maintaining it by hand. That last piece used the platform’s existing API in decoupled mode and cost about £4,000.
Total spend was around £16,500 against the £58,000 proposal. Mobile Core Web Vitals moved from failing to passing. The price list became a generated artefact rather than a manual one, which removed roughly two days of quarterly work and the errors that went with it. Product descriptions became consistent because there was now one place they lived.
The honest postscript matters. Eighteen months later the business did commission a customer portal, a genuine second interface with its own funding and owner, and at that point the structured product model built in phase one was exactly what it needed — consumed through the same API. A full headless re-platform may yet be the right destination. It was not the right first step, and arriving at it gradually cost substantially less than arriving at it immediately would have.
We were ready to spend fifty-eight thousand pounds on an architecture because we had been told our problems were architectural. They were not. Two of the three were a content model and a caching layer. The thing that convinced the board was being shown that the price list — which we had never thought of as part of the website at all — was the only real multi-channel requirement we had, and it could be solved for four thousand pounds.
Two points generalise. The first is that the hidden second channel is worth hunting for: manually maintained documents, spreadsheets and PDFs assembled from website content are multi-channel requirements that nobody has named, and they are often the cheapest and highest-value thing to automate. The second is that staging works. Content modelling first, performance second, additional channels as they arrive, and architecture last, is a sequence that keeps every option open and rarely produces a wasted step.
Common mistakes in the CMS architecture decision
The errors below recur in UK CMS projects. Most are made at the decision stage rather than in delivery, which is when they are cheapest to avoid and most expensive to reverse.
- Treating headless as an upgrade rather than a trade. It is a different set of trade-offs, not a newer version of the same thing. For a single-channel site it typically costs around twice as much over three years for a comparable outcome.
- Buying architecture to solve a content modelling problem. Inconsistent, unreusable content is a modelling failure, and every mature traditional platform supports structured types. The improvement people attribute to headless is usually the modelling, which is portable.
- Counting hypothetical channels. An app with no budget, owner or date is not a second channel. Business cases built on it reliably lead to paying for capability that is never used.
- Missing the hidden channels you do have. Manually maintained PDFs, price lists and spreadsheets assembled from site content are real multi-channel requirements, usually unnamed and often the cheapest thing to fix.
- Descoping editorial preview. It is invisible to budget approvers and essential to daily users. Two in five headless implementations ship without it, and it is the decision editors resent longest.
- Going headless with no development capacity. Without in-house or retained developers, a headless site becomes unchangeable within about eighteen months, which is worse than a dated site anyone can edit.
- Deciding the architecture before modelling the content. Platform selection should follow the model, so you are evaluating against your actual structure, localisation needs and three-year volume rather than a feature grid.
- Rendering client-side only, then wondering about search visibility. Anything that must be found needs server rendering or static generation. This is the most damaging technical mistake available in a headless build and it is entirely avoidable.
- Rebuilding without a redirect map. Only about 14 per cent of organisations maintain one, and losing accumulated search equity in a rebuild is a self-inflicted cost nobody budgets for.
Be careful when the party recommending the architecture is also the party who will build it, particularly where the recommended option is several times more expensive and technically more interesting to work on. This is not usually cynicism — developers genuinely prefer modern toolchains, and that preference is honestly held. It is still a conflict, and the defence is cheap: ask for a written comparison including the option of structuring and caching what you already have, with three-year costs for each. A partner who will not produce that comparison, or who dismisses the cheaper option without costing it, has answered a different question than the one you asked.
The 12-point architecture decision checklist
Work through these in order. Items one to five establish the requirement, items six to nine test the cheaper alternatives, and items ten to twelve apply if headless is genuinely the answer.
- Count your funded delivery channels. Existing, with an owner and a budget. Include hidden ones: manually maintained PDFs, price lists, feeds and spreadsheets built from site content.
- Establish whether marketing currently builds pages without a developer. If they do and value it, that capability is on the line and preserving it has a cost that belongs in the budget.
- Assess your development capacity honestly. In-house or retained, available in eighteen months as well as at launch. If there is none, headless is a poor fit regardless of everything else.
- Write down the actual complaint. Slow, inconsistent, hard to edit, cannot reuse, insecure. Each has a different cheapest fix, and only some of them are architectural.
- Model your two or three most important content types on paper. Fields, relationships, reuse. Do this before looking at any platform.
- Try the model in the platform you already have. Structured types plus rebuilt templates. For single-channel businesses this frequently resolves the complaint at a fraction of the cost.
- Fix performance independently of architecture. CDN, image pipeline, deferred third-party scripts. Over half of UK SME sites lack edge caching, and no re-platform substitutes for it.
- Evaluate decoupled or hybrid mode. Keep the editorial experience, expose the API for the second channel. Often the right first move when channel two arrives.
- Get a written three-year comparison including the do-less option. Build, licence, hosting and maintenance for each route. Refusal to cost the cheaper option is informative.
- If going headless, treat preview and visual editing as requirements. Not enhancements, not phase two. With a non-technical editorial team this is the difference between adoption and resentment.
- Decide rendering strategy before build. Server rendering or static generation for anything that must be discoverable. Confirm metadata, sitemaps and structured data are in scope as deliverables.
- Plan the redirect map, accessibility testing and content residency. Every old URL mapped, WCAG tested with assistive technology rather than only automated tooling, and the vendor storage and processing location confirmed.
If only three items are completed, make them one, six and nine. The channel count tells you whether the primary benefit applies. Trying the content model in your existing platform tests the cheapest hypothesis first and is never wasted work, because a validated model is exactly what a headless project would need anyway. And insisting on a three-year comparison that includes doing less is the single most effective defence against buying architecture you do not need.
At a glance — headless against traditional CMS
| Question | Short answer |
|---|---|
| What is the real difference? | Headless separates content storage and management from presentation; traditional keeps both in one platform |
| The single deciding factor | How many funded delivery channels consume your content. One means the primary benefit does not apply. |
| Share of UK SMEs with one channel | About 76 per cent |
| Where the economics turn | At the second genuine channel, and decisively by the third |
| Initial build cost | £14,000–35,000 traditional; £30,000–75,000 headless for comparable ambition |
| Three-year total | £20,000–62,000 traditional; £40,000–150,000+ headless |
| The most underestimated cost | Editorial experience — preview and in-context editing must be deliberately built |
| What editors lose | WYSIWYG by default, and the ability to create genuinely new page types without a developer |
| Non-negotiable prerequisite for headless | In-house or retained development capacity, still available in eighteen months |
| Is headless faster? | Not inherently. Caching, images and third-party scripts decide performance in both architectures. |
| Where the benefit people report comes from | Usually content modelling, which every mature traditional platform also supports |
| Cheapest thing to try first | Structure your content properly in the platform you have, and put a CDN in front of it |
| The overlooked middle option | Decoupled or hybrid mode — keep the editorial experience, expose the API for channel two |
| Biggest technical pitfall | Client-side-only rendering, plus rebuilding without a redirect map |
| Correct order of decisions | Requirements, then content model, then platform, then architecture — never architecture first |
How Cloudswitched approaches this decision
Cloudswitched builds websites for UK organisations on both traditional and headless architectures, which means we have no structural preference to defend and will say when the cheaper route is the right one. In practice that means starting with the channel count and the actual complaint rather than the platform, modelling the two or three content types that matter before recommending anything, testing whether structuring and caching the existing site resolves the problem, and producing a written three-year comparison that includes the option of spending considerably less. Where headless is genuinely right, we treat editorial preview and rendering strategy as requirements rather than late additions, because those are the two decisions that determine whether the result is used and found.
Find out which architecture your site actually needs
We will count your real delivery channels, identify what is behind the complaint, and cost the do-less option alongside the rebuild so the comparison is honest.
Talk to a Web Development SpecialistFrequently Asked Questions
What is the difference between a headless CMS and a traditional CMS?
A traditional CMS owns both the content and the rendering: one platform stores your pages and produces the HTML a visitor sees. A headless CMS stores and manages content only, exposing it through an API, while a separate front-end application requests that content and decides how to display it. The practical consequences are that you run two systems with a contract between them, editors work in structured fields rather than something resembling the page, new page types become development tasks, and search visibility and accessibility become your front end’s responsibility rather than a plugin’s. Some of those are benefits, and all of them are changes.
Is a headless CMS better than a traditional CMS?
No — it is a different set of trade-offs, and treating it as a newer version of the same thing is the most common expensive mistake in this decision. Headless is clearly better when you publish the same content to more than one delivery channel, when you have development capacity, and when design-system-driven delivery matters. Traditional remains better for a single-channel site with a marketing team that expects to build its own pages and no in-house developers, which describes a large share of UK SMEs. For a single channel, headless typically costs around twice as much over three years to reach a comparable outcome.
How do I know if my business needs headless?
Count your funded delivery channels — existing ones with an owner and a budget, not planned ones. One channel means the primary benefit does not currently apply and the case must rest on secondary grounds. Two or more and the economics shift quickly in headless favour, because serving existing structured content to an additional surface is cheap compared with building a second site. Be strict: a responsive site on mobile is one channel. Also hunt for hidden channels — manually maintained PDFs, price lists, spreadsheets and partner feeds assembled from site content are genuine multi-channel requirements that nobody has named.
What does a headless CMS cost in the UK?
Indicatively for a mid-sized UK marketing site in 2026, excluding VAT: initial build £30,000 to £75,000 against £14,000 to £35,000 traditional, because the entire front end is bespoke rather than configured. Platform licensing ranges from nothing for self-hosted open-source options to £40,000 or more over three years on hosted tiers, which step sharply with seats, records and environments. Hosting is often cheaper. Maintenance is higher, because a bespoke front end has dependencies that need keeping current. Three-year totals land roughly at £20,000 to £62,000 traditional against £40,000 to £150,000 or more headless.
Will a headless CMS make my website faster?
Not inherently, and this is one of the most oversold claims in the category. Both architectures can be fast and both are commonly slow, because the factors that actually decide performance — caching and edge delivery, image handling, render-blocking resources, third-party scripts — are largely independent of architecture. A traditional site behind a CDN with disciplined asset handling will comfortably outperform a carelessly built headless site. If performance is your complaint, fix caching and images first: fewer than half of UK SME sites have edge caching at all, and that is a much cheaper intervention than a re-platform.
What do editors lose when we go headless?
Two things, and both are frequently discovered after launch. First, what-you-see-is-what-you-get: editors fill in structured fields and the result is rendered by an application the CMS knows nothing about, so preview has to be deliberately built and in-context editing built or bought. Around 41 per cent of headless implementations we review shipped with no working preview, because it is invisible to budget approvers and gets cut when the project runs over. Second, autonomy: creating a genuinely new page layout becomes a development task. If your marketing team currently ships pages without involving anyone technical, budget explicitly for preserving that.
Can I get the benefits of headless without going headless?
Often, yes, and it is worth testing before committing. Most of what people report improving after a headless move — consistency, reuse, editors knowing which fields to fill, manageable translations — comes from having modelled content as structured data rather than as pages of formatted text. Every mature traditional platform supports custom content types, defined fields, relationships and reusable components; they simply are not the default. Model your two or three most important content types properly in the platform you already have and rebuild those templates. For single-channel businesses this frequently resolves the complaint for a fraction of the cost.
What is a decoupled or hybrid CMS?
A traditional platform serving content through an API while keeping its own rendering and editing experience. The website continues to be produced by the platform your editors already know, and a second channel — an app, a partner feed, digital signage, a generated document — consumes the same content through the API. It is the option buyers are least often shown and it is frequently the right first move when a second channel arrives, because you gain the multi-channel capability at the point of need without rebuilding the website or accepting an editorial regression.
Is headless bad for SEO?
It is neutral if built properly and genuinely damaging if built carelessly. The failure mode is client-side-only rendering, where content is assembled in the browser and may be effectively invisible to some crawlers and assistive technologies. Anything that must be discoverable needs server rendering or static generation, decided before the build rather than retrofitted. Beyond rendering, metadata, canonical tags, sitemaps, structured data and redirects all become front-end deliverables rather than plugin features — better when specified, absent when not. Rebuilding without carrying forward a redirect map is the most common way search visibility is lost, and only about 14 per cent of organisations maintain one.
Do we need developers on hand if we go headless?
Yes, and treat this as a hard prerequisite rather than a preference. A headless site needs somebody able to deploy it, keep dependencies current and build a new page type when marketing asks for one. Without in-house capability you need a retained arrangement with a development partner, and that ongoing cost belongs in the business case from the start. Organisations that go headless with no continuing development access find that within roughly eighteen months the site is something nobody can change, which is a worse position than a slightly dated traditional site any staff member can edit.
How long does a headless build take?
Around nineteen weeks for a mid-sized UK marketing site with an engaged client: two weeks auditing content and counting channels, two weeks modelling content with editors present, a week selecting the platform against that model, three weeks on the design system and component inventory, six weeks building the front end, three to four weeks on preview and authoring overlapping that, three weeks on migration, redirects and accessibility testing, and two weeks on training and post-launch support. A comparable traditional build typically runs ten to thirteen weeks, with the difference concentrated almost entirely in the front-end and preview phases.
What should we ask a supplier recommending headless?
Ask for a written three-year comparison including the option of structuring and caching what you already have, with build, licence, hosting and maintenance costed for each route. Ask what happens to marketing’s ability to create pages, and what preview and in-context editing will cost. Ask what rendering strategy is proposed and why. Ask who maintains the front end in year two and at what cost. And note that the party recommending the more expensive and technically more interesting option is often the party who will build it — usually honestly held preference rather than cynicism, but still a conflict. A supplier who dismisses the cheaper option without costing it has answered a different question.
Related reading
More guidance on building, buying and governing UK business technology:
The architecture should be the last decision, not the first
Cloudswitched builds on both architectures and will cost the do-less option alongside the rebuild — so you choose headless because your requirements point there, not because it was the only thing quoted.
Talk to a Web Development Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
