Headless Commerce Platforms

TL;DR — A “headless commerce platform” is the engine that runs your products, cart, and checkout and hands that data to a separate storefront you build. Every vendor claims theirs is “SEO-optimized out of the box.” That’s only half true. Some (Shopify Hydrogen, BigCommerce Catalyst) ship real SEO scaffolding — a sitemap, a robots.txt, a metadata helper. Others (Medusa, Saleor, Elastic Path) ship nothing SEO-specific and leave all of it to you. Pick based on how much you want to build versus inherit.

What we’re actually comparing here

In a normal Shopify or WooCommerce store, one system does everything: it stores your products, processes orders, and renders the pages shoppers and Google see. A headless setup splits that apart. A commerce engine handles products, inventory, and checkout, and hands that data through an API to a separate frontend that renders what people actually look at.

The commerce engine is the “headless commerce platform.” The major ones as of mid-2026 are Shopify (through its Hydrogen framework and Storefront API), BigCommerce (through Catalyst), commercetools, Salesforce Commerce Cloud (through PWA Kit), Medusa, Saleor, and Elastic Path.

The one thing that matters for choosing

For SEO, the platforms don’t really differ on whether your pages can be crawled — that comes down to how your frontend renders pages, which the Headless Ecommerce SEO hub covers in full (SSR, SSG, CSR). What they differ on is how much SEO plumbing they hand you for free versus how much you have to build yourself.

Think of it as three groups:

• They give you a lot. Shopify Hydrogen and BigCommerce Catalyst both ship a working example storefront with a sitemap, a robots.txt, and a way to set your title tags and meta descriptions already wired in.
• They give you helpers, not the finished thing. commercetools and Salesforce PWA Kit hand you the tools to build a sitemap but make you assemble it yourself.
• They give you nothing SEO-specific. Medusa, Saleor, and Elastic Path are pure “here’s your product data through an API” engines. Every bit of SEO — the sitemap, the metadata, the robots.txt — is on you (or on whatever frontend framework you build, usually Next.js).

The thing most people get wrong

“SEO-optimized out of the box” is a spectrum, not a checkbox. Every vendor’s marketing page says it. But Elastic Path’s own SEO blog post doesn’t even mention sitemaps, canonical tags, or redirects — so “out of the box” can mean almost nothing. Don’t take the claim at face value. Ask the specific question: what does this platform ship for sitemaps, metadata, redirects, and keeping my staging site out of Google? The answers vary a lot.

Want the platform-by-platform breakdown, the preview-environment gotcha, and a decision framework for picking one? Switch to the Advanced tab.

TL;DR — Headless commerce platforms sit on a spectrum from “ships real SEO scaffolding” to “leaves everything to you.” Shopify Hydrogen ships the most — a getSeoMeta utility, sitemap routes, robots.txt, and (via Oxygen) automatic crawler-blocking on preview deployments. BigCommerce Catalyst proxies BigCommerce’s own sitemap index and uses Next.js App Router generateMetadata conventions. commercetools Frontend and Salesforce PWA Kit give you SDK/API helpers, not shipped routes — you assemble the sitemap yourself, with real pagination limits. Medusa, Saleor, and Elastic Path ship nothing SEO-specific; the frontend owns everything. Two risks are genuinely differentiated by platform: preview-environment leakage (Hydrogen auto-blocks crawlers on shareable links; others don’t guarantee it) and redirect maps (no platform automates them). Platform choice sets how much scaffolding you inherit — not whether pages are crawlable, which is still the rendering decision the hub owns.

Platform choice is not the rendering decision

Start here, because it’s the single most common confusion. Whether Googlebot gets real HTML or an empty shell is decided by your frontend’s rendering model — server-side rendering (SSR), static generation (SSG), or client-side rendering (CSR). That’s the frontend framework’s job, and the Headless Ecommerce SEO hub covers it in depth. I won’t re-derive SSR vs. CSR here.

What the commerce platform does decide is how much SEO scaffolding you inherit — the sitemap, the metadata plumbing, the robots.txt, the preview-environment handling. A pristine SSR setup on Medusa still has no sitemap until you build one; a CSR mistake on Hydrogen still tanks a product page even though Hydrogen ships every other piece. Keep the two axes separate: rendering = crawlability; platform = scaffolding.

The SEO-tooling spectrum

Here’s where the seven platforms land:

Ships real tooling (a working reference storefront with SEO wired in): Shopify Hydrogen, BigCommerce Catalyst.

Ships SDK helpers, not routes (you assemble the sitemap yourself): commercetools Frontend, Salesforce PWA Kit.

Ships nothing SEO-specific (pure commerce API; frontend owns all of it): Medusa, Saleor, Elastic Path.

