# Headless CMS SEO: what to get right (2026)

> Headless CMS SEO works when your front end ships server-rendered HTML. The 7 jobs plugins used to do: metadata, previews, redirects, sitemaps and schema.

Canonical: https://www.searchmaxxed.com/research/headless-cms-seo
Last updated: 2026-10-27

HOW-TO GUIDE

Headless CMS SEO works when your front end ships server-rendered HTML. The 7 jobs plugins used to do: metadata, previews, redirects, sitemaps and schema.

BH

Brenden House

Founder of Searchmaxxed. We build agentic SEO and GEO workflows that help businesses rank on Google and get named in ChatGPT, then turn that search into more customers and revenue.

PUBLISHED 27 OCTOBER 2026 UPDATED 27 OCTOBER 2026 15 MIN READ

Headless CMS SEO means making a site built on Contentful, Sanity, Storyblok or another headless CMS rank as well as a traditional one. The CMS itself is neutral. Rankings depend on your front end. It has to ship server-rendered HTML, editable metadata, server-side redirects, a live sitemap and structured data that matches the page.

I'm Brenden House. I run Searchmaxxed, an SEO and AI SEO agency. This guide is for marketing and engineering leads at SaaS, enterprise and other large companies moving to a headless CMS, or already running one. It covers the seven SEO jobs a WordPress plugin used to do quietly, each of which now needs a named owner on your team. Sources checked: 27 October 2026 (AEST).

## In summary

A headless CMS won't hurt your SEO. It will if nobody rebuilds what WordPress plugins did for free, from title tags and canonicals to sitemaps, redirects and schema. Assign an owner to each job. Then test it on every release.

| SEO job | Who should own it |
| --- | --- |
| Rendering (SSR or SSG) | Engineering, set once per template |
| Titles, descriptions, canonicals | Editors, through CMS fields with code fallbacks |
| Preview and staging URLs | Engineering: noindex at the platform |
| Redirects | Editors for one-offs, code for patterns |
| XML sitemap and robots.txt | Code, generated from the route list |
| Structured data | Code, filled from CMS fields |
| Release tests | Engineering, in the build |

- **Rendering comes first.**  Send the full page in the first HTML response, because most AI crawlers don't run JavaScript.
- **Metadata needs fields.**  No plugin exists.
- **Redirects must be permanent and server-side.**  In Next.js, `redirect()` sends a temporary 307, so moved pages need `permanentRedirect()`.
- **Previews leak.**  Vercel noindexes preview deployments by default, but not on a custom domain such as staging.example.com.
- **Automate the checks.**  A build that fails on a missing canonical beats an audit three months after launch, when the traffic has already gone.

## Is a headless CMS good or bad for SEO?

A headless CMS is neither good nor bad for SEO. It moves the work out of plugins and into your code and content model, so results depend on the team that builds that layer.

Here's the mechanism. A headless CMS stores content and sends it to a front end through an API, usually REST or GraphQL, whenever a page needs it. The front end, often Next.js, Nuxt or Astro, turns that content into pages, and nothing in between writes a title tag. Or a canonical, or a sitemap, unless someone builds it.

