Plataformas de comércio headless

TL;DR — A “headmenos commerce platform” is the engine that runs your produtos, cart, e checkout e hands that data para 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 e leave todo of it para you. Pick based on como much você want para build versus inherit.

O que we’re na prática comparing here

In a normal Shopify ou WooCommerce store, one system does everything: it stores seu produtos, processes orders, and renders the páginas shoppers e Google see. A headless setup splits that apart. A commerce engine handles produtos, inventory, e checkout, e hands that data through an API para a separate frontend that renders what people na prática look at.

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

The one thing that matters para choosing

For SEO, the platforms não really differ on whether seu páginas can be rastreared — that comes down para como seu frontend renders páginas, which the Headmenos Ecommerce SEO hub covers in full (SSR, SSG, CSR). O que eles differ on is como much SEO plumbing eles he você para free versus como much você have para build yourself.

Think of it as three groups:

• They give você a lot. Shopify Hydrogen e BigCommerce Catalyst both ship a working example storefront com a sitemap, a robots.txt, e a way para set your title tags e meta descriptions already wired in.
• They give você helpers, não the finished thing. commercetools e Salesforce PWA Kit he você the tools para build a sitemap mas make você assemble it yourself.
• They give você nothing SEO-specific. Medusa, Saleor, e Elastic Path are pure “here’s seu dados de produtos through an API” engines. Every bit of SEO — the sitemap, the metadata, the robots.txt — is on você (or on whatever frontend framework você build, usually Next.js).

The thing a maioria people get wrong

“SEO-optimized out of the box” is a spectrum, não a checkbox. Every vendor’s marketing página says it. But Elastic Path’s own SEO blog post não even mention sitemaps, canonical tags, ou 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 para sitemaps, metadata, redirects, e keeping my staging site out of Google? The respostas vary a lot.

Want the platform-by-platform breakdown, the preview-environment gotcha, e a decision framework para picking one? Switch para the Avançado tab.

TL;DR — Headmenos commerce platforms sit on a spectrum de “ships real SEO scaffolding” para “leaves everything para you.” Shopify Hydrogen ships the a maioria — a getSeoMeta utility, sitemap routes, robots.txt, e (via Oxygen) automatic rastrearer-blocking on preview deployments. BigCommerce Catalyst proxies BigCommerce’s own sitemap índice e uses Next.js App Router generateMetadata conventions. commercetools Frontend e Salesforce PWA Kit give você SDK/API helpers, não shipped routes — você assemble the sitemap yourself, com real pagination limits. Medusa, Saleor, e Elastic Path ship nothing SEO-specific; the frontend owns everything. Two risks are genuinely differentiated by platform: preview-environment leakage (Hydrogen auto-blocks rastrearers on shareable links; others não guarantee it) e redirect maps (no platform automates them). Platform choice sets como much scaffolding você inherit — não whether páginas are rastreável, which is ainda the rendering decision the hub owns.

Platform choice is não the rendering decision

Start here, porque é the single a maioria common confusion. Whether Googlebot gets real HTML ou an empty shell is decided by seu frontend’s rendering model — server-side rendering (SSR), static generation (SSG), ou client-side rendering (CSR). That’s the frontend framework’s job, e the Headmenos Ecommerce SEO hub covers it in depth. I won’t re-derive SSR vs. CSR here.

O que the commerce platform does decide is como much SEO scaffolding você inherit — the sitemap, the metadata plumbing, the robots.txt, the preview-environment handling. A pristine SSR setup on Medusa ainda has no sitemap until você build one; a CSR mistake on Hydrogen ainda tanks a produto página even though Hydrogen ships every other piece. Mantenha the two axes separate: rendering = rastrearability; platform = scaffolding.

The SEO-tooling spectrum

Here’s where the seven platforms land:

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

Ships SDK helpers, não routes (você assemble the sitemap yourself): commercetools Frontend, Salesforce PWA Kit.