That framing is the whole article. The rest is the per-platform detail.

Shopify Hydrogen (Storefront API)

Hydrogen is Shopify’s headless framework, and it ships the most complete SEO scaffolding of anything reviewed here. One correction up front: Hydrogen is not Remix-based anymore. The npm registry shows @shopify/hydrogen 2026.4.4 peer-depending on react-router ~7.16.0 with no Remix dependency at all, and Shopify’s own @shopify/remix-oxygen package now carries a formal deprecation notice telling you to import from react-router instead. Shopify’s own SEO doc hasn’t caught up to its own package metadata — as of this check it still reads “Hydrogen uses Remix’s built-in meta features for SEO tags” — so don’t take that line at face value if you’re scaffolding a new project; check package.json, not the prose.

Metadata — a purpose-built utility. Whatever the doc calls the underlying router, Hydrogen still ships the getSeoMeta utility, which makes it easier and more consistent to render SEO meta tags. That getSeoMeta helper handles titles, descriptions, images, canonical URLs, and JSON-LD — an actual metadata abstraction, not “bring your own <head>.” It’s the only platform here that ships a dedicated SEO-metadata utility. Shopify also notes that “By default Hydrogen removes query parameters from canonical URLs” — a sensible default you can override in your meta exports.

Sitemap — shipped and self-refreshing. The Hydrogen skeleton template includes sitemap.xml and per-type sitemap routes out of the box, and its getSitemap utility generates per-resource-type sitemaps with locale alternates. The sitemap files are cached for 24 hours, so publishing or unpublishing a product updates the sitemap automatically within that window — no scheduled job to babysit.

robots.txt — shipped, with a preview safeguard. The template ships a robots.txt route. And here’s the differentiator: per Shopify’s SEO docs, “If you make a non-production deployment accessible with a shareable link or an auth bypass token, then Oxygen overrides the deployment’s robots.txt file with a disallow rule for all bots and crawlers.” Oxygen (Shopify’s Hydrogen hosting) automatically blocks all crawlers on preview/shareable-link deployments. That’s a real problem — duplicate staging content getting indexed — that most platforms leave you to solve by hand, and Hydrogen just handles.

What’s left to you: verify no product or category route was accidentally left as a resource route that skips SSR (React Router’s framework mode uses the same server-loader pattern Remix used before Hydrogen’s migration), and configure Oxygen caching (the hub’s advanced lens covers stale-cache risk).

BigCommerce headless (Catalyst)

Catalyst is BigCommerce’s Next.js App Router reference storefront. Its SEO scaffolding is real but architecturally different from Hydrogen’s.

Sitemap — proxied, not generated. Per BigCommerce’s Catalyst docs, “Catalyst acts as an intermediary when handling requests to /sitemap.xml.” It fetches the sitemap index from BigCommerce (against the channel’s canonical URL) and returns the XML. So the sitemap appears to be served from your storefront, but the data lives in BigCommerce, not in your frontend codebase — the opposite of Hydrogen, where the sitemap route lives inside the app. BigCommerce also warns that “If your storefront also uses third-party systems that generate content with different URLs, you will need to submit multiple sitemaps to cover the URLs from various sources,” and notes the sitemaps “don’t need to reside on the same domain as the website they represent” — flexible for multi-channel setups, but a footgun if per-channel canonical domains aren’t configured correctly.

Metadata — Next.js conventions. Catalyst populates generateMetadata and the alternates.canonical field per route from Storefront API GraphQL data, server-side. That’s the standard App Router pattern the Next.js SEO article already documents in detail — I’ll point there rather than re-explain generateMetadata syntax.

The migration warning. If you’re moving from BigCommerce’s older Stencil theme to Catalyst, URL parity is the whole ballgame. As 1Digital Agency’s Dan Kogan puts it in his Catalyst SEO practitioner guide: “Do not change established URLs on a Stencil-to-Catalyst migration. Every product, category, and content URL should match the legacy structure exactly, or you need a complete 301 redirect map.” He also flags recurring Catalyst regressions — generateMetadata returning a client-only fallback because the GraphQL query got thrown to a client component, canonical tags missing on paginated listing pages, and Product JSON-LD emitted twice (once by a custom component, once by a third-party app). All of those are worth a pre-launch check.

commercetools (Frontend / composable storefronts)

commercetools is the enterprise “composable/MACH” option, and its SEO scaffolding is proportionally thinner — you get SDK helper methods, not shipped routes.

