What is a headless CMS? Definition, benefits and when it pays off

A traditional CMS does both jobs in one program: the same system that holds the article also owns the template that renders it. Decoupling them is the entire idea, and everything else — the benefits, the costs, the arguments — follows from that one change.

The three parts

The editing environment. Where the team writes. In a headless system this is a content model rather than a page: an article has a title, a body, an author, a hero image, a locale, and no idea what any of those look like. That is the point, and also the first thing editors complain about.

The API. The delivery layer, usually REST or GraphQL, handing over structured content — JSON, not HTML. Anything that can make an HTTP request can consume it: a website, a mobile app, a kiosk, another system entirely.

The front end. A separate application that fetches the content and renders it. Design, routing, performance and the whole SEO surface now live here, maintained as software rather than configured as a theme.

Headless versus traditional, honestly

	Traditional CMS	Headless CMS
Templates	Inside the CMS	In a separate codebase
Editor preview	Built in, exact	Needs to be built
Plugin ecosystem	Large, does a lot for free	Small; features get built
Multi-channel reuse	Hard	The default
Performance ceiling	Bounded by the theme and plugins	Bounded by what you build
Who can change a layout	An editor, often	A developer, always
Cost of the first version	Lower	Higher

The last three rows are the trade. A headless setup buys a much higher performance ceiling and full control of the markup, and pays for it in build cost and in every convenience the plugin ecosystem was giving you for nothing — sitemaps, redirects, forms, previews, search. None of those disappear; all of them become work.

What headless changes for search visibility

Nothing, in principle. The engine sees a website either way. What changes is when the HTML exists, and that is where headless projects succeed or quietly fail.

Google renders pages as part of crawling: during the crawl it runs the JavaScript it finds using a recent version of Chrome, because sites often rely on JavaScript to bring content onto the page. Its JavaScript SEO documentation describes the pipeline as three phases — crawling, rendering, indexing — with pages queued for rendering after they are fetched. A page may sit in that queue for a few seconds, or considerably longer.

So a headless front end that ships an empty shell and fetches its content in the browser is not invisible, but it is second in line, and it depends on a rendering pass that is neither instant nor guaranteed. Google's own guidance is unambiguous about the alternative: server-side or pre-rendering is still a great idea, because it makes the site faster for users and crawlers, and not all bots run JavaScript at all — which matters more every year as answer engines join the queue.

web.dev's rendering guide reaches the same conclusion from the performance side and recommends server-side or static rendering over a full rehydration approach. Static rendering, generated at build time, gives a fast first paint and a consistently fast time to first byte because the HTML is not built per request, and it can be served from a CDN; its cost is that a file has to exist for every URL. Server rendering handles the live and personalised cases at the price of compute per request.

Two details bite headless projects specifically. Canonical tags belong in the server-rendered HTML — Google says HTML is the best place to set them, and that JavaScript must not change one to a different value than the original HTML declared (see canonical tags). And client-side routing produces soft 404s unless a missing page is deliberately given a real status code or a noindex, because the server happily returns 200 for a route with nothing behind it. Both are covered under crawling and indexing.

When headless pays off, and when it does not

It pays off when at least one of these is true:

• The same content has to appear in more than one place — website, app, in-store screen, partner feed.
• Performance is a commercial requirement, not an aspiration, and the current theme-plus-plugins stack has hit its ceiling.
• The site is genuinely multi-locale, with translations, hreflang and per-market routing that a plugin keeps mangling.
• The front end is closer to an application than to a brochure — logged-in areas, configurators, real interactivity.
• The design has to be exact and the team is tired of fighting a theme for it.

It does not pay off when the site is twenty pages, one language, one channel, and edited twice a year by someone who wants to drag a block into place. There, a well-built traditional CMS wins on every axis that matters, and "headless" is an expensive way to buy a slower editing experience.

The middle case is the common one, and it has a middle answer: keep the editor people already know and replace only the rendering half — a traditional CMS serving its content over an API to a separate front end.

Choosing a system without joining a religion

The vendor comparison matters less than four questions:

1. Can your editors actually use it? A content model nobody can picture is a content model nobody fills in. Preview is not a nice-to-have.
2. Can you get your content out? Structured export, documented API, no proprietary body format — the best defence against being trapped.
3. What happens to the things the plugin used to do? Forms, redirects, sitemaps, search, image handling. Price them in, because they are the build.
4. Where does the HTML get rendered? If the answer is "in the browser", the SEO conversation will come back.

Any system that answers those four well is a defensible choice, and more of them do than any vendor's comparison page admits.

How Xerx does this

We build front ends in Next.js and TypeScript and pair them with whichever content system fits the team — that is the web and web apps service. Very often that is headless WordPress: the editors keep the interface they already know, and the visitor gets a modern front end. When the product needs something a page-oriented CMS cannot express, we build fully custom. The CMS should fit your team, not the other way round.

This site is the working example: a Next.js front end with a headless content backend, every page prefixed by locale, content shipped as structured data rather than pasted HTML, canonicals and sitemaps generated by the routing layer instead of typed into a plugin field. The Learn hub you are reading is Markdown in git — a deliberately extreme version of the same idea.

We are also candid about when not to do it. A headless build is a larger first invoice than a themed one: our Website Complete Package starts at €4,500 as a fixed price, with web apps from €9,000. If a client's real problem is that nobody can edit the site, a decoupled front end makes that worse, and we would rather say so before the quote than after the launch.

FAQ