Headless CMS: Who Actually Needs One — and Who Doesn't

Headless does not remove the work. It moves it, and every SEO control goes with it.

Almost every page ranking for this term is published by a company that sells a headless CMS.

Which is why they all reach the same conclusion.

We run search engine optimisation across WordPress, Shopify, custom React front ends and a few genuinely headless builds. We do not resell a CMS, which is why this post can give you the uncomfortable half of the answer.

Headless is a real improvement for a specific set of problems and a downgrade for everyone else — it moves work out of the CMS and into the development team, including work you used to do yourself.

What a headless CMS actually is

A headless CMS stores your content and exposes it over an API, and nothing else. It does not render pages. The "head" — the part that turns content into HTML a browser and a crawler can read — is a separate application your team builds and runs.

Three things follow, and they are the whole debate:

• Any number of front ends can read the same content. Website, mobile app, in-store screen and partner feed all call one API instead of each keeping a copy.
• Nothing about the page is decided in the CMS any more. Layout, page speed, titles, canonicals, redirects and sitemaps live in the front-end codebase.
• The editing experience is whatever someone built for you. No theme, no page builder, no plugin directory — unless your developers rebuilt the equivalent.

Named factually: Contentful documents five APIs, Content Preview among them, which exists to show editors unpublished content "in-context" (contentful.com developer docs, read 5 October 2026, no last-updated date shown). WordPress can do it too: its REST API sends and receives site data "as JSON" (developer.wordpress.org, shows "Last updated January 16, 2024"), and WPGraphQL is a free, open-source plugin adding a GraphQL schema and API to any WordPress site (wpgraphql.com, read 5 October 2026).

So going headless does not mean leaving WordPress. It means leaving WordPress's rendering layer — a different and much larger decision.

The four conditions that justify going headless

Benefits are what a vendor writes. Conditions are what you can check against your own business today.

Note the word proven in the fourth one. Most sites blaming the CMS for speed have an unoptimised image pipeline, eleven tracking scripts and a bloated theme — our page speed work usually finds the ceiling far below where the client assumed.

The costs nobody quotes you

Every row below is something teams lose in the first month live, and none of it appears in a vendor comparison table. You also patch four moving parts instead of one.

The ticket problem quietly kills marketing velocity: if publishing twenty pages a month needs a developer to touch a route, your calendar is your developer's backlog. And the plugin ecosystem disappears — not "becomes harder", disappears. The SEO plugin writing your titles and sitemap stops being involved the moment it stops rendering the page.

Headless CMS and SEO: nothing breaks, everything moves

The sentence this post exists to deliver: headless does not hurt SEO. It moves every SEO control out of a settings screen and into code, so SEO has to be in the build brief rather than added after launch.

Rendering and indexability

Google processes JavaScript in three phases — "1. Crawling 2. Rendering 3. Indexing" — using an evergreen version of Chromium, and "queues all pages with a 200 HTTP status code for rendering". That page "may stay on this queue for a few seconds, but it can take longer than that" (Google Search Central, "Understand the JavaScript SEO basics", last updated 2026-03-04).

So client-side rendering is indexable. It is also queued, and the queue is the risk: anything failing in the browser fails silently while Google is looking. Google's troubleshooting page names soft 404s in single-page applications among the common faults and sends you to the URL Inspection tool in Search Console to "see loaded resources, JavaScript console output and exceptions, rendered DOM" ("Fix search-related JavaScript problems", last updated 18 December 2025).

Two consequences. Render what matters server-side or at build time. And return real status codes — a catch-all route replying 200 with "page not found" text is the commonest headless mistake we see, and the same failure mode behind most 404 error problems.

Who owns titles, descriptions and canonicals now

Your developers do. In Next.js, metadata is a code export — a static metadata object or a generateMetadata function — which "will automatically generate the relevant <head> tags for your page" (Next.js docs, "Metadata and OG images", lastUpdated 2026-08-25).

// app/blog/[slug]/page.tsx — the title now lives here, not in a CMS field
export async function generateMetadata({ params }) {
  const post = await getPost((await params).slug)
  return { title: post.seoTitle, description: post.seoDescription }
}