Per commercetools’ Frontend docs, the platform generates three separate sitemaps — static pages, product pages, and category pages — combined into a sitemap index. Static pages come from sdk.page.getPages(), products from extensions.product.query(), and categories from extensions.product.queryCategories(). But setup is not automatic: it requires the Frontend Add-On plus manually creating three Next.js route handlers (sitemap-static.xml/route.tsx, sitemap-products.xml/route.tsx, sitemap-categories.xml/route.tsx) and a postbuild script to assemble the final /sitemap.xml. And the product/category queries are cursor-paginated with a 500-item limit per request, so a large catalog needs pagination logic inside your sitemap generator. This is the most build-it-yourself of the enterprise platforms for sitemaps specifically — which tracks with commercetools’ whole no-opinionated-frontend positioning.

Salesforce Commerce Cloud headless (PWA Kit / Composable Storefront)

PWA Kit’s SEO tooling is the most fragmented and manual of the platforms with an official reference storefront.

Sitemap — the path branches. Per Salesforce’s docs, if your routes are configured in Business Manager, you create the sitemap in Business Manager; if routes are managed outside it (custom PWA Kit routing), you build or supplement the sitemap via an API endpoint instead. There’s no single automatic path — it depends on how the storefront was set up. For PWA Kit deployments specifically, the manual steps include adding a path in the ssr.js config, updating the ssrShared property, redeploying the bundle, and verifying the sitemap is accessible. Salesforce’s own guidance is to schedule a job to keep the sitemap current — meaning no automatic refresh on catalog changes, unlike Hydrogen’s 24-hour auto-update. Built-in sitemap handling has been a requested-but-manual area on the PWA Kit GitHub repo — useful color that this is a known gap, though the issue is community signal, not an official statement.

Metadata — tied to Page Designer. PWA Kit’s usePage() hook (from @salesforce/commerce-sdk-react) and <Page> component expose page name, description, and route for SEO metadata — but that’s tied to Salesforce’s CMS-like Page Designer content model, not a dedicated SEO utility like Hydrogen’s getSeoMeta.

Medusa, Saleor, and Elastic Path — pure APIs

These three are the “leaves everything to you” tier, and it’s worth being blunt about what that means.

Medusa is a pure commerce backend. There’s no dedicated Medusa SEO documentation because Medusa has no opinion on frontend rendering at all. Its Next.js Starter Storefront supports the App Router with React Server Components (so SSR is available), but metadata, sitemap, and canonical mechanics are entirely inherited from whatever Next.js conventions you implement. In practice virtually every Medusa storefront is Next.js — so the Next.js SEO article is your real reference, not Medusa’s docs.

Saleor is the same story: a GraphQL-first headless API (Python/Django backend) with community and Vercel-maintained Next.js storefront templates. SEO is 100% a function of the chosen frontend. Same tier as Medusa.

Elastic Path is API-first with metadata as raw fields you wire up yourself. Its product and category entities support custom fields for SEO metadata that can be, in Elastic Path’s words, “accessed via APIs just like the content that you render to your customers” — but that’s a build-your-own-schema pattern, not a shipped utility. Its slug resource is described as a “lower case, uri friendly string” for building URLs. Notably, Elastic Path’s own SEO for headless commerce blog post (by Kirsten Aebersold — vendor content, not neutral) does say “If you’re dynamically building a page with a JavaScript framework alone, you might want to look into serving up cached versions of the pages to the bots” — but it never covers sitemaps, canonical tags, redirects, or preview environments. When even the vendor’s own SEO page skips half of what you need, “SEO-optimized out of the box” is doing a lot of work.

None of these three are bad for SEO — there’s no platform ceiling. But there’s also no scaffolding to lean on. Everything is a function of the frontend you build.

Preview and staging leakage — the differentiated risk

This is the one place platform choice makes a concrete, measurable SEO difference, so it’s worth calling out separately.

Hydrogen/Oxygen automatically disallows all crawlers on preview and shareable-link deployments — a built-in safeguard against your staging site getting indexed and competing with production as duplicate content. No equivalent automatic guarantee is documented for Catalyst, commercetools, or PWA Kit. And it’s not theoretical: 1Digital Agency reports “Preview deployments indexed by Googlebot” as a recurring real-world failure mode on Catalyst migrations. That’s a single practitioner source rather than an official platform statement, so treat the specific Catalyst claim as one credible data point — but the underlying lesson is platform-agnostic: if your platform doesn’t auto-block preview crawlers, block them yourself (a robots.txt disallow, HTTP auth, or a noindex header on every non-production environment). On the “everything-to-you” platforms, this is entirely on you by definition.

Redirect management — a migration concern, not a platform feature

