Audit a headless CMS site where the SEO actually lives.

Is a headless CMS good or bad for SEO?

Your headless CMS is neither good nor bad for SEO, because your front end decides. Render HTML on your server and it helps. Ship a client-side-only app and it hurts. Open view-source on one of your article URLs and look for your title, your canonical and your body copy. If they're there, your crawler gets them. If you see an empty div and a script bundle instead, the crawler gets nothing until it renders your page (and that is a big "until").

Headless is not better for your SEO by default. Your canonicals, metadata, structured data, internal linking and rendering strategy now live in code your team writes and maintains. Client-rendered sites without dedicated technical SEO staff tend to have fewer pages indexed, so check whether that describes you. And you may not notice the losses until your rankings slide, by which point you are repairing old damage. The assessment scores what your pages ship, which tells you plainly which side of the line your site is on.

Where does SEO live in a headless or Jamstack stack?

Your SEO lives in your front end, not in your CMS. The CMS holds structured content and serves it by API, while the Next.js, Astro or Remix code you deploy owns rendering, routing and everything a crawler reads from your pages. Pick one page and trace its title. Find the SEO title field in your CMS, then find the line in your template that prints it. Can't find that line? Your field is decoration.

Look hardest at the seam between your API and your rendering, because that is where headless SEO most often breaks. You may have a field your template never uses. Your front end may output a canonical and ignore your editor's override. Nobody tends to own the template-level defaults: your CMS no longer renders, and your front-end team assumes the CMS handles SEO. So your developers must now rebuild the metadata, sitemaps, structured data and internal linking that a traditional CMS would have handled for you from its UI (a job nobody put on the roadmap).

How does the front end's rendering decide what crawlers get?

Your rendering strategy decides what a crawler gets from your site: finished HTML, or an empty shell it must run JavaScript to fill. Fetch your page with JavaScript disabled. Now look in the response for your headline, your body copy, your navigation links, your meta description and your canonical. If any of them is missing, you are betting that every crawler runs your JavaScript correctly (and some days they won't). And that bet rarely fails quietly.

Google processes your JavaScript web app in three phases: crawling, rendering and indexing. If your content exists only after rendering, you depend on the middle phase, the one you control least. So you are building on the part of the pipeline you can't steer. Check whether your templates put you there.

Two details in your template matter, and you can check both. Google says HTML is the best place for your canonical, and the canonical your JavaScript sets must match the one in your original HTML. Carry a noindex tag on your page, and Google may skip rendering altogether, so JavaScript that removes the tag may never get the chance to work. Dynamic rendering, if you use it, is a workaround. It is not a plan. For your pages, Google recommends server-side rendering, static rendering or client-side rendering with hydration. But don't take anyone's word for which one you run: read your own source to see which one you actually use.

Why do canonicals and slugs drift between the CMS and the site?

Your canonicals and slugs drift because your CMS stores one value, your route builds another, and nothing in your stack compares the two. Read the canonical tag in the source of three product pages. If all three point to the same URL, your template is hardcoding or inheriting it. Your editors lose their old controls too. In a traditional CMS, you could change canonicals, redirects, meta descriptions and schema without a ticket. Your headless setup may have quietly taken those built-in controls away.

An override in your CMS only counts if your template reads it. Sanity's course models an optional SEO object where an SEO title overrides the page title field if provided, and uses Next.js generateMetadata to render it. Skip that step and you have a field that does nothing. Before you trust the field, search your template for that call. And your sitemap drifts too: generate it at deploy time and it never notices an article you changed an hour ago. Check when you built yours.

Which headless setups leak preview and staging URLs into the index?

You leak them when your preview or staging build sits on a public host with no noindex header and no login. A staging subdomain on a custom domain is the clearest case, so check yours first. Request your staging URL, then read the response headers for X-Robots-Tag: noindex. Your Vercel Preview Deployments carry that header by default. Assign a custom domain such as staging.example.com to your non-production branch, though, and Vercel omits it (a detail that is easy to miss). You must add it yourself.

Noindex is a request, not a lock. Anyone with your URL can still open your preview, and if you want authentication before the page loads, you need Vercel's Deployment Protection. Your headless CMS preview URLs need the same treatment: add a noindex meta tag or an authorization header so your draft content does not get indexed as published pages. Don't rely on robots.txt. Google must crawl your page to see noindex, and it does not support noindex inside robots.txt, so your file cannot be your only guard.

How do you audit a headless site from the outside?

You audit your headless site from the outside by reading what it ships, because the shipped page is the only thing a crawler reads. Run the free assessment on your homepage and it samples up to eight more of your pages. It reads your response headers, markup, structured data, headings, script and image weight, plus your robots and canonical signals. The result: one score out of 100 for your site, with the evidence behind each of your eight weighted pillars.

The wait is about two minutes, and you pay nothing. You enter a work email, your report link arrives once, and you can run three checks per hour per connection. But the read has limits. It does not log in to your site, read your analytics, run field performance data or interview your team, so you get a report on your pages, not on the process behind your build. What you can confirm is whether each sampled page carries its own canonical, a meta description, schema and server-rendered body copy. Check each one against your templates.

Questions, answered.

Your next read.

1. 01Next.js SEO auditRendering mode, metadata, hydration cost.
2. 02Astro SEO checkIslands, content collections, schema, vitals.
3. 03Website repairDown, hacked or broken: what survives, what to rebuild.