SEO for Headless CMS: Shopify Oxygen, Strapi and Contentful

Headless architectures solve real problems and create one specific risk: nothing about SEO is handled for you any more. A traditional CMS shipped canonical tags, sitemaps and server-rendered HTML by default. Go headless and every one of those becomes a decision someone has to make deliberately, usually a front-end developer who was not in the SEO conversation.

Is headless CMS bad for SEO?

No, but it moves the responsibility. A headless build with server rendering, correct metadata and a generated sitemap performs as well as any monolith. A client-rendered build with metadata injected after load performs badly. The architecture is neutral. The rendering strategy is not.

The rendering decision comes first

Everything else depends on this. Three viable options:

• Static generation. Pages built at deploy time. Fastest and most reliable for content that changes on a publishing cadence. The constraint is build time once you pass a few thousand pages.
• Server rendering. HTML generated per request. Right for personalised or frequently changing pages, at the cost of server work on every hit.
• Incremental regeneration. Static pages refreshed in the background on a revalidation window. This is the practical default for most content sites and the one to reach for first.

Pure client-side rendering is the option to avoid for indexable content. Crawlers can execute JavaScript, but rendering is queued, delayed and not guaranteed, and AI crawlers are meaningfully less capable at it than Googlebot.

Metadata belongs in the server response

The single most common headless failure is titles and descriptions set by client-side JavaScript. View source on a template page: if the title tag shows a generic app shell, that is what a crawler may index. Every framework has a server-side metadata API now, and it needs to be sourced from CMS fields rather than hardcoded.

The same applies to canonical tags, Open Graph, structured data and hreflang. All of it belongs in the initial HTML.

The pieces the CMS used to give you free

• Sitemaps. Generate from your content API, not by hand. It will go stale within a month otherwise.
• Redirects. When an editor changes a slug, the old URL must redirect. Headless CMSs rarely do this automatically, so store slug history and handle it at the edge.
• 404 handling. Missing content must return a real 404 status, not a 200 with an error message rendered client-side.
• Preview isolation. Preview environments need noindex and authentication, or they get indexed and compete with production.

Caching and invalidation

Edge caching is where headless earns its performance advantage, and where content goes stale in ways nobody notices for weeks. Wire CMS publish webhooks to targeted cache invalidation for the changed page plus its parents and listings. Blanket purges on every edit destroy the performance benefit you built the architecture for.

Platform notes

Shopify Oxygen with Hydrogen gives server rendering by default, so the usual gap is product metadata and structured data sourced properly from the Storefront API rather than hardcoded per template.

Contentful and Strapi are content APIs with no opinion about rendering, which means every SEO field is one you must model deliberately. Add title, description, canonical override and noindex flag to your content types on day one, because retrofitting them across a live content set is painful.

A quick verification

Disable JavaScript in your browser and load your five most important templates. Whatever remains is roughly what a weaker crawler sees. If the title, headings, body copy and links survive, the build is sound. If you get an empty shell, that is the whole problem in one screenshot.

A free audit crawls your rendered pages and flags exactly these gaps.