No platform reviewed ships an automatic redirect system. Every headless migration — Stencil to Catalyst, monolith to headless, one commerce engine to another — needs an explicit 301 map from old URLs to new. The consensus across migration-focused trade posts is consistent: re-platforming failures almost always trace back to redirect maps, URL structures, and structured-data gaps, and you should never launch without a verified 301 map. That’s the same lesson the site’s Site Migrations article covers in full — I’ll cross-reference it for the checklist rather than re-derive it here. The platform-specific angle is just this: don’t assume any of these engines handles redirects for you. None do.

Portability is the underrated upside

One myth worth killing: switching commerce platforms does not mean rebuilding your SEO from scratch. The rendering layer — your Next.js (or React Router) storefront — is what determines crawlability, and it’s largely portable across commerce backends. A Next.js storefront can point at BigCommerce, Medusa, Saleor, or commercetools with mostly data-layer changes. What changes when you swap platforms is the scaffolding: where the sitemap data comes from, whether there’s a metadata utility, how redirects and previews are handled. That’s a meaningful re-wire, but it’s not “start over.”

And don’t over-index on API quality as an SEO signal, either. A platform’s GraphQL/REST API only determines what data is available to build metadata and sitemaps from. Whether that data actually reaches Google server-side is a frontend/rendering decision — which, again, the hub owns.

Where to go next

• Headless Ecommerce SEO — the hub: the SSR/SSG/CSR rendering decision, structured data (Product, ProductGroup/hasVariant), and why the GMC feed is independent of rendering.
• Next.js SEO — since Catalyst, commercetools Frontend, Medusa, and Saleor storefronts are usually Next.js, this is where the generateMetadata and sitemap.ts mechanics live.
• JavaScript SEO — the general JS-rendering failure modes that apply to any JS-heavy storefront.

AI summary

A condensed take on the Advanced version:

• Platform choice ≠ rendering choice. Crawlability comes from the frontend’s rendering model (SSR/SSG/CSR — owned by the headless ecommerce hub). The commerce platform decides how much SEO scaffolding you inherit.
• A spectrum, three tiers:
  • Ships real tooling: Shopify Hydrogen (getSeoMeta metadata utility, sitemap routes, robots.txt, auto preview-crawler blocking via Oxygen) and BigCommerce Catalyst (sitemap proxied from BigCommerce, Next.js generateMetadata conventions).
  • Ships SDK helpers, not routes: commercetools Frontend (three-sitemap pattern via SDK methods, manual route wiring, 500-item pagination limit) and Salesforce PWA Kit (sitemap path branches on Business Manager vs. custom routing; manual scheduled regeneration).
  • Ships nothing SEO-specific: Medusa, Saleor, Elastic Path — pure commerce APIs; the Next.js frontend owns all SEO.
• Metadata: Hydrogen’s getSeoMeta is the only shipped SEO-metadata utility (title/description/image/canonical/JSON-LD). Everyone else exposes raw API fields you wire into generateMetadata yourself.
• Preview/staging leakage is a real differentiator: Hydrogen/Oxygen auto-blocks crawlers on shareable links; no equivalent guarantee for Catalyst, commercetools, or PWA Kit (1Digital reports Catalyst previews getting indexed in the wild). Block them yourself if the platform doesn’t.
• Redirects are a migration concern — no platform automates a 301 map; cross-reference the Site Migrations article.
• Portability upside: the Next.js frontend is largely reusable across backends; swapping platforms re-wires scaffolding, not your whole SEO.
• Myth to kill: “SEO-optimized out of the box” is a spectrum — Elastic Path’s own SEO post doesn’t even cover sitemaps, canonical tags, or redirects.

Which headless commerce platform (for SEO)?

This walks the SEO-scaffolding tradeoff, not the business/pricing decision. The question at each node is “what do I want to inherit vs. build?”

Official documentation

Primary-source platform documentation, per commerce engine.

Shopify Hydrogen

• Search Engine Optimization for Hydrogen — the getSeoMeta utility, canonical handling, sitemap and robots.txt routes, and the Oxygen preview-blocking behavior.
• Hydrogen getSeoMeta utility — the metadata helper’s inputs (title, description, image, canonical, JSON-LD).
• Hydrogen getSitemap utility — per-resource-type sitemap generation with locale alternates.

BigCommerce Catalyst

• Catalyst Sitemap docs — how Catalyst proxies BigCommerce’s sitemap index. (This URL moved from developer.bigcommerce.com to docs.bigcommerce.com since this article was drafted — verified 2026-07-19; the old path 301s here.)

commercetools

• Sitemaps | Frontend Development — the three-sitemap pattern, the SDK methods (getPages, query, queryCategories), route handlers, and the 500-item pagination limit.

Salesforce Commerce Cloud (PWA Kit)

• Improve SEO with a Sitemap | Composable Storefront — the Business-Manager-vs-custom-routing branch and the manual sitemap steps.
• PWA Kit GitHub issue #1755 — Add Sitemap handling — community signal that built-in sitemap handling has been a manual gap.

