Headless CMS

A headless CMS stores and manages content but hands off presentation to a separate front end, exposing content through an API (REST or GraphQL) instead of baking it into templates the way classic WordPress does. The stakes for SEO: decoupling buys you flexibility and speed, but it also means your pages are frequently built with JavaScript, and if that JavaScript renders content the crawler never sees, your rankings quietly evaporate.

The "head" is the front end, the part a human looks at. A traditional CMS bolts the head onto the body; a headless one rips it off so you can attach any head you like: a React or Next.js app, a native mobile app, a smart display, whatever. Contentful, Sanity, Strapi, and Storyblok are common examples. The SEO question is never "is headless bad?" It's "how does this particular front end render, and does Googlebot get the finished HTML or an empty shell?"

The rendering flow that decides your fate

Everything hinges on where the HTML gets assembled. Three patterns dominate, and they are not equal in the eyes of a crawler:

Client-Side Rendering (CSR)
  Browser gets: <div id="root"></div> + JS bundle
  Content appears: only after JS fetches API + paints
  Crawler risk: HIGH — bot may index the empty shell

Server-Side Rendering (SSR)
  Server calls CMS API, builds full HTML per request
  Browser/bot gets: complete HTML immediately
  Crawler risk: LOW

Static Site Generation (SSG)
  Build step calls CMS API, writes HTML files ahead of time
  Browser/bot gets: complete HTML from CDN
  Crawler risk: LOW (content is fixed at build)

SSR and SSG both hand the crawler finished HTML. CSR gambles that Google will render your JavaScript, and while Google usually does, rendering is queued, delayed, and never guaranteed for every bot, especially AI crawlers and Bing. If SEO matters, you render on the server or you pre-build. A static site generator is the safest bet when content doesn't change per request.

SSR vs SSG vs CSR for SEO

How to check it on your own site

1. View source, not the inspector. Right-click → View Page Source (raw HTML). If your headline and body copy aren't there, they're being injected by JS and you have a rendering risk.
2. Disable JavaScript in DevTools (Command Menu → "Disable JavaScript") and reload. Whatever's left is roughly what a non-rendering bot sees.
3. Use Search Console URL Inspection. "View Crawled Page" shows the HTML Google actually indexed. Confirm your main content and meta tags are present.
4. Check meta tags specifically. Title, description, canonical, and robots must be in the server response, not set client-side after paint, or bots may miss them.
5. Crawl with a JS-off crawler first. Run a crawl with rendering disabled; the gap between that and a rendered crawl is your JavaScript-dependency exposure.

Common mistakes and how to fix them

• Shipping pure CSR for public pages. The front end paints an empty <div id="root"> and hopes Google renders it. Fix: move public, indexable routes to SSR or SSG.
• Meta tags set client-side. Title and canonical get written by JS after load, so the initial HTML has generic or missing tags. Fix: render meta in the server response (Next.js Metadata API, or equivalent).
• Internal links as JS onClick handlers. No real <a href>, so crawlers can't follow them. Fix: use genuine anchor tags with real hrefs.
• Forgetting the sitemap. Decoupled front ends often ship without one because the CMS no longer auto-generates it. Fix: generate an XML sitemap at build or via an API route.
• Slow API = slow TTFB. SSR that waits on a distant CMS API drags Time To First Byte. Fix: cache API responses at the edge and use edge SEO techniques to patch and cache rendered HTML.

Frequently asked questions

Is a headless CMS bad for SEO?

Not inherently. A headless site rendered server-side or statically can outperform a bloated traditional site. The danger is only client-side rendering that leaves crawlers staring at an empty shell.

Does Google render JavaScript, so why worry?

Google does render JS, but on a delayed, resource-limited second pass that isn't guaranteed for every page or every crawl. Bing and most AI crawlers render far less reliably. Server-rendered HTML sidesteps the whole gamble.

What's the difference between SSR and SSG?

SSR builds the HTML on each request, so it's always current. SSG builds it once at deploy time, so it's blazing fast but can go stale until the next rebuild. Incremental static rendering splits the difference.

How do I handle meta titles and descriptions?

Render them server-side so they're in the initial HTML. Frameworks like Next.js expose a metadata layer for exactly this; don't rely on client-side scripts to set them.

Do I still need an XML sitemap?

Yes. A decoupled front end won't auto-generate one the way monolithic WordPress does, so build it into your pipeline and submit it in Search Console.

Related reading: Headless CMS SEO: Keeping Search Visibility When Content and Front End Split and JavaScript SEO.