Technical SEO for headless and JAMstack sites

A headless CMS separates content management (where it's written and structured) from its presentation (where and how it's displayed), exposing content through an API instead of directly generating the final HTML. JAMstack (JavaScript, APIs, Markup) is the architecture pattern that usually goes with it: the site is pre-built as static files at build time, from those APIs, and served from a content delivery network (CDN) instead of being generated on every request from an application server. The combination substantially changes which technical SEO problems matter: some that dominate in a traditional monolithic CMS (classic WordPress, for example) practically disappear, and others specific to this architecture show up that a team used to the monolithic model usually doesn't anticipate.

What disappears: most real-time rendering problems

This site's JavaScript and SEO guide explains the two-phase gap Google uses to process content dependent on JavaScript executed in the browser (client-side rendering). On a well-built JAMstack site, that problem practically stops existing: the complete HTML, with the real text content already present, gets generated at build time, not in the user's browser or at the moment of the crawler's visit. Googlebot receives the same complete HTML in the first crawl phase that a user would receive after executing JavaScript on a client-side site, so the rendering gap and the resource queue for executing JavaScript, which are a real problem on single-page applications (SPAs) with no pre-rendering, simply don't apply here.

What shows up: preview environments leaking into the index

The flip side of an automated build pipeline is that most JAMstack platforms (Netlify, Vercel, Cloudflare Pages) automatically generate a preview deployment URL for every branch or pull request, meant for reviewing changes before merging to production. Those preview URLs are complete sites, publicly accessible by default in many configurations, with the same content as production or an in-progress version of it. If they aren't explicitly protected, a link shared in a project management tool, a public Slack notification, or simply a crawler discovering the platform's domain can end up indexing those preview environments, generating duplicate content against real production and, in the worst case, leaking content that hasn't been published yet.

# Recommended header for any preview deployment,
# applied at the platform configuration level (not the CMS):
X-Robots-Tag: noindex, nofollow

# Alternative if the platform doesn't allow per-environment headers:
# protect the preview domain with basic authentication
# and explicitly exclude it from production's sitemap and robots.txt

Redirects: managed at the edge, not in the CMS

In a traditional monolithic CMS, redirects usually live inside the system itself (a plugin, a database table) because the same server that serves the content also handles the redirect logic on every request. In a JAMstack architecture, the served content is static and comes from the CDN, so redirect logic can't depend on the CMS (which isn't even active when the real request is served): it has to live in the edge layer, as configuration native to the deployment platform or a CDN proxy.

# Netlify: _redirects file at the root of the build
/old-product   /new-product   301
/blog/*        /articles/:splat 301

# Vercel: "redirects" block in vercel.json
{
  "redirects": [
    { "source": "/old-product", "destination": "/new-product", "permanent": true }
  ]
}

The usual technical risk is that redirects fall outside editorial control: if whoever manages content in the headless CMS assumes (out of habit from earlier platforms) that changing an entry's URL automatically creates a redirect from the old one, when in reality that logic lives in a separate configuration file nobody updates in the same move, every URL change in the CMS produces a silent 404 until someone manually adds the redirect at the edge layer.

Broken canonicals when content comes from multiple sources

It's common for a JAMstack site to combine content from more than one source at build time: the headless CMS for editorial pages, an ecommerce API for products, maybe a separate bookings or events service. Each source usually has its own notion of canonical URL or slug, and if the build process doesn't unify that logic centrally, it's easy for a single piece of content to end up with two different access paths (for example, reachable both from /products/nordic-chair and from a path inherited from an old integration) with no consistent canonical tag declaring which one is the reference, because the component generating that tag was built with only one of the two sources in mind.

The sitemap has to be part of the build pipeline, not a separate task

In a monolithic CMS, the sitemap is usually generated dynamically on every request, querying the database in real time, so it always reflects the current state of the content. In JAMstack, if the sitemap is generated as a manual step disconnected from the build process, it can go stale as soon as new content is published without re-running that step. The correct fix is to make sitemap generation part of the build script itself, so it regenerates automatically every time the site is compiled from the most recent content across every source.

// Example build-script integration (Node.js)
// runs as part of the same command that generates the static site
async function build() {
  const pages = await buildStaticSite();
  await generateSitemap(pages, './dist/sitemap.xml');
  await generateRobotsTxt('./dist/robots.txt');
}

Incremental Static Regeneration (ISR): content freshness and crawl priority

Some JAMstack frameworks offer Incremental Static Regeneration (ISR): instead of rebuilding the whole site on every change, they regenerate only the affected pages, on demand or at a defined interval, keeping the advantage of serving static HTML without sacrificing freshness. For SEO this has a concrete technical implication: if the regeneration interval is too long for content that changes frequently (prices, availability, news), Googlebot can keep seeing an outdated version of the page throughout that interval, even though the HTML is, technically, always static and fast to serve. Tuning the revalidation interval to the content's real pace of change, instead of leaving it at a generic default, is what avoids that gap.

Frequently asked questions