Medusa / Saleor / Elastic Path

• Medusa Next.js Starter Storefront — App Router + React Server Components; SEO inherited from your Next.js implementation.
• Elastic Path — SEO for headless commerce websites — vendor blog; useful as the platform’s stated SEO position (note it omits sitemaps/canonical/redirects).

Quotes from the source

Verbatim statements from the platform docs and one named practitioner. Deep links jump to the quoted passage where the source supports it.

Shopify Hydrogen — the metadata utility

• “Hydrogen uses Remix’s built-in meta features for SEO tags, and includes the getSeoMeta utility, which makes it easier and more consistent to render SEO meta tags.” — Shopify.dev, Hydrogen SEO docs. This exact sentence is still live on the doc, but it’s stale: @shopify/hydrogen no longer depends on Remix (it peer-depends on react-router ~7.16.0, and @shopify/remix-oxygen is formally deprecated in favor of react-router). The getSeoMeta utility itself is accurate and current. Jump to quote
• “By default Hydrogen removes query parameters from canonical URLs.” — Shopify.dev, Hydrogen SEO docs.

Shopify Hydrogen — preview-crawler blocking

• “If you make a non-production deployment accessible with a shareable link or an auth bypass token, then Oxygen overrides the deployment’s robots.txt file with a disallow rule for all bots and crawlers.” — Shopify.dev, Hydrogen SEO docs.

BigCommerce Catalyst — sitemap proxying

• “Catalyst acts as an intermediary when handling requests to /sitemap.xml.” — BigCommerce Developer Center, Catalyst Sitemap docs.
• “If your storefront also uses third-party systems that generate content with different URLs, you will need to submit multiple sitemaps to cover the URLs from various sources.” — BigCommerce Developer Center, Catalyst Sitemap docs.
• “The sitemaps don’t need to reside on the same domain as the website they represent.” — BigCommerce Developer Center, Catalyst Sitemap docs.

Dan Kogan, 1Digital Agency (practitioner, Catalyst SEO)

• “Do not change established URLs on a Stencil-to-Catalyst migration. Every product, category, and content URL should match the legacy structure exactly, or you need a complete 301 redirect map.” Read the guide
• “Use generateMetadata and SSR-emitted JSON-LD for every PDP and PLP. Do not rely on client-side schema injection.” Read the guide

Elastic Path (vendor blog — treat as the platform’s stated position, not neutral)

• “If you’re dynamically building a page with a JavaScript framework alone, you might want to look into serving up cached versions of the pages to the bots.” Read the post

Mistakes that cost you

Concrete failure modes I’d check for on any headless commerce build.

Trusting “SEO-optimized out of the box” at face value. Why it’s wrong: it’s a spectrum, not a guarantee. Hydrogen ships real scaffolding; Medusa, Saleor, and Elastic Path ship nothing SEO-specific. Elastic Path’s own SEO blog post doesn’t even mention sitemaps, canonical tags, or redirects. Do instead: ask the specific questions per platform — what ships for sitemaps, metadata, redirects, and preview-blocking? — and budget the gaps as build work.

Assuming every platform keeps staging out of Google. Why it’s wrong: only Hydrogen/Oxygen auto-blocks crawlers on preview/shareable deployments. There’s no documented equivalent for Catalyst, commercetools, or PWA Kit, and at least one practitioner (1Digital Agency) reports Catalyst preview deployments getting indexed by Googlebot in the wild. (Single-source claim — treat as one credible data point, not settled fact.) Do instead: block non-production environments yourself — robots.txt disallow, HTTP auth, or a noindex header on every preview/staging URL. Never assume the platform does it.

Treating a platform swap as “rebuild all SEO from scratch.” Why it’s wrong: the rendering layer (your Next.js/React Router frontend) is what determines crawlability and is largely portable across backends — a Next.js storefront can point at BigCommerce, Medusa, Saleor, or commercetools with mostly data-layer changes. Do instead: re-wire only the scaffolding that actually differs — sitemap data source, metadata utility, redirect handling, preview-blocking. Reuse the frontend.

Judging SEO by API quality. Why it’s wrong: the GraphQL/REST API only determines what data is available to build metadata and sitemaps from. Whether that data reaches Google depends on server-side rendering — a frontend decision, not an API one. Do instead: evaluate the rendering model (per the hub) separately from the API. A great API with a CSR frontend still ships empty HTML to crawlers.

Skipping the redirect map on migration. Why it’s wrong: no platform reviewed automates redirects. Re-platforming failures almost always trace back to missing 301 maps, changed URL structures, and structured-data gaps. Do instead: build and verify a complete old-URL→new-URL 301 map before launch. On Stencil→Catalyst specifically, keep URLs identical or map every one. See the Site Migrations article for the checklist.