Ships nothing SEO-specific (pure commerce API; frontend owns todo 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 headmenos framework, e it ships the a maioria 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 com no Remix dependency at all, e Shopify’s own @shopify/remix-oxygen package now carries a formal deprecation notice telling você 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 ainda ships the getSeoMeta utility, which makes it easier e more consistent para render SEO meta tags. That getSeoMeta helper handles titles, descriptions, images, canonical URLs, e JSON-LD — an actual metadata abstraction, não “bring seu own <head>.” It’s the apenas platform here that ships a dedicated SEO-metadata utility. Shopify also notes that “By default Hydrogen removes query parameters de canonical URLs” — a sensible default você can override in seu meta exports.

Sitemap — shipped e self-refreshing. The Hydrogen skeleton template includes sitemap.xml e per-type sitemap routes out of the box, e its getSitemap utility generates per-refonte-type sitemaps com locale alternates. The sitemap files are cached para 24 hours, so publishing ou unpublishing a produto updates the sitemap automatically within that window — no scheduled job para babysit.

robots.txt — shipped, com 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-produtoion deployment accessible com a shareable link ou an auth bypass token, then Oxygen overrides the deployment’s robots.txt file com a disallow rule para todo bots e rastrearers.” Oxygen (Shopify’s Hydrogen hosting) automatically blocks todo rastrearers on preview/shareable-link deployments. That’s a real problem — duplicate staging conteúdo getting índiceado — that a maioria platforms leave você para solve by hand, e Hydrogen just handles.

What’s left para you: verify no produto ou category route was accidentally left as a refonte route that skips SSR (React Router’s framework mode uses the same server-loader pattern Remix used antes de Hydrogen’s migration), e configure Oxygen caching (the hub’s advanced lens covers stale-cache risk).

BigCommerce headmenos (Catalyst)

Catalyst is BigCommerce’s Next.js App Router reference storefront. Its SEO scaffolding is real mas architecturally diferente de Hydrogen’s.

Sitemap — proxied, não gerado. Per BigCommerce’s Catalyst docs, “Catalyst acts as an intermediary when handling requests para /sitemap.xml.” It fetches the sitemap índice de BigCommerce (against the channel’s canonical URL) e returns the XML. So the sitemap appears para be served de seu storefront, mas the data lives in BigCommerce, não in seu frontend codebase — the opposite of Hydrogen, where the sitemap route lives inside the app. BigCommerce also warns that “If seu storefront also uses third-party systems that generate conteúdo com diferente URLs, você will need to submit multiple sitemaps para cover the URLs de various fontes,” e notes the sitemaps “não need para reside on the mesmo domain as the website eles represent” — flexible para multi-channel setups, mas a footgun if per-channel canonical domains aren’t configured correctly.

Metadata — Next.js conventions. Catalyst populates generateMetadata e the alternates.canonical field per route de 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 de 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 guia: “Do não change established URLs on a Stencil-to-Catalyst migration. Every produto, category, e conteúdo URL should match the legacy structure exactly, ou você need a complete 301 redirect map.” He also flags recurring Catalyst regressions — generateMetadata returning a client-only fallback porque the GraphQL query got thrown para a client component, canonical tags missing on paginated listing páginas, 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, e its SEO scaffolding is proportionally thinner — você get SDK helper methods, não shipped routes.

Per commercetools’ Frontend docs, the platform generates three separate sitemaps — static páginas, produto páginas, e category páginas — combined into a sitemap índice. Static páginas come de sdk.page.getPages(), produtos de extensions.product.query(), and categories de extensions.product.queryCategories(). But setup is não 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) e a postbuild script para assemble the final /sitemap.xml. And the produto/category queries are cursor-paginated com a 500-item limit per request, so a large catalog needs pagination logic inside seu sitemap generator. This is the a maioria build-it-yourself of the enterprise platforms para sitemaps specifically — which tracks com commercetools’ whole no-opinionated-frontend positioning.

Salesforce Commerce Cloud headmenos (PWA Kit / Composable Storefront)

PWA Ké SEO tooling is the a maioria fragmented e manual of the platforms com an oficial reference storefront.

Sitemap — the path branches. Per Salesforce’s docs, if seu routes are configured in Business Manager, você create the sitemap in Business Manager; if routes are managed outside it (custom PWA Kit routing), você build ou supplement the sitemap via an API endpoint instead. There’s no single automatic path — it depends on como 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 para schedule a job to keep the sitemap atual — 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, não an oficial statement.

Metadata — tied para Page Designer. PWA Ké usePage() hook (from @salesforce/commerce-sdk-react) e <Page> component expose página name, description, e route para SEO metadata — mas that’s tied para Salesforce’s CMS-like Page Designer conteúdo model, não a dedicated SEO utility like Hydrogen’s getSeoMeta.

