Salesforce Commerce Cloud SEO

How SEO works on Salesforce Commerce Cloud (B2C Commerce / SFCC, formerly Demandware) — the strong native building blocks (Business-Manager-editable robots.txt, scheduled auto-sitemaps, rule-based meta tags, canonical-by-design master/variation products) and the parts you still have to build by hand (hreflang, faceted-nav URLs, schema, and headless crawlability on PWA Kit or Salesforce's newer Storefront Next framework).

First published: Jul 2, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #6 in Ecommerce Platforms#30 in Platform SEO#193 in Technical SEO#267 on the site

Salesforce Commerce Cloud (B2C Commerce, formerly Demandware — SFCC for short) gives you strong native SEO building blocks: an editable per-site robots.txt in Business Manager, auto-generated XML sitemaps as a scheduled job, rule-based Meta Tag Rules for catalog-wide titles and descriptions, and a canonical-by-design master/variation product model that maps almost exactly onto Google's ProductGroup schema. What it leaves you is the work that actually decides rankings at enterprise scale: hreflang (no dedicated B2C admin feature — sitemap alternate URLs or custom link tags), faceted/refinement URLs (custom development), structured data (a template/developer job, not a toggle), and headless crawlability on PWA Kit or Salesforce's newer Storefront Next framework (SSR is necessary but not sufficient — test with ?__server_only on PWA Kit; confirm the equivalent on Storefront Next). Nothing works well without deliberate configuration; the platform isn't the limitation, unfamiliarity with it is.

TL;DR — SFCC (B2C Commerce, formerly Demandware) ships strong native SEO building blocks: a per-site robots.txt you edit in Business Manager, XML sitemapsAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags. auto-generated as a scheduled job, rule-based Meta Tag Rules for catalog-wide titles/descriptions, and a canonical-by-design master/variation product model that maps almost 1:1 onto Google’s ProductGroup/hasVariant/isVariantOf schema. The work it leaves you is what scales: hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. (no dedicated B2C feature — 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. “Include Alternate URLs” or custom <link> tags), faceted/refinement URLs (custom dev), 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. (a template job, not a toggle), and headless 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. on PWA Kit or Salesforce’s newer Storefront Next framework (SSR is necessary but not sufficient — test with ?__server_only on PWA Kit; confirm the equivalent on Storefront Next). And the single biggest architectural fork is whether a multi-region brand is one site with many locales or many sites — that decides how many full SEO config surfaces you keep in sync.

Evidence for this claim Salesforce B2C Commerce provides sitemap generation that merchants configure and run for storefront URLs. Scope: Salesforce B2C Commerce; scheduling and content selection require configuration. Confidence: high · Verified: Salesforce Developers: Create a sitemap Evidence for this claim Salesforce documents server-side rendering and crawler considerations for PWA Kit storefronts. Scope: Salesforce PWA Kit; SSR alone does not guarantee indexing or ranking. Confidence: high · Verified: Salesforce Developers: PWA best practices

The frame: strong native tools, steep platform literacy

Most SFCC SEO content is either thin agency marketing or developer docs with zero SEO framing. The honest take is in between: SFCC has more native, admin-configurable SEO tooling than most competing platforms — but nothing works well without deliberate setup, and several defaults will hurt you if you leave them alone. Sort every task into “native building block” vs. “you have to build it,” and the platform stops being mysterious.

Two things to understand before anything else:

  1. Business Manager is where SEO lives. The SEO hub is Merchant Tools → site → SEO, and it splits into Canonical URLHow search engines pick one canonical URL among duplicates and consolidate signals onto it. tags, URL RedirectsA 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., SitemapsA 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., Robots, Meta Tag Rules, and URL Rules/Aliases. Each is a separate screen with its own rules.
  2. The master/variation product model shapes everything. A single master product owns multiple variation products (by color, size). That model is the central SEO decision point, and it happens to mirror how Google wants you to mark up variants — more on that below.
  3. Name your storefront architecture before you name a fix. “Salesforce Commerce Cloud” now spans at least four distinct storefront generations that behave differently for SEO: the legacy SiteGenesis pipeline architecture, the current SFRA (Storefront Reference Architecture), the established headless PWA Kit (Composable Storefront), and, as of the 2026 B2C Commerce release cycle, Salesforce’s newer Storefront Next React framework. Admin paths, cartridge behavior, and renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. mechanics differ across them — a fix verified on one doesn’t automatically transfer to another. This article’s Business Manager screens apply broadly across SFRA/SiteGenesis; the PWA Kit-specific mechanics later in this piece are scoped explicitly where they apply.

Native building blocks: per-site editable robots.txt, scheduled auto-generated XML sitemapsAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags. (with optional hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. and last-modifiedA conditional request lets a crawler (or browser) ask a server 'has this changed since I last fetched it?' — using If-Modified-Since (checked against your Last-Modified header) and/or If-None-Match (checked against your ETag). If nothing changed, the server replies 304 Not Modified with no body, so the crawler reuses its existing copy instead of re-downloading the page. dates), URL Rules + Hostname Aliases for locale-aware clean URLs, canonical-by-design variation products, rule-based Meta Tag Rules, automatic 301s on in-Business-Manager URL changes, and PWA Kit SSR for the first load.

Yours to build: hreflang, faceted/refinement URLs, structured data, multi-locale robots.txt handling, H1 templating, and (in a headless build) all on-page tag management.

The architecture fork that shapes everything: sites vs. locales

Before you touch a single SEO screen, settle this: is your multi-region brand modeled as one site with multiple locales, or multiple sites (one per locale or region)? In SFCC, multi-region storefronts are usually built as separate sites in Business Manager. That matters because each site is its own complete SEO configuration surface — its own sitemap job, its own robots.txt, its own Meta Tag Rules, its own URL Rules. Ten sites means ten of everything to keep in sync by hand. Name this decision explicitly early, because it silently multiplies every other section of this article.

URL structure: URL Rules vs. Hostname Aliases

SFCC gives you two configuration paths, and the right one depends on how complex your locale setup is:

  • URL Rules (Merchant Tools → site → SEO → URL Rules) map locale, category, and product path segments to a pattern. They’re simpler but less flexible — you pick one of alternative hostnames, URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO., or paths for locale routing.
  • Hostname Aliases (Merchant Tools → site → SEO → Aliases) are a JSON alias file offering more capability — including a mixed approach, like ccTLDCountry-code top-level domain like .de or .co.uk — a strong geotargeting signal.-style hostnames for some locales and subfolder-style locales in the same site. If you need mixed routing, it has to go through the alias file.

The mechanics worth knowing:

  • Force lowercase. SFCC’s own URL configuration guidance tells you to select Lower Case so you don’t generate multiple URLs with different cases of the same text. Practitioners note lowercase is generally preferred by 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..
  • Use hyphens for whitespace. Whitespace can be URL-encoded (%20), or replaced with plus/underscore/minus/period. Salesforce’s own SEO-URL guidance points out that search engines treat hyphens as separators but underscores as joiners (two underscore-joined words read as one), so the hyphen (minus) is the cleanest choice. NOVOS makes the same recommendation over the default %20.
  • category vs. category-path. For sites more than two or three categories deep, use category rather than category-path; but if you have duplicate category names under different parents, use category-path to disambiguate.
  • Product IDs auto-append. You don’t add the product ID to the rule — B2C Commerce always appends it automatically, with a .html extension. Practitioners note there’s no way to remove the .html without custom development.
  • Assign products to the domain, not a category path. NOVOS recommends this to reduce duplication and complexity, because products can be assigned to multiple categories, which makes a category-based URL segment unstable.
  • General URL hygiene from Salesforce’s own guidance: keep URLs readable and short, use as few folders as possible, avoid parameters, integrate keywords, and don’t put a page-type indicator, a proprietary sc.html extension, or the word demandware in the URL.

The classic pitfall: duplicate homepages from unmapped Default-Start and Home-Show pipelines resolving to www and non-www variants. Map them explicitly or you get duplicate sites generated by hosts with and without the www. And one alias-file gotcha practitioners flag repeatedly: the alias file must declare version 1 or the system ignores it entirely.

Compared to a platform like BigCommerce (which offers preset 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 removes prefixes with a dropdown) or Shopify (which forces /products/ and /collections/), SFCC’s URL layer is far more configurable — and far more its own job to get right.

XML sitemaps

Sitemap generation is a scheduled Business Manager job, not a static file you maintain. You reach it via App Launcher → Merchant Tools → site → SEO → Sitemaps, and configure the job’s schedule on the Job tab. Salesforce’s guidance is to schedule it for low-traffic times (early morning) to avoid CPU and memory spikes, and to run it after your daily data replication from staging.

Three things that trip people up:

  • Configure per instance type. Sitemap settings can’t be replicated between Staging and Production or Development — you set them individually on each instance. This is the opposite of most site preferences.
  • changefreq/priority are dead weight. Google has confirmed it ignores these in sitemaps. Don’t spend engineering effort tuning them. Do keep lastmod accurate — it’s auto-applied to the generated sitemap and it’s a real signal for what to re-crawl.
  • Hreflang rides on a checkbox. You can embed hreflang by ticking “Include Alternate URLs”, which adds hreflang annotations inside the standard sitemaps. The caveat: at enough locales this pushes you past the per-file link threshold, at which point you need custom sitemaps built with a solution architect.

Headless is a separate mechanism. For a PWA Kit storefront, Salesforce’s own “Improve SEO with a Sitemap” guide is explicit that sitemaps “provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.” If your routes are configured in Business Manager, generate the sitemap there; otherwise you upload one via the SCAPI uploadCustomSitemapAndTriggerSitemapGeneration endpoint. Wiring it up requires a vanity domain (embedded CDN or a subdomain like seo.example.com), a matching hostname alias, and the sitemap reachable at example.com/sitemap_index.xml; in PWA Kit you add app.get('/sitemap_index.xml', runtime.serveStaticFile('static/sitemap_index.xml')) in ssr.js and expose the file via ssrShared in the app config.

Robots.txt

There are two distinct mechanisms, and confusing them causes real deployment bugs:

  1. Business Manager site preference (the recommended default path). App Launcher → Merchant Tools → site → SEO → Robots lets you write a per-site robots.txt (up to 50,000 characters). It’s stored as a site preference and can be replicated between instances.
  2. Cartridge-level static file (custom storefront / SFRA). A robots.txt placed in cartridge/static/default of a custom cartridge, managed via UX Studio. This version can only move between instances via code replication, because the static directory is cartridge-specific, not site-specific.

Two gotchas:

  • Cache invalidation. With caching enabled, you must invalidate the static content cache for a new cartridge-level robots.txt to be served.
  • Robots is domain-scoped, not subfolder-scoped. If you run multiple locales in subfolders, one robots.txt at the domain root has to satisfy every locale’s needs — plan the rules to cover all of them.

The practitioner philosophy, which I agree with: keep robots.txt minimal. Use 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. and noindex to control what’s served in results; robots.txt controls crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., not indexingStoring 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., so over-relying on it is the actual anti-pattern. Keep dev/staging non-crawlable via the deployed cartridge default, and configure production deliberately. (The platform-agnostic mechanics are in crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. and canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it..)

Canonical URLs and the master/variation product model — the differentiating section

This is where SFCC’s data model and Google’s own guidance line up almost perfectly, and where most SFCC content stops short.

In the SFCC pattern described here, child variation URLs point `rel=canonical` to the master PDP, while ProductGroup connects the structured-data family.

The SFCC master product is the canonical product detail page. Each color, size, or other child variation URL points rel canonical to the master URL. In structured data, the master maps to ProductGroup and child Product entities connect through hasVariant and isVariantOf. Verify the public storefront output.

SFCC represents a product’s color/size variations as a single master (base) product with child variation products. Salesforce’s recommendation is to canonicalize the variation product URLs to the master product to preserve or improve rankings — i.e., point every color/size PDP’s rel="canonical" at the base product so ranking signals consolidate onto one URL.

Now look at what Google recommends for exactly this “one product, many variations” situation. Google’s product-variant guidance is to “use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID to group such variants together.” That’s a conceptual match to SFCC’s master/variation model:

  • The master product is Google’s ProductGroup.
  • The variation products are the hasVariant members (or, in the “separate” pattern, each Product uses isVariantOf to reference the group’s @id).
  • Google documents both a nested pattern (ProductGroup.hasVariant“the most compact and natural representation of a product group”) and a separate pattern (Product.isVariantOf — which “might be easier for some content management systems (CMSes) to generate”). The separate pattern is the natural fit for how SFCC templates variation products across independent PDP renders.

For a single-page variant selector, Google says to keep “only one distinct canonical URL for the overall ProductGroup — which is precisely the “variation → master” canonical rule SFCC already recommends.

Make the two agree, because Google is explicit that your canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. signals must be consistent. On its consolidate-duplicate-URLs guidance, rel="canonical" is “a strong signal that the specified URL should become canonical,” sitemap inclusion is “a weak signal,” and “these methods can stack and thus become more effective when combined.” But don’t contradict yourself — Google warns: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques (for example, don’t specify one URL in a sitemap, but a different URL for that same page using rel="canonical").” On SFCC, that means your variation-product rel="canonical", your sitemap, your hreflang, and your internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. all have to name the same master URL. And “when linking within your site, link to the canonical URL rather than a duplicate URL” — so link internal navigation to the master product, not to specific variation URLs.

(The general variant-schema deep dive is in product variant SEOEcommerce SEO is the practice of optimizing an online store so its product and category pages rank in organic search and attract purchase-intent visitors. It uses the same Google algorithm as any other site, but compounds the usual SEO work with commerce-specific challenges like faceted navigation, product variants, and platform-imposed URLs.; the canonical mechanics are in canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it..)

Meta Tag Rules

Titles and descriptions have two implementation paths: manual entry per object (Category/Product → Page Title / Page Description fields), or rule-based dynamic generation via Meta Tag Rules (Merchant Tools → site → 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.), which apply formulas across page types.

  • Basic dynamic rule: a category title like ${Category.Name} | Example Brand.
  • Hybrid override + fallback: ${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name} lets merchandisers override specific pages while the rule stays the catalog-wide default. This is the pattern to standardize on — rules scale, but any one-off exception either uses this hybrid syntax or inherits the generic rule.
  • Localize the connectives. For localized rules, translate any connectives (like the | separator’s surrounding words) and set them at language or language-country level.
  • H1 is a limitation. Unlike titles and descriptions, there’s no standard Meta Tag Rules syntax to template H1 tagsAn H1 tag is the HTML `<h1>` element that marks a page's primary heading — the big visible headline at the top of the content. It helps users, search engines, and screen readers understand what the page is about. dynamically — H1 templating requires custom development.

Redirects

SFCC has some native, automatic 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. behavior plus manual tools:

  • Automatic 301s fire when you override a category/product URL inside Business Manager, and SFCC auto-corrects misspelled PDP URLs as long as the underlying product ID is intact.
  • Three manual tools: URL Redirects for one-to-one mappings, Static Mappings for legacy URL patterns redirecting to static resources, and Dynamic Mappings for complex wildcard-based patterns.
  • Status codes: use 301 for permanent (or 308 if altered via custom development) and 307 for temporary. (Background on choosing between them is in Ahrefs’ 11 types of redirects and 301 vs. 302 guides.)
  • Point at object IDs, not hard-coded paths. NOVOS recommends redirecting to object types/IDs rather than literal URL strings to prevent errors and redirect loops when the destination URL later changes.

The precedence rule matters and it’s a direct developer-docs quote: “If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.”

Migration framing: on an SFRA relaunch, the redirect strategy is the single most critical SEO component for preserving rankings — Acxiom’s Salesforce practice puts it at 60–70% of launch SEO effort. That’s consistent with the broader lesson that a migration takes more than a checklist to go well.

Structured data / schema — name the gap honestly

Here’s the honest part most content skips: on SFCC there’s no native “turn on product schemaProduct schema (schema.org/Product) is structured data that tells search engines a page's product name, price, availability, and reviews so it can appear in Shopping-style rich results. It's separate from a Google Merchant Center feed, though Google reconciles the two.” toggle in Business Manager comparable to Meta Tag Rules or canonical handling. Unlike BigCommerce (whose Cornerstone theme ships 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. product schema out of the box), schema on SFCC is a template/developer responsibility. The SFRA reference storefront includes some product/breadcrumb schema in template code, but that’s developer-implemented, not an admin feature. Treat schema as a build task, not a checkbox — and lean on the ProductGroup/variant pattern from the canonical section as your target shape, since JSON-LD is Google’s recommended format when your setup allows it.

One renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. constraint to design around, especially for headless builds: Google’s guidance is that structured data should be present in the server-rendered HTML rather than injected only during client-side hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers.. On a PWA Kit store, that means the JSON-LD has to be in the SSR output — see the headless section.

Hreflang and multi-site/locale architecture

Disambiguate B2B from B2C first. Salesforce’s clean, dedicated “Alternate Language Links” hreflang feature is a B2B Commerce feature — it does not exist as a dedicated screen in B2C Commerce. Search results and even some agency blogs blur the two Clouds. In B2C Commerce, hreflang runs through the sitemap’s “Include Alternate URLs” checkbox (covered above), not a dedicated alternate-language admin screen.

So the two realistic implementation paths are:

  1. Sitemap-embedded hreflang via “Include Alternate URLs” — simple, but can blow past the per-file sitemap size limit at scale.
  2. Custom <link rel="alternate" hreflang="x"> tags emitted directly in the page <head> — necessary once you have too many locale/URL combinations for the sitemap approach.

Standard hreflang hygiene still applies, and it’s spelled out in Google’s localized- versions guidance: for each page, include a full set of <link> elements in the <head> — one per variant including itself — and keep that set identical across every version, plus an x-default fallback for unmatched languages. Google documents that you can declare hreflang either in <head> <link> elements or via an XML sitemap — which is exactly the two SFCC routes.

Bing footnote: Bing has historically not supported hreflang the way Google does, reading the HTML content-language signal instead — so an SFCC site that implements hreflang only via the sitemap checkbox may not be giving Bing the language signal it wants. (Confirm current Bing behavior before treating this as a hard rule; Bing’s stated support has been reported inconsistently.)

The deeper the multi-site architectureSite architecture is how a website's pages are organized, categorized, and interlinked. It controls how crawlers discover pages, how link equity flows, and how clearly search engines understand each page's topical context. Silo structure, hub and spoke, and topic clusters are the three common models., the more this compounds — remember each site carries its own sitemap job and its own robots.txt, so a locale added as a new site is a full new SEO surface, not just a new language file. (International mechanics live in the hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. cluster.)

Faceted navigation / refinement URLs

SFCC does not produce SEO-friendly filter/refinement URLs out of the box — clean URLs and proper indexing for faceted navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals. require custom development. There’s no native canonical/noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. behavior for refinement combinations, so you have to build the decision framework yourself. Here’s the working triage I’d adapt to SFCC’s refinement mechanics — the same pattern that works on BigCommerce and any other platform, since the underlying problem (a combinatorial explosion of crawlable filter URLs) is platform-agnostic:

Page typeCanonicalRobots directive
Main category (PLP)Selfindex
High-demand refinement (real search value)Selfindex
Navigation-only refinementMain categorynoindex,follow
Sort-order onlyMain categorynoindex,follow
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. (page 2+)Self (its own URL)index
Variation product PDPMaster productcanonical to master

Two principles that don’t change on SFCC:

  • robots.txt blocks crawling, not indexing. A URL you disallow can still be indexed if something links to it — and Google can’t read your canonical or noindex because it never fetched the page. Pair parameter rules with on-page canonical + noindex.
  • Don’t noindex your paginated pages. Google’s ecommerce guidance is to give each paginated page its own canonical URL, not to fold page 2+ into page 1. noindex belongs on filter/sort variations, not on pagination.

(The platform-agnostic deep dive is the faceted navigationEcommerce SEO is the practice of optimizing an online store so its product and category pages rank in organic search and attract purchase-intent visitors. It uses the same Google algorithm as any other site, but compounds the usual SEO work with commerce-specific challenges like faceted navigation, product variants, and platform-imposed URLs. treatment in the Ecommerce SEOEcommerce SEO is the practice of optimizing an online store so its product and category pages rank in organic search and attract purchase-intent visitors. It uses the same Google algorithm as any other site, but compounds the usual SEO work with commerce-specific challenges like faceted navigation, product variants, and platform-imposed URLs. cluster.)

Headless SEO with PWA Kit (and its successor, Storefront Next)

If your storefront is headless, it runs on PWA Kit — Salesforce’s established React framework (built on SCAPI, deployed to Managed Runtime) — or, as of the 2026 B2C Commerce release cycle, Salesforce’s newer Storefront Next framework. The SEO story here is almost entirely a 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. story, and Salesforce’s own docs frame it that way.

Scope check before you apply the mechanics below. This section — the ?__server_only test, the app/ssr.js file path, the specific SSR/hydration wiring — is written for classic PWA Kit / Composable Storefront, verified directly against Salesforce’s PWA Kit developer docs. Storefront Next is a different build: React 19 with React Router 7 file-based routing (vs. PWA Kit’s React Router 5) and a fetch-then-render loader model, also running on Managed Runtime with its own streaming SSR-then-hydration flow. Salesforce documents it as distinct enough to ship a dedicated “Migrate from PWA Kit to Storefront Next” guide. If your store is on Storefront Next, don’t assume ?__server_only or the exact file paths below carry over unchanged — confirm the equivalent server-rendering verification step in Storefront Next’s own docs before treating this section as gospel for that architecture. The underlying SEO principle is the same either way: crawler-critical content (title, meta, canonical, primary copy, price/availability, JSON-LD) has to be present in the server-rendered or streamed HTML, not deferred to client-only hydration.

How rendering works. For the first page load, PWA Kit uses server-side rendering: “For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.” SSR runs through an Express app (app/ssr.js), and “Managed Runtime’s CDN cache can store a previously rendered version of a page and serve it to the user in an instant.” So far, so good for crawlers — the first load is real HTML.

The hydration boundary is the SEO risk point. After that first load, “rendering duties are transferred from the server side to the client side through a process called hydration,” at which point “your React app starts running in the user’s browser.” Your code has to be isomorphic (safe on both sides) — window.location is client-only, req/res are server-only. And critically, Salesforce says some content is deliberately client-only: “Some content, such as personalized or frequently changing content, must only be rendered on the client side to get the best possible performance.” That’s the exact tension for SEO: anything crawler-critical (title, meta, canonical, primary content, price/availability, JSON-LD) must not be in that client-only bucket, or crawlers may never see it.

How to verify it — the method Salesforce itself documents. The PWA Kit best- practices checklist tells you to test your entry pages (home, PLP, PDP) by appending ?__server_only, which lets you “confirm that your server-rendered pages have enough data for crawlers and that the layout shift between server and client is small (ideally non-existent). This can help to improve your SEO ranking.” This is the single most useful SFCC-headless SEO check, and it doesn’t require being a developer — load the URL with ?__server_only, and confirm your title, meta, canonical, main copy, and product schema are all present.

Keep URL logic in sync via SCAPI. The getUrlMapping endpoint lets a headless storefront “support localized, user-friendly URLs based on URL rules and URL redirects set up in Business Manager” — it resolves product, category (including category refinements), and content-asset URLs, and falls back to the site’s default locale if none is passed. Salesforce recommends long TTLs for it (the default is 12 hours). The payoff: you don’t maintain a parallel URL system for the headless frontend — the same URL Rules and Redirects you configured in Business Manager drive it.

The gap to bridge. Salesforce’s own PWA Kit docs treat “SEO” almost entirely as an SSR/crawlability problem — they say little about meta tags, canonical, hreflang, or schema as PWA Kit concerns (sitemaps get their own separate doc). That on-page tag work falls to the implementation team’s head-management layer (React Helmet or equivalent). If nobody owns it, a technically-crawlable PWA Kit store can still ship with missing titles, canonicals, and schema. (The general headless mechanics are in JavaScript SEO and the headless CMS SEOA headless CMS decouples content storage and editing (the backend) from how that content is rendered and delivered (the frontend), serving content over an API instead of a built-in templated 'head'. Its SEO outcomes come almost entirely from how the separate frontend renders pages. article.)

SFCC vs. the other platforms — the honest version

Compared with Shopify, BigCommerce, Magento, WooCommerce, and PrestaShop, SFCC sits at the enterprise end: it has the deepest native SEO configurability of the hosted platforms (per-site editable robots.txt, URL Rules + Aliases, canonical-by-design variants, rule-based meta tags), but it demands the most platform literacy to use. Where Shopify forces URL prefixes and hides robots.txt behind a template, and BigCommerce hands you preset URL structures and native JSON-LD, SFCC gives you the raw levers and expects you to know Business Manager. It isn’t a platform where “good SEO out of the box” is true — it’s a platform where “excellent SEO is possible if you configure it deliberately” is true. Judge it on that.

Add an expert note

Pin an expert quote

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