Letting Product JSON-LD render twice, or client-side. Why it’s wrong: 1Digital flags Product JSON-LD emitted twice (a custom component plus a third-party app) and generateMetadata returning a client-only fallback because the GraphQL query got thrown to a client component — both common Catalyst regressions. Do instead: emit one server-rendered Product block per PDP, and keep the generateMetadata query server-side. Validate with the Rich Results Test.

Platform SEO scaffolding — at a glance

What each platform ships out of the box

Fast facts

• Only Hydrogen ships a dedicated SEO-metadata utility (getSeoMeta).
• Only Hydrogen/Oxygen auto-blocks crawlers on preview/shareable deployments.
• Catalyst proxies BigCommerce’s sitemap — the data lives in BigCommerce, not your app.
• commercetools sitemap queries cap at 500 items/request — large catalogs need paging logic.
• No platform ships automatic redirect management — a 301 map is always your job.
• Platform choice = scaffolding; rendering model (SSR/SSG/CSR) = crawlability.

Three-tier summary

• Ships real tooling: Hydrogen, Catalyst
• Ships SDK helpers, not routes: commercetools, PWA Kit
• Ships nothing SEO-specific: Medusa, Saleor, Elastic Path

Headless platform SEO vetting checklist

Run this before committing to a platform, and again before launch.

Scaffolding audit (what the platform gives you)

• Confirmed what ships for metadata — a utility (Hydrogen) vs. raw API fields you wire into generateMetadata (everyone else).
• Confirmed how the sitemap is produced — shipped route (Hydrogen), proxied (Catalyst), or SDK/API you assemble (commercetools, PWA Kit, Medusa, Saleor, Elastic Path).
• For commercetools: pagination logic in the sitemap generator for catalogs over 500 items per query.
• For PWA Kit: decided the sitemap path (Business Manager vs. custom routing) and scheduled a regeneration job.
• Confirmed there’s a robots.txt route (or built one).

Preview / staging safety

• On Hydrogen: relying on Oxygen’s automatic crawler-block — verified it’s active on shareable links.
• On every other platform: explicitly blocked non-production environments (robots.txt disallow, HTTP auth, or noindex header).
• Checked that no preview/staging URLs are currently indexed (site: search on the preview domain).

Rendering (owned by the hub, but verify per platform)

• curl-checked a product page — title and description present in raw HTML (not CSR-only).
• Confirmed category/collection routes also render server-side.

Migration / redirects

• Complete old-URL → new-URL 301 map built and verified.
• On Stencil→Catalyst: URLs kept identical, or every one mapped.
• Product JSON-LD emitted once, server-side (no double-emission from a third-party app).

Verify what a headless store actually ships

The whole point of this article is “don’t trust the vendor claim.” Here’s how to check the claims yourself, per platform, on a live demo or your own build.

Is the product page server-rendered? (shell)

If the product title isn’t in the raw HTML, the page is CSR — no platform scaffolding saves you from that.

# Product name should appear in the raw HTML, before any JS runs.
curl -s https://yourstore.example/products/some-slug | grep -i '<title>'
curl -s https://yourstore.example/products/some-slug | grep -o 'og:title[^>]*'

Does the sitemap exist, and where does it come from? (shell)

# Hydrogen ships this route; Catalyst proxies it from BigCommerce; others may 404.
curl -sI https://yourstore.example/sitemap.xml
# Peek at the first URLs to confirm it's populated (not an empty shell).
curl -s https://yourstore.example/sitemap.xml | grep -o '<loc>[^<]*</loc>' | head

Is the preview/staging environment blocked? (shell)

The Hydrogen-vs-everyone-else test. On a preview URL, Oxygen should return a disallow-everything robots.txt.

# On a preview/shareable deployment URL:
curl -s https://preview--yourstore.example/robots.txt
# Hydrogen/Oxygen preview: expect "User-agent: *  Disallow: /"
# If it returns your production robots.txt instead, previews can be indexed — block them.

Find canonical + JSON-LD in the rendered head (DevTools Console)

Paste into Chrome DevTools Console on any PDP to see whether canonical and Product schema are actually in the DOM (and whether Product JSON-LD is duplicated — a common Catalyst regression):

// Canonical URL the page declares:
document.querySelector('link[rel="canonical"]')?.href ?? '(no canonical)';

// Every JSON-LD block, parsed — watch for TWO Product blocks:
[...document.querySelectorAll('script[type="application/ld+json"]')]
  .map(s => { try { return JSON.parse(s.textContent); } catch { return s.textContent; } });

One-click canonical checker (bookmarklet)