Medusa, Saleor, e Elastic Path — pure APIs

These three are the “leaves everything para you” tier, e é worth being blunt about what that means.

Medusa is a pure commerce backend. There’s no dedicated Medusa SEO documentação because Medusa has no opinion on frontend rendering at all. Its Next.js Starter Storefront supports the App Router com React Server Components (so SSR is available), but metadata, sitemap, e canonical mechanics are entirely inherited de whatever Next.js conventions você implement. In practice virtually every Medusa storefront is Next.js — so the Next.js SEO article is seu real reference, não Medusa’s docs.

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

Elastic Path is API-first com metadata as raw fields você wire up yourself. Its produto e category entities support custom fields para SEO metadata that can be, in Elastic Path’s words, “accessed via APIs just like the conteúdo that você render para your customers” — mas that’s a build-your-own-schema pattern, não a shipped utility. Its slug refonte is described as a “lower case, uri friendly string” para building URLs. Notably, Elastic Path’s own SEO para headmenos commerce blog post (by Kirsten Aebersold — vendor conteúdo, não neutral) does say “If you’re dynamically building a página com a JavaScript framework alone, você might want para look into serving up cached versions of the páginas para the bots” — mas it nunca covers sitemaps, canonical tags, redirects, ou preview environments. Quando even the vendor’s own SEO página skips half of what você need, “SEO-optimized out of the box” is doing a lot of work.

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

Preview e staging leakage — the differentiated risk

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

Hydrogen/Oxygen automatically disallows todo rastrearers on preview e shareable-link deployments — a built-in safeguard against seu staging site getting índiceado and competing com produtoion as duplicate conteúdo. No equivalent automatic guarantee is documented para Catalyst, commercetools, ou PWA Kit. And é não theoretical: 1Digital Agency reports “Preview deployments índiceado by Googlebot” as a recurring real-world failure mode on Catalyst migrations. That’s a single practitioner fonte rather than an oficial platform statement, so treat the specific Catalyst claim as one credible data point — mas the underlying lesson is platform-agnostic: if seu platform não auto-block preview rastrearers, block them yourself (a robots.txt disallow, HTTP auth, or a noindex header on every non-produtoion environment). On the “everything-to-you” platforms, this is entirely on você by definition.

Redirect management — a migration concern, não a platform feature

No platform reviewed ships an automatic redirect system. Every headmenos migration — Stencil para Catalyst, monolith para headless, one commerce engine para another — needs an explicit 301 map de old URLs para new. The consensus across migration-focused trade posts is consistent: re-platforming failures ala maioria sempre trace back para redirect maps, URL structures, e structured-data gaps, e você should nunca launch sem a verified 301 map. That’s the mesmo lesson the site’s Site Migrations article covers in full — I’ll cross-reference it para the checklist rather than re-derive it here. The platform-specific angle is just this: não assume qualquer of these engines handles redirects para you. None do.

Portability is the underrated upside

One myth worth killing: switching commerce platforms does not mean rebuilding seu SEO from scratch. The rendering layer — seu Next.js (or React Router) storefront — is what determines rastrearability, e é largely portable across commerce backends. A Next.js storefront can point at BigCommerce, Medusa, Saleor, ou commercetools com mostly data-layer changes. O que changes when você swap platforms is the scaffolding: where the sitemap data comes from, whether there’s a metadata utility, como redirects e previews are handled. That’s a meaningful re-wire, mas é não “start over.”

And não over-índice on API quality as an SEO signal, either. A platform’s GraphQL/REST API apenas determines what data is available para build metadata e sitemaps from. Whether that data na prática reaches Google server-side is a frontend/rendering decision — which, again, the hub owns.

Onde para go next

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

AI summary

A condensed take on the Advanced version:

• Platform choice ≠ rendering choice. Crawlability comes de the frontend’s rendering model (SSR/SSG/CSR — owned by the headmenos ecommerce hub). The commerce platform decides como much SEO scaffolding você inherit.
• A spectrum, three tiers:
  • Ships real tooling: Shopify Hydrogen (getSeoMeta metadata utility, sitemap routes, robots.txt, auto preview-rastrearer blocking via Oxygen) e BigCommerce Catalyst (sitemap proxied de BigCommerce, Next.js generateMetadata conventions).
  • Ships SDK helpers, não routes: commercetools Frontend (three-sitemap pattern via SDK methods, manual route wiring, 500-item pagination limit) e 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 todo SEO.
