One Headless Backend, Many Agency Sites

The Estate Problem

Large public sector organizations accumulate websites. A department launches a campaign site. A program buys a microsite because the main site had a six-week queue. An agency merges and inherits three more. Each one arrives with its own platform, its own hosting, its own contract and its own renewal date.

The costs compound in ways that are individually small and collectively serious. Every site needs its own upgrades, its own certificates, its own accessibility remediation, its own security patching. A change to organizational branding becomes a program. A fix to a broken form pattern has to be made eleven times, and will be made eight times.

The instinct is consolidation onto one platform, which fails politically as often as technically because the sites genuinely do have different owners, different audiences and different release cadences. Headless architecture offers a different split: consolidate the content and the components, not the sites.

What Actually Gets Shared

The separation only pays off if you are clear about which layer is shared. Three things are worth sharing across an estate, and they are not the same thing:

• Content, where it is genuinely common. Office locations, service definitions, staff directories, news, policy notices. These are the records that are wrong in six places today.
• Components. A single implementation of the header, the navigation, the form controls, the tables, the notification banners: accessible once, tested once, fixed once.
• Infrastructure patterns. Build, deploy, monitoring and security scanning, so a new site is a repository rather than a procurement.

What should not be shared is layout and editorial judgment. A campaign site and a statutory service have different jobs, and forcing them into one template produces something that serves neither. The architecture should make divergence cheap where it is justified and expensive where it is not.

The Accessibility Argument Is the Strongest One

The business case for headless usually gets made on cost or speed. In this sector the accessibility case is stronger and more durable.

In a conventional estate, an accessibility defect in a date picker exists independently in every site that has a date picker. Each needs to be found, fixed, tested and released separately, by different teams on different platforms, some of whom have no budget this year. In practice the fix lands in the sites with active development and not in the rest, so the estate's compliance position quietly degrades between audits.

With a shared component library, the same defect is one fix in one place, and every site picks it up on its next deployment. That changes accessibility from a per-site remediation cost into a maintenance property of the platform, which is the only version of it that survives budget pressure. It pairs directly with the standards work described in our accessibility audits, and it is why we usually recommend the two together.

Draw the Boundary at Content

The most common way to get this wrong is to push presentation into the content system. It starts reasonably (an editor wants a two-column section) and ends with layout instructions, inline styles and component names stored as content.

Once that happens the benefit is gone. The content can no longer be rendered differently by a different front end, which was the entire point, and the redesign you do in four years becomes a content migration instead of a front-end project.

Hold the line: the content system stores what is true, the front end decides how it looks. An editor says a notice is urgent; the front end decides urgent means a red banner. An editor says a service has eligibility criteria; the front end decides whether that renders as a list or an accordion. This discipline is uncomfortable at first and is the difference between an architecture that pays off and one that merely adds a network hop.

What It Costs

This is not free, and pretending otherwise leads to disappointment.

• You need an owner for the shared layer. A component library with no maintainer becomes a liability faster than duplicated code, because now everyone depends on it and nobody improves it.
• Editors lose direct preview unless you build it. When content and presentation are separate, "what will this look like" needs deliberate engineering.
• Debugging crosses a boundary. Is the wrong text a content problem or a rendering problem? Good tooling and clear ownership matter more than they did.
• It suits estates, not single sites. For one website with one team, this is overhead with no corresponding benefit.

The threshold is roughly where you start maintaining the same fix in several places. Below it, keep things simple. Above it, the duplication is already costing more than the architecture would. We build these as headless frontend applications against a shared content backend, and are happy to talk through whether an estate is over that line.