Why go headless?

Headless CMS is having a moment. Every CMS vendor that hasn't already pivoted to "headless" is busy adding the prefix to their marketing. That doesn't mean every site should be headless.

A headless CMS splits the editor (where content lives) from the frontend (where readers see it). Two separate systems talking via an API. The split unlocks real benefits — but only when the cost of running two systems is justified by what you get back.

We've run headless in production on the NSW Land Registry 1862 project. It's the deployment we've learned the most from about where headless earns its keep. Here's the honest version.

Security

Under-discussed in vendor marketing, and the one that matters most for us. When the editor and the frontend are the same monolithic CMS, every public visitor is hitting code that has admin pathways in it. With headless, the admin codebase is a separate service — put it behind a VPN or IP allowlist, harden it independently, and you've removed a class of attack surface from the public-facing side entirely.

The bigger gain is keeping up with releases. In a monolithic CMS the frontend theme is locked to whatever CMS version it was built against — you wait for the vendor to ship a frontend-compatible security update before you can apply it. With the frontend decoupled, the CMS upgrades on its own schedule and the frontend on its own. Each takes security patches as soon as they're released. The window where a known CVE sits unpatched because "the theme breaks on the new version" closes. You also stop depending on the CMS provider for frontend security patches at all — the frontend stack is yours.

A frontend that needs to be fast, accessible, and modern

Traditional CMSs come with their own frontend baked in. Whatever it does for accessibility, performance, and framework choice, that's what you get. Replace it and you've defeated the point of using the CMS. Headless lets the frontend team pick the right tool for the job — Nuxt for SSR sites that need to rank, Next for single-page apps, server-rendered HTML for the GOV.UK pattern. You can hit WCAG 2.2 AA without fighting a 15-year-old theme engine. This is the most common explicit reason customers ask us for headless.

Integration scale

If content has to come FROM somewhere else — a case management system, a register, a vault of records — and back-fill INTO somewhere else — payment, identity, GIS — a headless API is how that integration stays maintainable. The website becomes one of many integrations, not the centre of gravity.

Multi-channel publishing

If content has to land in a website AND a mobile app AND a regulator's data feed AND a partner's portal, headless beats traditional. One source of truth, many destinations. Not the case we ship most often, but if it's yours, headless is the answer.

When it's overkill

A brochure site for a 12-person team that needs four pages and a contact form: headless adds friction without paying for it. Use a traditional CMS, or a static site generator if you're technical.

The actual cost

You'll do more frontend work yourself. Things you'd get for free from a traditional CMS — page templates, a styled login, a built-in WYSIWYG that ships with the framework — you have to build or wire in. We built Hydra to close one of the biggest gaps: giving editors a true visual editor that works with real design system rules, still fully headless and decoupled, and without forcing heavy dependencies onto the frontend.

The upside is that the work is easier to estimate accurately. Fewer surprises than re-using CMS components and finding out at integration time which assumptions baked into the component don't fit your site. You don't get a "free" theme, but you don't get the hidden costs either.