• Metadata: Hydrogen’s getSeoMeta is the apenas 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 rastrearers on shareable links; no equivalent guarantee para Catalyst, commercetools, or PWA Kit (1Digital reports Catalyst previews getting índiceado in the wild). Block them yourself if the platform não.
• 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, não seu whole SEO.
• Myth para kill: “SEO-optimized out of the box” is a spectrum — Elastic Path’s own SEO post não even cover sitemaps, canonical tags, ou redirects.

Which headmenos commerce platform (for SEO)?

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

Official documentação

Primary-fonte platform documentação, per commerce engine.

Shopify Hydrogen

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

BigCommerce Catalyst

• Catalyst Sitemap docs — como Catalyst proxies BigCommerce’s sitemap índice. (This URL moved de developer.bigcommerce.com para 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, e the 500-item pagination limit.

Salesforce Commerce Cloud (PWA Kit)

• Improve SEO com a Sitemap | Composable Storefront — the Business-Manager-vs-custom-routing branch e 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 de seu Next.js implementation.
• Elastic Path — SEO para headmenos commerce websites — vendor blog; useful as the platform’s stated SEO position (note it omits sitemaps/canonical/redirects).

Quotes de the fonte

Verbatim statements de the platform docs e one named practitioner. Deep links jump to the quoted passage where the fonte supports it.

Shopify Hydrogen — the metadata utility

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

Shopify Hydrogen — preview-rastrearer blocking

• “If você make a non-produtoion deployment accessible com a shareable link ou an auth bypass token, then Oxygen overrides the deployment’s robots.txt file com a disallow rule para todo bots e rastrearers.” — Shopify.dev, Hydrogen SEO docs.

BigCommerce Catalyst — sitemap proxying

• “Catalyst acts as an intermediary when handling requests para /sitemap.xml.” — BigCommerce Developer Center, Catalyst Sitemap docs.
• “If seu storefront also uses third-party systems that generate conteúdo com diferente URLs, você will need para submit multiple sitemaps para cover the URLs de various fontes.” — BigCommerce Developer Center, Catalyst Sitemap docs.
• “The sitemaps não need para reside on the mesmo domain as the website eles represent.” — BigCommerce Developer Center, Catalyst Sitemap docs.

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

• “Do não change established URLs on a Stencil-to-Catalyst migration. Every produto, category, e conteúdo URL should match the legacy structure exactly, ou você need a complete 301 redirect map.” Read the guia
• “Use generateMetadata e SSR-emitted JSON-LD para every PDP e PLP. Do não rely on client-side schema injection.” Read the guia

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

• “If you’re dynamically building a página com a JavaScript framework alone, você might want para look into serving up cached versions of the páginas para the bots.” Read the post

Mistakes that cost you

Concrete failure modes I’d check para on qualquer headmenos commerce build.

Trusting “SEO-optimized out of the box” at face value. Por que é wrong: é a spectrum, não a guarantee. Hydrogen ships real scaffolding; Medusa, Saleor, e Elastic Path ship nothing SEO-specific. Elastic Path’s own SEO blog post não even mention sitemaps, canonical tags, ou redirects. Do instead: ask the specific questions per platform — what ships para sitemaps, metadata, redirects, e preview-blocking? — e budget the gaps as build work.

Assuming every platform keeps staging out of Google. Por que é wrong: apenas Hydrogen/Oxygen auto-blocks rastrearers on preview/shareable deployments. There’s no documented equivalent para Catalyst, commercetools, ou PWA Kit, e at least one practitioner (1Digital Agency) reports Catalyst preview deployments getting índiceado by Googlebot in the wild. (Single-fonte claim — treat as one credible data point, não settled fact.) Do instead: block non-produtoion environments yourself — robots.txt disallow, HTTP auth, ou a noindex header on every preview/staging URL. Never assume the platform does it.

Treating a platform swap as “rebuild todo SEO de scratch.” Por que é wrong: the rendering layer (seu Next.js/React Router frontend) is what determines rastrearability e is largely portable across backends — a Next.js storefront can point at BigCommerce, Medusa, Saleor, ou commercetools com mostly data-layer changes. Do instead: re-wire apenas the scaffolding that na prática differs — sitemap data fonte, metadata utility, redirect handling, preview-blocking. Reuse the frontend.

Judging SEO by API quality. Por que é wrong: the GraphQL/REST API apenas determines what data is available para build metadata e sitemaps from. Whether that data reaches Google depends on server-side rendering — a frontend decision, não an API one. Do instead: evaluate the rendering model (per the hub) separately de the API. A great API com a CSR frontend ainda ships empty HTML para rastrearers.

Skipping the redirect map on migration. Por que é wrong: no platform reviewed automates redirects. Re-platforming failures ala maioria sempre trace back para missing 301 maps, changed URL structures, e structured-data gaps. Do instead: build e verify a complete old-URL→new-URL 301 map antes de launch. On Stencil→Catalyst specifically, keep URLs identical ou map every one. See the Site Migrations article para the checklist.

Letting Product JSON-LD render twice, ou client-side. Por que é wrong: 1Digital flags Product JSON-LD emitted twice (a custom component plus a third-party app) e generateMetadata returning a client-only fallback porque the GraphQL query got thrown para a client component — both common Catalyst regressions. Do instead: emit one server-rendered Product block per PDP, e keep the generateMetadata query server-side. Validate com the Rich Results Test.

Platform SEO scaffolding — at a glance

O que each platform ships out of the box

Fast facts

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

Three-tier summary

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

Headmenos platform SEO vetting checklist

Execute this antes de committing para a platform, e again antes de launch.

Scaffolding audit (what the platform gives you)

• Confirmed what ships para metadata — a utility (Hydrogen) vs. raw API fields you wire into generateMetadata (everyone else).
• Confirmed como the sitemap is produced — shipped route (Hydrogen), proxied (Catalyst), ou SDK/API você assemble (commercetools, PWA Kit, Medusa, Saleor, Elastic Path).
• For commercetools: pagination logic in the sitemap generator para 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 rastrearer-block — verified é active on shareable links.
• On every other platform: explicitly blocked non-produtoion environments (robots.txt disallow, HTTP auth, ou noindex header).
• Checked that no preview/staging URLs are atually índiceado (site: search on the preview domain).

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

• curl-checked a produto página — title e 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 e verified.
• On Stencil→Catalyst: URLs kept identical, ou every one mapped.
• Product JSON-LD emitted once, server-side (no double-emission de a third-party app).

Verify what a headmenos store na prática ships

The whole point of this article is “não trust the vendor claim.” Here’s como para check the claims yourself, per platform, on a live demo ou seu own build.

Is the produto página server-rendered? (shell)

If the produto title não é in the raw HTML, the página is CSR — no platform scaffolding saves você de 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, e 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 qualquer PDP para see whether canonical e Product schema are na prática in the DOM (e 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 qualquer produto página para alert the declared canonical e how mqualquer 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 produto URL de a proxied Catalyst sitemap (Python)

Useful when você need the URL list para a redirect map ou 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> ou a missing sitemap tells você mais than qualquer “SEO-optimized out of the box” claim on a pricing página.

Tools para vetting a headmenos platform

• curl / view-fonte — the fastest “is this na prática server-rendered?” check. If the produto title não é in the raw HTML, no platform scaffolding matters yet.
• Busca do Google Console — URL Inspection — “Test live URL” shows como Googlebot renders a given produto/category página e what canonical it sees. The fonte of truth over your template.
• Rich Results Test — validate Product JSON-LD per PDP, e catch double-emitted schema (a common Catalyst regression).
• Screaming Frog SEO Spider — rastrear a staging build para find missing canonicals on paginated listings, orphaned routes, e whether preview URLs are reachable/índiceable.
• Ahrefs Site Audit — surface duplicate conteúdo, missing metadata, e redirect-chain problems across a headmenos build at scale.
• site: search on the preview domain — the crude-but-effective test para whether your staging environment has already been índiceado.

Frameworks para comparing headmenos commerce platforms

The two-axis model: rendering e scaffolding

Score the storefront on two independent axes:

• Rendering determines rastrearability. SSR ou SSG should put produto e category conteúdo in the initial HTML; CSR can leave rastrearers com a shell.
• Platform scaffolding determines what seu team must build. Metadata plumbing, sitemap routes, robots.txt, preview blocking, e redirect ownership may ship, require assembly, ou be absent.

A platform com strong scaffolding can ainda have a CSR implementation problem. A pure API platform can ainda be excellent para 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 antes de platform selection:

The platform decision is não apenas build effort. A manual sitemap that works on launch still creates an operating obligation when catalog size, locales, ou routing changes.

The evidência ladder

Evaluate a platform claim in this order:

1. Raw response evidência: curl, response headers, e view-fonte scomo what a rastrearer receives.
2. Route evidência: live sitemap, canonical, JSON-LD, e robots.txt behavior.
3. Environment evidência: produtoion e preview deployments behave differently where eles should.
4. Vendor documentação: explains intended behavior, mas does não prove the implementation shipped correctly.
5. Marketing language: useful apenas as a question generator.

The evidência ladder keeps “SEO-ready” de substituting para a testable acceptance criterion.

Post-implementation proof para a headmenos platform

Product HTML e canonical test

Test para run: Fetch a representative produto URL com curl -s e inspect the raw response para its title, produto name, canonical, e one Product JSON-LD block.

Expected result: The produto conteúdo e canonical are present antes de JavaScript, e exactly one server-rendered Product object exists.

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

Monitoring window: Immediate depois de every produto-template ou data-fetching change.

Rollback trigger: A release removes índiceable produto conteúdo de raw HTML or duplicates the produto schema across the tested template set.

Sitemap completeness test

Test para run: Fetch the sitemap índice e child files, then compare sampled produto e category URLs com the commerce catalog. For commercetools, include produtos on both sides of a pagination boundary.

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

Failure interpretation: The route is missing, a fonte sitemap is não proxied, pagination stops early, ou a scheduled generator is stale.

Monitoring window: After launch e depois de qualquer catalog, locale, routing, ou sitemap job change.

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

Preview-environment isolation test

Test para run: Request a real shareable preview URL’s robots.txt e headers, then use URL Inspection ou an external fetch sem authenticated cookies.

Expected result: Non-produtoion URLs are inaccessible para anonymous rastrearers or carry an environment-wide block; produtoion remains rastreável.

Failure interpretation: The hosting preview safeguard is absent, applies apenas to one preview pattern, ou produtoion rules leaked into staging.

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

Rollback trigger: A public preview returns índiceable conteúdo sem the intended block, ou the fix accidentally blocks produtoion.

Migration redirect test

Test para run: Request the complete old-URL inventory sem following redirects, then validate status e Location against the approved map.

Expected result: Every changed legacy URL returns one permanent redirect para 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 para stay stable.

Monitoring window: Before cutover, immediately depois de cutover, e during the first post-launch rastrear reviews.

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

Test yourself: Headmenos Commerce Platforms

Five quick questions on como the major headmenos commerce platforms differ para SEO. Pick an resposta para each, then check.

Refontes worth seu time

My related writing

• JavaScript SEO Issues & Best Practices — the general rendering failure modes (parity, interaction, state, timing) behind qualquer JS-heavy headmenos storefront; the verify-não-trust approach I apply para platform claims here.
• The Beginner’s Guide para Technical SEO — where rendering e rastrearability sit in the bigger picture.

My speaking

• How Search Works (SlideShare) — rastrearing, rendering, índiceação, e ranqueamento, i.e. the pipeline every one of these platforms feeds into. (My standing disclaimer applies: “This is my understanding of systems… não going para be 100% complete ou accurate.”)

From around the industry

• Search Engine Optimization para Hydrogen (Shopify.dev) — the getSeoMeta utility, sitemap/robots routes, e the Oxygen preview-blocking behavior, straight de the fonte.
• Catalyst Sitemap docs (BigCommerce Developer Center) — como Catalyst proxies BigCommerce’s sitemap índice.
• Sitemaps | Frontend Development (commercetools) — the three-sitemap SDK pattern e the 500-item pagination limit.
• Improve SEO com a Sitemap | Composable Storefront (Salesforce Developers) — the Business-Manager-vs-custom-routing branch para 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, e preview-índiceação.
• SEO para headmenos 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 headmenos 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 Headmenos Commerce Platforms 2026 (Your Next Store) — another platform-selection comparison para cross-referencing the non-SEO decision criteria.

Registro de alterações