That's the trade. You get speed, full control over every template, and one source of content feeding the website, the app, the docs and anything else you launch. You lose the defaults. WordPress VIP's [guide to headless CMS SEO](https://wpvip.com/blog/headless-cms-seo/) says it plainly: "Headless requires a full rebuild of that metadata pipeline."

Speed is the upside people quote most. A static or server-rendered site on a CDN can load fast, but Google measures what users feel, not what the server sends. Its [Core Web Vitals](https://web.dev/articles/vitals) set three targets. Largest Contentful Paint should land within 2.5 seconds, and Cumulative Layout Shift should stay at 0.1 or less. Interaction to Next Paint should be 200 milliseconds or less, and a heavy JavaScript bundle can pass the loading target while failing this one.

So headless suits a company whose engineers will own SEO in code. Want marketing to change titles and redirects without a ticket? Build that into the CMS first.

## What is headless SEO, in plain terms?

Headless SEO is technical and on-page SEO for a site whose content and front end live in separate systems. The checklist matches any other site, from crawlable HTML to schema. Who does each job is what changes.

Seven terms keep coming up:

- **Headless CMS:**  a content store with no front end of its own, such as Contentful, Sanity, Storyblok, Strapi, Contentstack, Hygraph or headless WordPress.
- **Content model:**  each content type's fields.
- **Server-side rendering (SSR):**  HTML built per request.
- **Static site generation (SSG):**  pages turned into finished HTML ahead of time and served from a CDN.
- **Incremental static regeneration (ISR):**  static pages that rebuild one at a time.
- **Client-side rendering (CSR):**  the browser downloads an empty shell, then JavaScript fetches the content and draws the page.
- **Webhook:**  the CMS's publish signal.

At Searchmaxxed, we treat a headless site as a [technical SEO](https://www.searchmaxxed.com/services/technical-seo) job first. Get rendering, metadata and redirects right. Then the content work compounds.

## Which rendering method should a headless site use?

Use static generation or server-side rendering for every page you want found in Google or AI answers. Client-side rendering suits logged-in screens.

| Rendering | What crawlers get | Use it for |
| --- | --- | --- |
| SSG | Full HTML from a CDN | Marketing pages, docs, articles |
| ISR | Full HTML, refreshed after publish | Large catalogues, frequent edits |
| SSR | Full HTML per request | Personalised or fast-changing pages |
| CSR | An empty shell until scripts run | App screens behind a login |
| Dynamic rendering | A separate HTML copy for bots | Nothing new |

Google's [dynamic rendering page](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) calls it "a workaround and not a recommended solution". Google can render JavaScript. GPTBot, ClaudeBot and PerplexityBot read raw HTML. Our guide to [JavaScript SEO for React and Next.js sites](https://www.searchmaxxed.com/research/javascript-seo) covers the crawler tests and the Next.js metadata trap, so I won't repeat them.

The headless twist is simpler. Your content arrives from an API, so ask what happens when that API is slow or down at build time. A page that builds with an empty body still returns a 200 status, and Google will index that blank page as if it were finished.

## Who should own titles, meta descriptions and canonicals?

Editors should own the words, and code should own the rules. Put SEO fields in the content model, give each one a fallback in code, and block publishing when a required field is empty.

Here's the field set I'd add to every page-level content type in the CMS:

| Field | Editor sets | Code fallback |
| --- | --- | --- |
| SEO title | Optional override, up to about 60 characters | Page title plus brand |
| Meta description | Required, about 140 to 160 characters | None; block publish if empty |
| Slug | Set once, then locked | Generated from the title |
| Canonical URL | Rare override, admins only | The page's own clean URL |
| Robots | Index or noindex toggle | Index |
| Social image | Optional | Default brand card |
| Alt text | Required on each image | None; block publish if empty |

Two rules prevent most headless metadata bugs. First, generate the canonical from the route. A free-text canonical field will eventually hold a typo, a staging URL or last year's slug, and Google will follow it.

Second, render head tags server-side. Contentful's [headless SEO guide](https://www.contentful.com/seo-guide/headless-seo/) agrees: "Avoid injecting any critical elements through JavaScript."

In Next.js, `generateMetadata` reads the CMS entry and returns those tags for each route, and other frameworks follow the same pattern with their own names.

## How do you keep previews and drafts out of Google?

Noindex every preview and staging environment at the platform level. Keep preview URLs out of anything public, because a leaked draft competes with your live page.

Headless CMSs make previews easy, and easy things leak. Preview links end up in Slack, tickets and customer emails, and each one is a full copy of the page at a second address.

Vercel adds `X-Robots-Tag: noindex` to every preview deployment by default, and to old production deployments, according to its [guide on preview indexing](https://vercel.com/kb/guide/are-vercel-preview-deployment-indexed-by-search-engines). The exception catches teams out. Assign a custom domain such as staging.example.com to a non-production branch, and Vercel omits the header. Add it yourself there.

On the live domain, use draft mode. Next.js [Draft Mode](https://nextjs.org/docs/app/guides/draft-mode) shows draft content on the real URL through a cookie, so no second address exists. After launch, check three things:

1. Run `curl -I` on a preview URL and look for `x-robots-tag: noindex`.
2. Search Google for `site:` plus your staging domain, and open anything that comes back.
3. Confirm the sitemap holds no draft or preview URLs.

## How should redirects work on a headless site?

Redirects on a headless site should be permanent, server-side and editable from the CMS. 301 and 308 both mean permanent.

Google's [redirects guide](https://developers.google.com/search/docs/crawling-indexing/301-redirects) recommends "a permanent server-side redirect whenever possible". JavaScript redirects are weaker. They work only once Google renders the page, and AI crawlers that skip JavaScript may never follow them.

Headless stacks add three traps:

- **The wrong status code.**  In Next.js, `redirect()` returns a 307, which is temporary, according to the [Next.js redirecting guide](https://nextjs.org/docs/app/guides/redirecting). Moved content needs `permanentRedirect()`, a 308.
- **Platform limits.**  The same guide notes a limit of 1,024 redirects on Vercel. For a big migration, keep the map in a data store your middleware reads instead.
- **Slug changes.**  Rename a slug and the old URL breaks. Add a redirect content type, and have the CMS create an entry automatically whenever someone changes the slug of a published page.

Deleted entries need care too. A catch-all route that shows "not found" with a 200 status creates a soft 404. Google's [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) covers fixes for single-page apps, and on a server-rendered site it's easier still: return a real 404 or 410.

## How do you build an XML sitemap and robots.txt for a headless CMS?

Generate both from the list of routes your site serves. Include only indexable pages that return a 200 and carry a self-referencing canonical.

The CMS knows which entries exist. Only the front end knows which URLs those entries become. So the sitemap belongs in the front end, rebuilt at deploy time or on a publish webhook. Next.js ships a `sitemap.ts` convention.

Google's [sitemap guide](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) sets three rules:

- One sitemap holds at most 50,000 URLs or 50MB uncompressed.
- Google ignores `<priority>` and `<changefreq>`.
- Google uses `<lastmod>` only "if it's consistently and verifiably" accurate, so take it from the entry's real last-edited date rather than the build time.

Is it worth the trouble? On a site we own, we measured how fast Google indexes a brand-new build. We launched a new site with 161 guides, each built for one search from the live results and People Also Ask. We submitted the sitemap and pinged IndexNow. No paid indexer. About 25 hours after Google's first crawl, 203 of 228 URLs were indexed. Indexed isn't ranked, though: 5,198 impressions in ten days and 5 clicks.

Robots.txt needs the same care. Headless sites often expose API routes, or cached JSON that repeats the page copy word for word, at URLs any crawler can fetch. Block those paths. Keep the sitemap line pointing at the live file.

## How do you add structured data with a headless CMS?

Generate JSON-LD in code from the same CMS fields that fill the visible page, and render it on the server. Markup that describes something readers can't see breaks Google's rules.

Google's [structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) are blunt. "Don't mark up content that is not visible to readers of the page." A free-text schema field invites that. Editors paste JSON once and move on, while the page keeps changing around it until the markup describes a page that no longer exists.

A safer pattern has three parts:

1. Map each content type to a schema type: Article, Product, SoftwareApplication, Event or FAQPage.
2. Build the JSON-LD from that entry's fields, so the author, dates, prices and questions always match the page.
3. Give shared entities, like your Organization, one stable `@id` that every page references, so engines see one company rather than several near-copies.

This matters beyond rich results. Google's [AI features guide](https://developers.google.com/search/docs/appearance/ai-features) says AI Overviews and AI Mode need nothing beyond normal SEO. Clean server-rendered entities help every engine.

## How do you handle hreflang and several markets?

Store each market's version as a localised entry, and generate hreflang tags from the route list. Each version lists every version.

Google's [localised versions guide](https://developers.google.com/search/docs/specialty/international/localized-versions) puts it this way. "Each language version must list itself as well as all other language versions." Alternate URLs must be fully qualified too.

Take Australia and the US. The en-AU and en-US pages share most of their copy but differ in spelling, currency and proof. Model them as two locales of one entry rather than two separate pages. The hreflang pair then stays in sync. Our [international SEO service](https://www.searchmaxxed.com/services/international-seo) covers multi-market builds, from hreflang to market-specific pages and proof.

## What changes for Contentful, Sanity and Next.js SEO?

The jobs stay the same across stacks. Where each SEO field lives, and which default bites, is what changes.

| Stack | Where SEO fields live | What to watch |
| --- | --- | --- |
| Contentful | Fields in your content types; Contentful Apps add more | Critical tags injected by client-side JavaScript |
| Sanity | Fields in your schema; SEO plugins exist | A free-text schema markup field |
| Next.js front end | `generateMetadata`, `sitemap.ts`, `robots.ts` | `redirect()` is a 307; 1,024 redirects on Vercel |

Contentful's guide says it "doesn't use plugins", and points to Contentful Apps instead. [Sanity's headless SEO guide](https://www.sanity.io/headless-seo) goes further and tells teams to "request a field to input schema markup". I'd skip that field. For the reason, see the structured data section above: generated JSON-LD can't drift from the page.

## What should editors be able to do without a developer?

Editors should be able to publish, retitle, preview and redirect a page alone. The CMS should block the mistakes that cost rankings, because anything that waits on a developer ticket tends to slip for weeks.

Build these controls into the CMS:

- Required meta descriptions and alt text.
- A slug that locks after first publish, with an automatic redirect if an admin changes it later.
- A noindex toggle that also drops the page from the sitemap.
- Internal links chosen as references to other entries rather than typed URLs, so every link follows the target page when its slug changes.
- Snippet and social-card previews.

That typed-URL point matters more than it looks, because nothing warns you. Rename the target, and that link breaks. Reference fields fix it at the source, because the link follows the entry rather than the URL.

## What do we test on every release of our own site?

Searchmaxxed.com doesn't run a headless CMS. Our content lives in the repository and every route renders to HTML at build time, so we face the same jobs. Any failed check stops the build:

| Check | What fails the build |
| --- | --- |
| Head tags | More or fewer than one title, description or canonical |
| Title match | The rendered title differs from the source title |
| Social tags | og:url differs from the canonical |
| Noindex | A noindex route without its noindex directive |
| Headings | Any count of H1s other than one |
| Descriptions | Length outside 100 to 160 characters |
| Structured data | JSON-LD missing, malformed or without a stable @id |
| FAQ schema | FAQPage markup that differs from the visible FAQ |
| Internal links | A link to a missing route, or to a redirect |
| Redirects | A redirect away from a page we still build |
| Sitemap | A lastmod date that doesn't come from the source |
| Images | An image with no alt text, or a missing file |

Our build script writes the sitemap, robots.txt and llms.txt together. One route table feeds both the sitemap and llms.txt, so neither lists a page the site doesn't serve.

Copy this list into your own pipeline, whatever framework or CMS you run. A headless site changes in two places. Test one and you'll miss half.

## How do you move to a headless CMS without losing rankings?

Map every old URL to a new one, ship permanent redirects on launch day, and compare raw HTML before and after for each template. When rankings fall after a move, check redirects and tags first. Headless itself is rarely the culprit.

Say a B2B SaaS company moves 1,400 blog, docs and product URLs from WordPress to Sanity and Next.js. Here's the order I'd run it in:

1. Crawl the old site. Export every URL with its title, description, canonical, status code and inbound internal links.
2. Pull 12 months of Search Console page data, so the URLs that earn clicks get checked first.
3. Build the redirect map: one old URL to one new URL, no chains.
4. On staging, compare raw HTML against the old site for each template: title, description, canonical, H1, body, links and JSON-LD.
5. Rebuild analytics and conversion events.
6. Launch, submit the new sitemap, and watch Search Console's page indexing report daily for two weeks.

Step five gets skipped most. Here's a case we found while auditing an enterprise client's tracking, and it had nothing to do with rankings. A client's four enquiry types never counted as conversions. Their event names ran 41 to 50 characters; GA4 cuts at 40. The 40-character "career" event counted every time. Nobody had noticed, because the events still showed up.

## Where does Searchmaxxed fit?

Searchmaxxed is an SEO and AI SEO agency for enterprise, B2B SaaS, venture-backed, manufacturing and public-sector companies. On headless sites we do the technical SEO, on-page SEO, structured data and content. The aim is simple: rank in Google and get named in ChatGPT, Gemini, Perplexity and Google's AI answers.

For a headless build, we audit rendering and metadata template by template, then write the SEO fields straight into your content model. Then come redirects, sitemaps and release checks in your pipeline. After that, we ship new pages and articles each month through your CMS or repository.

| Package | Who it suits | What it includes |
| --- | --- | --- |
| Growth System | A company growing in one or two markets | 30 page releases a month, work on up to 4 existing pages, technical and schema work, AI visibility tracking |
| Agentic Search Engineering | A competitive or national market | 50 page releases a month, comparison and integration pages, digital PR and link campaigns, AI answer tracking |
| Custom & Enterprise | Several brands, several markets or a large site | Dedicated engineering, custom reporting and original first-party research |

A page release is an approved new page or a substantial rebuild of one, and technical or schema work never reduces that count. Changing platforms? Our Agentic Migration keeps a design worth keeping and moves the site to an owned repository and infrastructure that supports ongoing search work. Want the fault list first? The [AI SEO Audit](https://www.searchmaxxed.com/audit) takes five business days and ranks every fix by what it's worth.

Here's how we do it. We work on a site you own, our [Agentic Website](https://www.searchmaxxed.com/agentic-websites). AI agents pull your Search Console and GA4 data, read the Google results and check what AI answers say about you and your competitors. That feeds the Managed Search Loop, which shows which page, fix or link should bring in the most enquiries next. We build it, check the live page and measure what changed.

Searchmaxxed's work has generated more than A$10 million in revenue through search for its clients.

## Is Searchmaxxed right for you?

We fit marketing and growth teams at larger companies on a headless CMS who want the SEO built and shipped for them. Just want advice for your own engineers? A consultant suits you better.

| Searchmaxxed is a good fit if | Look elsewhere if |
| --- | --- |
| You want technical SEO and monthly content from one team | You need one redirect map and nothing after |
| Your engineers welcome pull requests to the front end | Nobody outside your team may touch the code |
| You want Google and AI answers handled together | You only want a dashboard of AI mentions |
| You sell in several markets, such as Australia and the US | You need search to fill this month's pipeline alone |
| You want to own your site, repository, content and data | You're shopping for the cheapest retainer |

## Frequently asked questions

### What are examples of headless CMS?

Common headless CMSs include Contentful, Sanity, Storyblok, Strapi, Contentstack, Hygraph, Payload and headless WordPress. Each stores content and sends it to a separate front end through an API. The front end decides their SEO.

### What does Contentful do?

Contentful is a headless CMS. Editors create structured content in it, and developers fetch that content through an API for websites, apps and other channels. It has no front end. Your team builds the SEO layer.

### Can WordPress work as a headless CMS?

Yes. WordPress can store content and serve it through its REST API, or a GraphQL plugin, to a front end like Next.js. You keep the familiar editor. SEO plugins stop writing your tags, though, so the front end must render them.

### What is SEO in a CMS?

SEO in a CMS covers the fields and settings that control how each page appears in search. That means the title, meta description, slug, canonical, robots tag and structured data. Headless CMSs leave that build to you.

### Is Next.js good for SEO?

Yes, when pages use static generation or server rendering and metadata renders on the server. Watch two defaults. `redirect()` sends a temporary 307, and Vercel caps config redirects at 1,024.

### Do I need an SEO plugin with a headless CMS?

No. You need SEO fields in the content model, code that renders them, and checks that block bad publishes. Some CMSs sell apps that add the fields, but your front end still has to output the tags.

### Does a headless CMS help with AI search?

It can. A server-rendered headless site gives ChatGPT, Claude and Perplexity full HTML they can read without running JavaScript. A client-rendered one can rank in Google and stay invisible to them.

## What should you do next?

Pick your three busiest templates. Fetch each one with `curl` and read the raw HTML, checking that the title, description, canonical, body copy and JSON-LD are all there. If any are missing, or you'd like us to own the fix and the monthly work after it, [let's talk pricing](https://www.searchmaxxed.com/contact).

REFERENCES

1. [guide to headless CMS SEO](https://wpvip.com/blog/headless-cms-seo/)
2. [Core Web Vitals](https://web.dev/articles/vitals)
3. [dynamic rendering page](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering)
4. [headless SEO guide](https://www.contentful.com/seo-guide/headless-seo/)
5. [guide on preview indexing](https://vercel.com/kb/guide/are-vercel-preview-deployment-indexed-by-search-engines)
6. [Draft Mode](https://nextjs.org/docs/app/guides/draft-mode)
7. [redirects guide](https://developers.google.com/search/docs/crawling-indexing/301-redirects)
8. [Next.js redirecting guide](https://nextjs.org/docs/app/guides/redirecting)
9. [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
10. [sitemap guide](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)
11. [structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
12. [AI features guide](https://developers.google.com/search/docs/appearance/ai-features)
13. [localised versions guide](https://developers.google.com/search/docs/specialty/international/localized-versions)
14. [Sanity's headless SEO guide](https://www.sanity.io/headless-seo)

[Get an AI visibility audit](https://www.searchmaxxed.com/contact)

See where buyers find someone else across Google and AI answers.

See where you are invisible →

## Let's make you the answer.

## Related

- [Research](https://www.searchmaxxed.com/research)
- [Searchmaxxed](https://www.searchmaxxed.com/)