Save as a bookmark; click it on any product page to alert the declared canonical and how many Product JSON-LD blocks exist (2+ is a problem):

javascript:(()=>{const c=document.querySelector('link[rel="canonical"]')?.href||'(none)';const p=[...document.querySelectorAll('script[type="application/ld+json"]')].filter(s=>/"@type"\s*:\s*"Product"/.test(s.textContent)).length;alert('Canonical: '+c+'\nProduct JSON-LD blocks: '+p);})();

Extract every product URL from a proxied Catalyst sitemap (Python)

Useful when you need the URL list for a redirect map or an audit:

import urllib.request, re

url = "https://yourstore.example/sitemap.xml"
xml = urllib.request.urlopen(url).read().decode("utf-8")
locs = re.findall(r"<loc>(.*?)</loc>", xml)
for loc in locs:
    print(loc)

Remember: a curl that shows an empty <title> or a missing sitemap tells you more than any “SEO-optimized out of the box” claim on a pricing page.

Tools for vetting a headless platform

• curl / view-source — the fastest “is this actually server-rendered?” check. If the product title isn’t in the raw HTML, no platform scaffolding matters yet.
• Google Search Console — URL Inspection — “Test live URL” shows how Googlebot renders a given product/category page and what canonical it sees. The source of truth over your template.
• Rich Results Test — validate Product JSON-LD per PDP, and catch double-emitted schema (a common Catalyst regression).
• Screaming Frog SEO Spider — crawl a staging build to find missing canonicals on paginated listings, orphaned routes, and whether preview URLs are reachable/indexable.
• Ahrefs Site Audit — surface duplicate content, missing metadata, and redirect-chain problems across a headless build at scale.
• site: search on the preview domain — the crude-but-effective test for whether your staging environment has already been indexed.

Frameworks for comparing headless commerce platforms

The two-axis model: rendering and scaffolding

Score the storefront on two independent axes:

• Rendering determines crawlability. SSR or SSG should put product and category content in the initial HTML; CSR can leave crawlers with a shell.
• Platform scaffolding determines what your team must build. Metadata plumbing, sitemap routes, robots.txt, preview blocking, and redirect ownership may ship, require assembly, or be absent.

A platform with strong scaffolding can still have a CSR implementation problem. A pure API platform can still be excellent for SEO when its frontend implements the missing layer. Never collapse the two scores into one vendor claim.

The inherit–build–operate model

Classify every SEO capability before platform selection:

The platform decision is not only build effort. A manual sitemap that works on launch still creates an operating obligation when catalog size, locales, or routing changes.

The evidence ladder

Evaluate a platform claim in this order:

1. Raw response evidence: curl, response headers, and view-source show what a crawler receives.
2. Route evidence: live sitemap, canonical, JSON-LD, and robots.txt behavior.
3. Environment evidence: production and preview deployments behave differently where they should.
4. Vendor documentation: explains intended behavior, but does not prove the implementation shipped correctly.
5. Marketing language: useful only as a question generator.

The evidence ladder keeps “SEO-ready” from substituting for a testable acceptance criterion.

Post-implementation proof for a headless platform

Product HTML and canonical test

Test to run: Fetch a representative product URL with curl -s and inspect the raw response for its title, product name, canonical, and one Product JSON-LD block.

Expected result: The product content and canonical are present before JavaScript, and exactly one server-rendered Product object exists.

Failure interpretation: The route may have fallen back to CSR, metadata may be client-only, or multiple schema producers are active.

Monitoring window: Immediate after every product-template or data-fetching change.

Rollback trigger: A release removes indexable product content from raw HTML or duplicates the product schema across the tested template set.

Sitemap completeness test

Test to run: Fetch the sitemap index and child files, then compare sampled product and category URLs with the commerce catalog. For commercetools, include products on both sides of a pagination boundary.

Expected result: Published canonical URLs appear once, return 200, and the newest catalog changes arrive on the platform’s documented refresh cycle.

Failure interpretation: The route is missing, a source sitemap is not proxied, pagination stops early, or a scheduled generator is stale.

Monitoring window: After launch and after any catalog, locale, routing, or sitemap job change.

Rollback trigger: A deployment drops a material catalog section from the sitemap or starts emitting non-canonical/failed URLs.

Preview-environment isolation test

Test to run: Request a real shareable preview URL’s robots.txt and headers, then use URL Inspection or an external fetch without authenticated cookies.

Expected result: Non-production URLs are inaccessible to anonymous crawlers or carry an environment-wide block; production remains crawlable.

Failure interpretation: The hosting preview safeguard is absent, applies only to one preview pattern, or production rules leaked into staging.

Monitoring window: Immediate for every deployment mode, including branch previews and auth-bypass links.

