Headless Commerce Platforms

A platform-by-platform SEO comparison of the major headless commerce engines — Shopify Hydrogen, BigCommerce Catalyst, commercetools, Salesforce PWA Kit, Medusa, Saleor, and Elastic Path — covering what each ships out of the box for metadata, sitemaps, redirects, and preview-environment safety, and how to choose.

First published: Jul 3, 2026 · Last updated: Jul 19, 2026 · Advanced
demand #3 in Headless Ecommerce#11 in Ecommerce SEO#194 on the site

Every headless commerce platform's marketing page claims it's SEO-optimized out of the box. The reality is a spectrum. Shopify Hydrogen ships the most real scaffolding — a getSeoMeta metadata utility, sitemap routes, robots.txt, and automatic crawler-blocking on preview deployments. BigCommerce Catalyst proxies BigCommerce's own sitemap and uses Next.js App Router metadata conventions. commercetools Frontend and Salesforce PWA Kit give you SDK helpers, not shipped routes — you assemble sitemaps yourself. Medusa, Saleor, and Elastic Path are pure commerce APIs and ship nothing SEO-specific; your Next.js frontend does all the work. Platform choice determines how much scaffolding you inherit, not whether your pages are crawlable — that's still the rendering decision the headless ecommerce hub owns. The two differentiated risks worth budgeting for: preview/staging environments getting indexed (Hydrogen blocks this automatically; others don't guarantee it), and redirect maps on migration (no platform automates them).

TL;DR — Headless commerce platformsHeadless 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. sit on a spectrum from “ships real SEO scaffolding” to “leaves everything to you.” Shopify Hydrogen ships the most — a getSeoMeta utility, sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. routes, robots.txt, and (via Oxygen) automatic crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-blocking on preview deployments. BigCommerceBigCommerce SEO is the technical, on-page, and content work you do on a store built on BigCommerce — a hosted SaaS ecommerce platform that ships with more native SEO controls than most of its rivals (editable robots.txt, custom URL structures, auto sitemaps, and automatic 301s), while still leaving faceted navigation, multi-storefront hreflang, and review schema for you to handle. Catalyst proxies BigCommerce’s own sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. and uses Next.js App Router generateMetadata conventions. commercetools Frontend and Salesforce PWA KitSalesforce Commerce Cloud SEO is the technical, on-page, and international work you do on a storefront built on Salesforce B2C Commerce (formerly Demandware, commonly SFCC) — an enterprise SaaS platform that ships strong native SEO building blocks (Business-Manager-editable robots.txt, scheduled auto-generated sitemaps, rule-based meta tags, canonical-by-design master/variation products) but leaves hreflang, faceted-navigation URLs, schema, and PWA Kit crawlability to deliberate, platform-literate configuration. give you SDK/API helpers, not shipped routes — you assemble the sitemap yourself, with real paginationPagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does. 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 crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. on shareable links; others don’t guarantee it) and redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. maps (no platform automates them). Platform choice sets how much scaffolding you inherit — not whether pages are crawlable, which is still the renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. decision the hub owns.

Evidence for this claim Choosing a commerce API does not itself determine search rendering; the storefront must produce discoverable content, links, status codes, and metadata. Scope: Google requirements for JavaScript storefronts. Confidence: high · Verified: Google Search Central: JavaScript SEO basics Evidence for this claim Shopify describes Hydrogen as its React-based framework for custom storefronts and Oxygen as its deployment platform. Scope: Shopify-specific platform capability, not Google guidance. Confidence: high · Verified: Shopify Developers: Hydrogen

Platform choice is not the rendering decision

Start here, because it’s the single most common confusion. Whether GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. gets real HTML or an empty shell is decided by your frontend’s renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. model — server-side rendering (SSR), static generation (SSG), or client-side rendering (CSR). That’s the frontend framework’s job, and the Headless Ecommerce SEOAn ecommerce architecture where the commerce engine (Shopify, Commercetools, BigCommerce) is decoupled from the storefront frontend. A separate JavaScript framework (Next.js, Remix, Nuxt) renders pages and fetches product data via API — giving full UI control at the cost of owning all SEO basics yourself. 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 = crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index.; 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 tagsMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored.. That getSeoMeta helper handles titles, descriptions, images, canonical URLs, and JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. — 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 SEONext.js SEO is the set of practices and built-in features that make a Next.js site crawlable, indexable, and rankable — rendering mode (SSG/SSR/ISR/Server Components), the App Router Metadata API, sitemap.ts/robots.ts conventions, next/image, and next/link. 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 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. map.” He also flags recurring Catalyst regressions — generateMetadata returning a client-only fallback because the GraphQL query got thrown to a client component, canonical tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. 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 indexA sitemap index is a sitemap of sitemaps — a single file that lists your other sitemap files instead of listing URLs directly. It's how large sites stay under the 50,000-URL / 50MB-per-sitemap limit while submitting just one file.. 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 paginationPagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does. 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 CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms.-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 contentThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling.. No equivalent automatic guarantee is documented for Catalyst, commercetools, or PWA Kit. And it’s not theoretical: 1Digital Agency reports “Preview deployments indexed by GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.” 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 structuresURL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly., and structured-data gaps, and you should never launch without a verified 301 map. That’s the same lesson the site’s Site MigrationsA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. 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 SEOAn ecommerce architecture where the commerce engine (Shopify, Commercetools, BigCommerce) is decoupled from the storefront frontend. A separate JavaScript framework (Next.js, Remix, Nuxt) renders pages and fetches product data via API — giving full UI control at the cost of owning all SEO basics yourself. — the hub: the SSR/SSG/CSR rendering decision, structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. (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 SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. — the general JS-rendering failure modes that apply to any JS-heavy storefront.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.