Headless CMS SEO: what changes, what breaks, and how to fix it

Nothing about a headless CMS is bad for search by itself. What changes is who is responsible. In a traditional CMS such as WordPress, the theme and an SEO plugin produce most of the technical SEO without anyone thinking about it. Search Engine Journal's headless checklist states the consequence plainly: "In a headless set-up, we don't have these out-of-the-box guardrails, and we need to be a lot more specific with our technical implementation."

What the CMS no longer does for you

Job	Traditional CMS	Headless setup
Rendering	The theme returns full HTML for every URL	The front end decides: at build time, on the server or in the browser
Title and meta description	Theme and SEO plugin, from post fields	The front end writes the head from fields the CMS must provide
Canonical tag	Added automatically	Must be emitted as an absolute, self-referencing URL
XML sitemap	Generated for you	Built from the content API and kept current
Structured data	The SEO plugin outputs article markup	Built from fields and emitted as JSON-LD
Status codes	Missing pages return a 404	The front end must return a real 404, not a "not found" screen with a 200
Redirects	Plugin or server rule when a slug changes	Host or framework config; the CMS knows nothing about them
Archives	Category and tag archives come with the theme	Each archive is a route someone builds
Links and images	Use the site's own URLs	Can point at the CMS host unless rewritten

On a themed WordPress site most of the middle column comes from an SEO plugin. On a headless site none of it exists until a developer builds it, and most headless SEO failures are rows from this table that nobody was assigned. Archives deserve a mention of their own: without them, internal linking is reduced to whatever links editors type into the body.

Rendering decides what Google sees

The biggest headless SEO decision is when the HTML gets made. Google renders JavaScript, but its documentation describes two steps: a page is crawled, then queued for rendering, and "the page may stay on this queue for a few seconds, but it can take longer than that." Content that only exists after client-side JavaScript runs waits for that second step. Google's advice is direct: "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."

For a content site that leaves three options: static generation, which builds every page at deploy time; server-side rendering, which builds HTML on each request; and incremental regeneration (ISR in Next.js), which serves static pages and rebuilds them in the background after a set time or when content changes. Client-side rendering, where the browser assembles the page from JSON, is the one to avoid for content. The old fix of serving crawlers a prerendered copy is retired: Google now calls dynamic rendering "a workaround and not a long-term solution" and recommends server-side rendering, static rendering or hydration instead.

Two client-side details catch single-page apps even when rendering is solved. Links must be real anchors, because Google "can only discover your links if they are <a> HTML elements with an href attribute". And client-side routing often cannot send a 404 status, so a missing slug shows an error view that returns a 200, which Google treats as a soft 404. Google's fixes are to redirect to a URL that returns a real 404 or to add a noindex tag to the error view.

A headless SEO checklist

1. Render content and links into the HTML. Use static generation, server rendering or ISR, then compare the raw and rendered HTML of each template. SEJ's reminder: "Google doesn't scroll or click", so anything behind an interaction may as well not exist.
2. Model the SEO fields in the CMS. Every content type that becomes a page needs a title, meta description, editable slug, social image and, in SEJ's words, an indexing toggle "with a clear description of what it means". Without the fields, the front end has nothing to render.
3. Emit a self-referencing canonical in the server HTML. Use absolute URLs on the public domain. Google says the best way to set a canonical "is to use HTML", and warns against JavaScript changing it to a different value.
4. Generate the sitemap from the content API. Include only indexable, canonical URLs that return a 200, regenerate it on publish, and fill lastmod from the content's real update time. Google ignores priority and changefreq but uses lastmod when it is "consistently and verifiably" accurate.
5. Output structured data as JSON-LD. Article or BlogPosting for posts, plus FAQ or HowTo where the content has those sections, built from the same fields as the visible page.
6. Return real status codes. A 404 for unknown slugs and a 301 when a slug changes. SEJ suggests an automation that creates the redirect whenever a published URL is edited.
7. Rewrite links and media that point at the CMS host. Links in post bodies and image URLs should resolve on the public domain; the headless WordPress page explains how WordPress in particular leaks its own host.
8. Keep the heading hierarchy intact. Reusable content modules make it easy to end up with two H1s or a skipped level.
9. Revalidate on change. Rebuild the affected pages when the CMS reports an update, so corrections reach the HTML and the sitemap.

How Structura handles this

Structura covers the content side of this list and leaves the front end to you. A headless space stores the posts and serves them from a public Content API with the fields the checklist asks a CMS for: sanitized HTML with links already made absolute on your public domain, or structured blocks if you render components; meta title, meta description and keyphrase; Open Graph fields; images with width, height and alt text; categories and tags, with a terms endpoint for archive pages; and publishedAt and updatedAt on every post, so revalidation can key on real changes.

Each post also carries a schema array of JSON-LD: a BlogPosting node built from the post's public URL with the author as a Person, plus FAQPage and HowTo entries when the post has those sections, delivered separately so the HTML sanitizer cannot strip them. Inside the body, internal links point at your other posts on your public domain.

What the API does not do is render your pages. Your front end still picks the rendering mode, writes the head tags from those fields including the canonical link, builds the sitemap from the list endpoint, returns 404s and handles redirects. If you would rather keep WordPress as the backend, the plugin's headless mode publishes native posts there and points their links at your public site; the front-end work is the same. The API-first CMS page walks through the endpoints and links to the full reference.

FAQ