Rollback trigger: A public preview returns indexable content without the intended block, or the fix accidentally blocks production.

Migration redirect test

Test to run: Request the complete old-URL inventory without following redirects, then validate status and Location against the approved map.

Expected result: Every changed legacy URL returns one permanent redirect to its closest canonical replacement; preserved URLs remain 200.

Failure interpretation: The platform swap omitted a rule, introduced a chain, or changed a URL that was meant to stay stable.

Monitoring window: Before cutover, immediately after cutover, and during the first post-launch crawl reviews.

Rollback trigger: High-value legacy URLs return 404, loop, chain, or redirect to an irrelevant destination.

Test yourself: Headless Commerce Platforms

Five quick questions on how the major headless commerce platforms differ for SEO. Pick an answer for each, then check.

Resources worth your time

My related writing

• JavaScript SEO Issues & Best Practices — the general rendering failure modes (parity, interaction, state, timing) behind any JS-heavy headless storefront; the verify-don’t-trust approach I apply to platform claims here.
• The Beginner’s Guide to Technical SEO — where rendering and crawlability sit in the bigger picture.

My speaking

• How Search Works (SlideShare) — crawling, rendering, indexing, and ranking, i.e. the pipeline every one of these platforms feeds into. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Search Engine Optimization for Hydrogen (Shopify.dev) — the getSeoMeta utility, sitemap/robots routes, and the Oxygen preview-blocking behavior, straight from the source.
• Catalyst Sitemap docs (BigCommerce Developer Center) — how Catalyst proxies BigCommerce’s sitemap index.
• Sitemaps | Frontend Development (commercetools) — the three-sitemap SDK pattern and the 500-item pagination limit.
• Improve SEO with a Sitemap | Composable Storefront (Salesforce Developers) — the Business-Manager-vs-custom-routing branch for PWA Kit.
• BigCommerce Catalyst SEO | Next.js Storefront Best Practices (Dan Kogan, 1Digital Agency) — the one deep practitioner piece on Catalyst SEO: URL parity on migration, generateMetadata regressions, double JSON-LD, and preview-indexing.
• SEO for headless commerce websites (Kirsten Aebersold, Elastic Path) — the vendor’s own SEO position (useful as a case study in what “out of the box” leaves out — no sitemap/canonical/redirect coverage).
• Best headless commerce platforms: 2026 comparison (Vendure) — a broad business/tech-stack comparison of the platforms (with the SEO axis notably missing, which is the gap this article fills).
• Best Headless Commerce Platforms 2026 (Your Next Store) — another platform-selection comparison for cross-referencing the non-SEO decision criteria.

Headless Commerce Platforms

Headless commerce platforms are the commerce engines that expose product, cart, and checkout through APIs instead of rendering their own storefront — Shopify (Hydrogen/Storefront API), BigCommerce (Catalyst), commercetools, Salesforce Commerce Cloud (PWA Kit), Medusa, Saleor, and Elastic Path. Each ships a different amount of SEO tooling out of the box.

Related: Headless Ecommerce, JavaScript SEO, Next.js SEO

Headless Commerce Platforms

Headless commerce platforms are the commerce engines that handle products, carts, and checkout and hand that data to a separate frontend through APIs, rather than rendering their own storefront HTML the way a monolithic platform does. As of mid-2026 the major options are Shopify (via Hydrogen and the Storefront API), BigCommerce (via Catalyst), commercetools, Salesforce Commerce Cloud (via PWA Kit / the Composable Storefront), Medusa, Saleor, and Elastic Path.

For SEO, the thing that matters is not which engine you pick but how much SEO scaffolding each one ships versus leaves for you to build. That scaffolding falls on a spectrum:

• Ships real tooling — Shopify Hydrogen (a getSeoMeta metadata utility, sitemap routes, robots.txt, and automatic crawler-blocking on preview deployments) and BigCommerce Catalyst (a sitemap that proxies BigCommerce’s own index, plus Next.js App Router metadata conventions).
• Ships SDK helpers, not routes — commercetools Frontend (a three-sitemap pattern you wire up yourself via SDK methods) and Salesforce PWA Kit (sitemap setup that branches on your routing, with manual regeneration).
• Ships nothing SEO-specific — Medusa, Saleor, and Elastic Path are pure commerce APIs; SEO is entirely a function of whichever frontend (usually Next.js) you build.

None of these platforms change the underlying rendering decision (SSR/SSG/CSR) that actually determines crawlability — that’s the frontend’s job, covered by the headless ecommerce hub. Platform choice determines how much you inherit, not whether your pages are crawlable.

Related: Headless Ecommerce, JavaScript SEO, Next.js SEO

Changelog