Read that as a marketer. If post.seoTitle is not a field in the content model, nobody changes a title without a deploy. Getting those fields into the model on day one is the cheapest hour you will spend here.

The same doc holds a second trap: Next.js streams metadata separately on dynamically rendered pages, and that streaming is "disabled for bots and crawlers that expect metadata to be in the <head> tag". Framework defaults are doing SEO work for you; someone should know which.

Canonicals need their own line. Google will "pick up the injected canonical URL when rendering the page" but warns you to "make sure that this is the only rel=canonical link tag on the page" (JavaScript SEO basics, last updated 2026-03-04). A framework default plus a CMS field plus a hand-rolled component is how a site ends up with two — settle that with our canonical tag guide.

Redirects, and who maintains the map

This is where most migrations lose traffic — a people problem in technical clothing.

In Next.js, redirects are entries in next.config.js, and permanent: true emits a 308 rather than a 301 — the framework uses 307 and 308 "to explicitly preserve the request method used" (Next.js docs, "redirects", lastUpdated 2026-06-30). Both are valid permanent signals, but a team grepping logs for 301s will conclude the redirects are missing.

Ownership is harder: a redirect in a config file is a code change. Ask before the build: who adds one when marketing retires a landing page, and what is the turnaround? If the answer is "raise a ticket", your old URL will 404 for a fortnight.

Sitemaps, structured data and internal links

All three become build artefacts.

• Sitemaps. Next.js generates sitemap.xml from a file convention you write programmatically (Next.js metadata file conventions, lastUpdated 2026-08-25) — built from your route list, so a page that exists in the CMS but has no route is never submitted. Re-read our XML sitemap rules before anyone writes that generator.
• Structured data. No plugin is emitting it, so every type is built per template — cleaner than a plugin guessing, which is why breadcrumb navigation is worth specifying rather than inheriting.
• Internal links. "Related posts" is now a query someone wrote. A weak query manufactures orphan pages that sit in the API, in the sitemap, and linked from nothing.

Internationalisation

Google accepts three equivalent ways to declare localised versions — hreflang link tags, HTTP Link headers, or xhtml:link entries in a sitemap — and the requirement is bidirectional: "Each language version must list itself as well as all other language versions", and pages that do not both point to each other are ignored (Google Search Central, "Tell Google about localized versions of a page", last updated 2026-09-21).

A front end rendering hreflang from a per-locale query drops those return links the moment a locale lacks a translation. Test per template, not once on the homepage.

What we put in a headless build brief

Our own practice, shared as practice and not a benchmark — we have not measured it across a sample large enough to quote a figure, so read it as a pattern we see, not a statistic.

When a client says their developer is proposing headless, the first thing we ask for is not the rendering strategy. It is the redirect map and the content model. Rendering faults are loud and get fixed in week one; a content model shipped without SEO fields is quiet, and takes a second project to undo.

1. SEO fields in the content model — title, description, canonical override, robots directive, OG image. Marketer-editable, no deploy.
2. Server-rendered or pre-rendered primary content — copy, headings and internal links in the initial HTML response.
3. Real status codes — 404 returns 404, 301 or 308 for moved URLs, no soft 404s on the catch-all route.
4. A named redirect owner — a person and a turnaround time, agreed before launch.
5. Sitemap built from published content, not routes alone — plus a pre-launch diff against the old one.
6. A working preview for editors — unpublished content on the real template. It is what keeps editors in the CMS.
7. Rendered-DOM checks per template — one URL Inspection pass per template type, not one per site.

Scope that in and a migration behaves like a migration. Skip it and you spend the next quarter recovering — and since organic takes roughly three to six months to show movement, a bad launch costs two quarters. Running that is what our SEO services cover.

The decision test

Count the conditions you can answer yes to — with evidence, not ambition.

Two of four is the honest threshold. Below it you are buying complexity, and you pay in publishing speed.

The spectrum helps. A closed platform limits what you can change — the subject of our guide to SEO on Wix. Headless is the opposite end: total control, total responsibility. WordPress sits in the middle, where most marketing teams get the most done.

What to do next

At two or more, take the seven-item brief to your developer before anyone picks a vendor — those decisions are cheap in a planning call and expensive in a retro. Below two, ask which condition "we should go headless" actually answers. If nobody can name one, that is your answer.