Salesforce Commerce Cloud SEO

TL;DR — Salesforce Commerce Cloud (you’ll also see it called B2C Commerce, SFCC, or the old name Demandware) is an enterprise hosted store platform. It comes with a lot of solid SEO tools built in — you can edit your robots.txt, it builds your sitemap automatically, it can write your page titles from a template, and it handles product variations (colors, sizes) in a search-friendly way. The catch is that these tools still require site-specific configuration and rendered-output testing by someone who knows the platform.

What “Salesforce Commerce Cloud SEO” means

Salesforce Commerce Cloud is a hosted (SaaS) ecommerce platform aimed at big brands and retailers. Salesforce hosts it, so you don’t install it on your own server the way you would WordPress and WooCommerce. Its official name is B2C Commerce, its old name was Demandware, and most people in the industry just say SFCC. It plays in the same space as Shopify and BigCommerce, but a tier up in size, price, and complexity.

Nearly everything you configure — SEO included — happens in an admin console called Business Manager. So “Salesforce Commerce Cloud SEO” is really “knowing which screen in Business Manager controls each SEO lever, and setting it correctly.”

What SFCC gives you built in

• An editable robots.txt. You can write your own robots.txt per site right in Business Manager — unlike Shopify, which doesn’t let you do this natively.
• Automatic sitemaps. SFCC generates your XML sitemap for you on a schedule you set. You don’t build the file by hand.
• Template-based page titles and descriptions. With something called Meta Tag Rules, you can write one formula (like “Category name | Brand”) and have it fill in titles across your whole catalog.
• Search-friendly product variations. Most products come in colors and sizes. SFCC treats them as one “master” product with “variations,” and the individual color/size pages are meant to point back to the master so Google doesn’t see them as duplicates.

What you still have to do yourself

• Multi-language / multi-country tags (hreflang). SFCC does not add these automatically. You either switch on a checkbox in the sitemap settings or have a developer add the tags.
• Filter pages (faceted navigation). When shoppers filter by color, size, or price, SFCC doesn’t produce clean, search-friendly URLs on its own — that needs custom development.
• Rich results / schema. The behind-the-scenes “structured data” that gets you star ratings and rich product results isn’t a switch you flip — a developer builds it into the store’s templates.
• Headless (PWA Kit or Storefront Next) crawlability. If your store uses one of Salesforce’s “headless” frontends — the established PWA Kit or the newer Storefront Next — you have to check that Google can actually see your content — see the Advanced tab.

The thing most people get wrong

There’s a common belief that “you can’t do SEO on Salesforce Commerce Cloud.” That’s not true. The platform has strong tools; what it demands is someone who knows the platform. Generic SEO advice (“just add hreflang tags,” “just clean up your filter URLs”) is correct in spirit but often can’t be done the obvious way in SFCC — it has its own screens and its own rules. The limitation isn’t the platform. It’s unfamiliarity with it.

Want the practitioner version — URL Rules vs. Aliases, the master/variation canonical strategy, hreflang architecture, and how to check whether your headless store is crawlable? Switch to the Advanced tab.

TL;DR — SFCC (B2C Commerce, formerly Demandware) ships strong native SEO building blocks: a per-site robots.txt you edit in Business Manager, XML sitemaps 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: hreflang (no dedicated B2C feature — sitemap “Include Alternate URLs” or custom <link> tags), faceted/refinement URLs (custom dev), structured data (a template 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). 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.

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 URL tags, URL Redirects, Sitemaps, 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 rendering 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 sitemaps (with optional hreflang and last-modified 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 parameters, 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 ccTLD-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 crawlers.
• 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 structures 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 tags and noindex to control what’s served in results; robots.txt controls crawling, not indexing, 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 crawling and canonicalization.)

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.

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 canonicalization 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 links 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 SEO; the canonical mechanics are in canonicalization.)

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 Tags), 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 tags dynamically — H1 templating requires custom development.

Redirects

SFCC has some native, automatic redirect 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 schema” toggle in Business Manager comparable to Meta Tag Rules or canonical handling. Unlike BigCommerce (whose Cornerstone theme ships JSON-LD 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 rendering 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 hydration. 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 architecture, 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 hreflang 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 navigation require custom development. There’s no native canonical/noindex 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:

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 navigation treatment in the Ecommerce SEO 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 crawlability 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 SEO 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.

AI summary

A condensed take on the Advanced version:

• Salesforce Commerce Cloud = enterprise hosted SaaS ecommerce, officially B2C Commerce, formerly Demandware, commonly SFCC. Nearly all SEO config lives in Business Manager (Merchant Tools → site → SEO).
• Four storefront generations, not one platform: legacy SiteGenesis, current SFRA, headless PWA Kit (Composable Storefront), and Salesforce’s newer Storefront Next framework (GA 2026 release cycle) — admin paths and rendering mechanics differ across them, so name the architecture before applying a fix.
• Native building blocks: per-site editable robots.txt (up to 50k chars), auto-generated XML sitemaps as a scheduled job, URL Rules + Hostname Aliases for locale-aware clean URLs, canonical-by-design master/variation products, rule- based Meta Tag Rules, automatic 301s on in-BM URL changes, and PWA Kit SSR.
• The architecture fork: one site with many locales vs. many sites — each site is a full separate SEO config surface (sitemap job, robots.txt, meta rules, URL rules).
• Canonical = the differentiator: variation product URLs canonicalize to the master, which maps almost 1:1 onto Google’s ProductGroup/hasVariant/isVariantOf schema. Keep canonical, sitemap, hreflang, and internal links all naming the same master URL.
• You build by hand: hreflang (no dedicated B2C feature — B2B’s “Alternate Language Links” is a different Cloud; use sitemap “Include Alternate URLs” or custom <link> tags), faceted/refinement URLs (custom dev), structured data (a template job, not a toggle), multi-locale robots.txt (domain-scoped), and H1 templating.
• Sitemaps: configure per instance type (can’t replicate Staging→Production); changefreq/priority are ignored by Google; keep lastmod accurate.
• Redirects: URL Redirects take precedence over URL Rules; on an SFRA relaunch the redirect strategy is ~60–70% of launch SEO effort.
• PWA Kit (and Storefront Next): SSR is necessary but not sufficient — content marked client-only won’t be crawled; test entry pages with ?__server_only on PWA Kit (confirm the equivalent on Storefront Next, a different React Router 7 framework); keep URL logic in sync via the SCAPI getUrlMapping endpoint.
• The myth to kill: “you can’t do SEO on SFCC” is false — the platform is strong; the limitation is unfamiliarity with it.

Official documentation

Primary-source docs from Salesforce and Google.

Salesforce — B2C Commerce (help & Business Manager)

• SEO & Discoverability for B2C Commerce — the SEO settings hub (canonical, redirects, sitemaps, robots, meta tags, URL syntax).
• SEO Best Practices for B2C Commerce.
• Configure SEO URLs for B2C Commerce — URL Rules mechanics.
• Create Canonical URL Tags for B2C Commerce — the variation → master canonical recommendation.
• Product Types and Variations in B2C Commerce — the master/variation data model.
• Sitemaps in B2C Commerce — the scheduled sitemap job.
• Generate a Robots.txt File with Business Manager.
• Hostname Aliases for B2C Commerce.

Salesforce — Developer docs (PWA Kit / SCAPI, verified directly)

• PWA Kit Rendering (SSR & hydration) — SSR-for-first-load, hydration boundary, isomorphic code.
• PWA Kit / Composable Storefront Best Practices Checklist — the ?__server_only crawlability test and the URL/redirect migration plan.
• Improve SEO with a Sitemap (Composable Storefront) — the headless sitemap mechanism and SCAPI upload endpoint.
• URL Mapping / getUrlMapping (SCAPI) — headless URL resolution and the “URL redirects take precedence” rule.
• Storefront Next: Get Started and Migrate from PWA Kit to Storefront Next — Salesforce’s newer headless React framework (React 19/React Router 7), GA in the 2026 release cycle; verify SEO-critical mechanics here before assuming PWA Kit’s steps carry over unchanged.

Salesforce — Trailhead (static learning modules)

• Explore SEO URLs (best practices).
• Configure SEO URLs — lowercase, whitespace separators, category/product patterns.
• Configure Hostname Aliases.

Google

• Consolidate duplicate URLs (canonicalization) — signal strength, stacking, and the “don’t contradict yourself” rule.
• Product variant structured data (ProductGroup) — variesBy/hasVariant/isVariantOf, nested vs. separate patterns.
• Localized versions of your pages (hreflang) — <link> vs. sitemap, reciprocity, x-default.
• Intro to structured data — JSON-LD as the recommended format.

Quotes from the source

On-the-record statements from Salesforce’s own developer documentation and from Google, deep-linked to the quoted passage. Everything from Salesforce’s JS-rendered Help/Business Manager screens (URL Rules mechanics, the canonical recommendation, robots.txt behavior, Meta Tag Rules) is paraphrased in the Advanced tab rather than quoted, because those pages resist automated verification — confirm exact wording in the live Business Manager or rendered docs before treating any of it as verbatim.

Salesforce — PWA Kit Rendering (developer docs)

• “For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.” Jump to quote
• “Managed Runtime’s CDN cache can store a previously rendered version of a page and serve it to the user in an instant.” Jump to quote
• “After the first page load, rendering duties are transferred from the server side to the client side through a process called hydration.” Jump to quote
• “Some content, such as personalized or frequently changing content, must only be rendered on the client side to get the best possible performance.” Jump to quote

Salesforce — PWA Kit Best Practices Checklist (developer docs)

• On testing crawlability with ?__server_only: “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.” Jump to quote

Salesforce — Improve SEO with a Sitemap (developer docs)

• “Sitemaps provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.” Jump to quote

Salesforce — URL Mapping / SCAPI (developer docs)

• “If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.” Jump to quote

Google — canonicalization

• “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”).” Jump to quote
• “When linking within your site, link to the canonical URL rather than a duplicate URL.” Jump to quote

Google — product variant structured data

• “use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID to group such variants together.” Jump to quote

Salesforce Commerce Cloud (SFCC) SEO checklist

Prioritized, and organized by the Business Manager screen that controls each item. Top items move the needle most.

High impact

• Variation → master canonical confirmed — every variation-product PDP canonicalizes to its master (base) product, and your sitemap + internal links name the same master URL (don’t contradict yourself across techniques).
• Faceted / refinement URLs handled — refinement combinations get canonical + noindex per the parameter triage; SFCC won’t do this natively, so it’s a custom-development task.
• PWA Kit crawlability verified (headless only) — load home, PLP, and PDP with ?__server_only and confirm title, meta, canonical, primary content, price, and JSON-LD are all in the SSR output.
• Migration redirect map (SFRA relaunch / headless migration) — complete, pointing at object IDs not hard-coded paths; this is 60–70% of launch SEO effort.

Business Manager setup (Merchant Tools → site → SEO)

• URL Rules / Aliases — lowercase forced, hyphen (minus) whitespace separator, category vs. category-path chosen for your depth, products assigned to the domain not a category path; alias file declares version 1.
• Default-Start / Home-Show pipelines mapped so you don’t generate duplicate www/non-www homepages.
• Sitemap job scheduled for low-traffic times, after daily replication; configured per instance type (Staging/Production/Development separately); lastmod accurate; changefreq/priority ignored so not worth tuning.
• Robots.txt minimal and deliberate; know whether you’re using the Business Manager site preference or a cartridge static file; invalidate the static cache after a cartridge-level change; account for it being domain-scoped, not subfolder-scoped.
• Meta Tag Rules set with the hybrid override syntax (${IF Category.pageTitle THEN … ELSE …}); connectives localized per language/country; remember H1 templating needs custom dev.
• Redirects — URL Redirects / Static Mappings / Dynamic Mappings chosen per case; remember URL Redirects beat URL Rules on conflict.

Structured data (developer/template layer)

• Product / ProductGroup / breadcrumb JSON-LD built into templates (no native BM toggle); present in server-rendered HTML, not injected only on hydration.

International (multi-site / multi-locale only)

• hreflang implemented via sitemap “Include Alternate URLs” or custom <link> tags — reciprocal, full set per page including itself, with x-default.
• Don’t confuse B2B Commerce’s “Alternate Language Links” feature with B2C (B2C has no dedicated hreflang screen).
• Consider a content-language signal for Bing, which historically doesn’t use hreflang the way Google does.
• Each site’s sitemap job, robots.txt, and Meta Tag Rules kept in sync.

The mental models

1. Native building block vs. build-it-yourself. Every SFCC SEO task is either a Business-Manager-configurable building block (robots, sitemaps, URL Rules, canonical variants, Meta Tag Rules, auto-301s) or something you have to build (hreflang, faceted URLs, schema, H1 templating, headless on-page tags). Knowing which bucket a task is in tells you whether to configure a screen or brief a developer.

2. Sites vs. locales = your configuration-surface count. One site with many locales, or many sites? Each site is a complete separate SEO config surface — its own sitemap job, robots.txt, Meta Tag Rules, URL Rules. Decide this first, because it multiplies every other section.

3. Master/variation = ProductGroup. SFCC’s master product is Google’s ProductGroup; variation products are its hasVariant/isVariantOf members. Canonicalize variations to the master, mark them up as a ProductGroup, and keep canonical + sitemap + hreflang + internal links all naming the same master URL. One model, two systems, one preferred URL.

4. robots.txt controls crawling; canonical/noindex control indexing. Keep robots.txt minimal. Over-relying on it to control what’s indexed is the anti-pattern — it only blocks crawling, and it’s domain-scoped so it can’t cleanly target one locale’s subfolder. Use canonical and noindex for indexing decisions.

5. In PWA Kit, SSR is necessary but not sufficient. Headless crawlability isn’t “does it do SSR?” — it’s “is the SEO-critical content in the SSR output, or did it get marked client-only?” The ?__server_only test is the whole game: if a title, canonical, price, or JSON-LD isn’t there, a crawler won’t see it either.

Salesforce Commerce Cloud SEO cheat sheet

Where things live in Business Manager (Merchant Tools → site → SEO → …)

URL Rules quick facts

• Force Lower Case; use hyphen (minus) for whitespace, not %20 or underscore.
• category for deep trees; category-path when category names collide across parents.
• Product ID + .html auto-appended (no removal without custom dev).
• Assign products to the domain, not a category path.
• Avoid sc.html, page-type indicators, and the word demandware in URLs.

Meta Tag Rules syntax

• Basic: ${Category.Name} | Example Brand
• Hybrid override: ${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name}
• H1 templating: not supported by rules — custom dev.

Redirects

• 301 permanent (308 via custom dev); 307 temporary.
• URL Redirects beat URL Rules on conflict.
• Point at object IDs, not hard-coded paths.

PWA Kit (headless)

• Test entry pages with ?__server_only for crawler-visible content.
• Keep SEO-critical content out of the client-only bucket.
• getUrlMapping (SCAPI) reuses BM URL Rules/Redirects; long TTL (default 12h).

Don’ts

• Don’t leave changefreq/priority tuning on the to-do list (Google ignores them).
• Don’t confuse B2B “Alternate Language Links” with B2C hreflang (B2C has no such screen).
• Don’t rely on robots.txt to deindex, or to target one locale subfolder.
• Don’t assume PWA Kit is SEO-safe just because it does SSR.
• Don’t skip mapping Default-Start / Home-Show (duplicate homepages).

Salesforce Commerce Cloud SEO mistakes to avoid

Tuning sitemap fields Google ignores

Why it’s wrong: Spending time on changefreq and priority does not improve Google crawling because Google ignores both fields. Do this instead: keep lastmod accurate, schedule generation after replication, and spend the saved time checking which canonical URLs actually appear in the sitemap.

Treating the B2B hreflang screen as a B2C feature

Why it’s wrong: B2C Commerce does not have B2B Commerce’s dedicated Alternate Language Links feature. Following the wrong product’s instructions leaves the B2C store without working hreflang. Do this instead: use the B2C sitemap’s Include Alternate URLs option or implement reciprocal <link rel="alternate"> tags.

Using robots.txt as a deindexing tool

Why it’s wrong: A disallow controls crawling, not indexing, and it prevents a crawler from seeing a page-level canonical or noindex. It also cannot target one locale when several locales share a domain. Do this instead: keep robots.txt minimal and use canonical or noindex for index-state decisions.

Assuming PWA Kit is crawlable because it uses SSR

Why it’s wrong: PWA Kit can still leave price, copy, metadata, or JSON-LD in the client-only layer. Do this instead: append ?__server_only to representative home, PLP, and PDP URLs and confirm every crawler-critical element is present.

Leaving Default-Start and Home-Show unmapped

Why it’s wrong: The pipelines can expose duplicate homepages across hostname variants. Do this instead: map both pipelines explicitly and crawl the hostname variants to confirm they consolidate on one homepage.

Prove a PWA Kit rendering change worked

Compare the server-only response after deployment

Test to run: Open the changed home, PLP, and PDP URLs with ?__server_only, then inspect the returned source for the title, meta description, canonical, primary copy, price or availability, and JSON-LD.

Expected result: Every SEO-critical element affected by the release is present in the server response, without waiting for hydration.

Failure interpretation: A missing element is still fetched or rendered only on the client, or its server data dependency failed.

Monitoring window: Immediate after deployment; repeat once the Managed Runtime cache has been refreshed for the release.

Rollback trigger: Roll back the change if a canonical, primary content, product availability, or structured-data block that existed before the release disappears from the server-only response.

Confirm Google receives the same critical content

Test to run: Use Google Search Console URL Inspection on the same representative URLs and inspect the tested HTML.

Expected result: The inspected HTML contains the same critical content and tags as the ?__server_only response.

Failure interpretation: Google is receiving a cached, blocked, or otherwise different response from the one tested directly.

Monitoring window: Run a live test immediately; allow normal recrawling time before judging the indexed result.

Rollback trigger: Roll back if the live test repeatedly loses indexable content or canonical signals that were present before the release.

Tools for Salesforce Commerce Cloud SEO

• Business Manager — the platform’s own admin; every SEO lever (URL Rules, Aliases, Sitemaps, Robots, Meta Tag Rules, Redirects, canonical) lives under Merchant Tools → site → SEO.
• The ?__server_only URL parameter — Salesforce’s own headless crawlability test; append it to any PWA Kit page to see exactly what the server rendered before hydration. The most important SFCC-headless SEO tool, and it’s free and built in.
• Google Search Console — sitemap submission, URL Inspection (see the rendered HTML for a PWA Kit page), International Targeting for hreflang, Crawl Stats. Your ground truth for what Google actually does.
• Bing Webmaster Tools — second sitemap submission, crawl control, and the place to check content-language handling since Bing doesn’t use hreflang like Google.
• Screaming Frog / Ahrefs Site Audit — crawl your store to catch the refinement-URL explosion, variation PDPs not canonicalizing to the master, redirect chains, and duplicate homepages from unmapped pipelines. This is how you find the SFCC-specific gaps.
• URL Inspection (GSC) — for a PWA Kit page, confirm the rendered HTML actually contains title, canonical, price, and JSON-LD (the same thing ?__server_only checks, from Google’s side).
• Rich Results Test / Schema Markup Validator — verify your ProductGroup/variant JSON-LD, since schema on SFCC is developer-built with no native toggle to trust.

Resources worth your time

On-site, related

• Faceted navigation — the platform-agnostic deep dive on SFCC’s #1 build-it-yourself problem; SFCC’s refinement URLs need custom development.
• Canonicalization — the mechanics behind the variation → master rule.
• Product variant SEO — the ProductGroup/hasVariant/isVariantOf pattern that maps onto SFCC’s master/variation model.
• hreflang — international mechanics for SFCC’s non-automatic hreflang.
• Headless CMS SEO — directly relevant to the PWA Kit SSR/hydration section.

Salesforce official

• SEO & Discoverability for B2C Commerce — the SEO hub in Business Manager.
• PWA Kit Rendering and the PWA Kit Best Practices Checklist — SSR/hydration and the ?__server_only test.
• Improve SEO with a Sitemap and URL Mapping / getUrlMapping (SCAPI).

Google official

• Product variant structured data and Consolidate duplicate URLs.
• Localized versions of your pages (hreflang).

My related writing

• A Website Migration Takes More Than A Checklist To Be Successful — directly applicable to SFRA relaunches and PWA Kit migrations.
• 11 Types Of Redirects & Their SEO Impact and 301 vs. 302 Redirects for SEO — the 301/307/308 guidance above.
• JavaScript SEO Issues & Best Practices — the rendering side of the PWA Kit section.

From around the industry (SFCC-specific practitioner coverage; verify against the live docs)

• Resignal — SFCC SEO Masterclass Part 1: Hostnames & URL Structure — the deepest third-party URL-config write-up (URL Rules vs. Aliases, Default-Start/Home-Show pitfalls, the version-1 alias gotcha).
• Resignal — SFCC SEO Masterclass Part 2: Crawling & Redirect Tools — sitemap auto-generation, changefreq/priority deprecation, and the three redirect tools.
• Resignal — SFCC SEO Masterclass Part 3: On-Page SEO — Meta Tag Rules syntax, the hybrid override pattern, and the H1 limitation.
• NOVOS — The Ultimate Guide to Salesforce eCommerce SEO — assign-to-domain URL advice and redirect-to-object-ID best practice.
• Eskimoz — Is SEO on Salesforce Commerce Cloud even possible? — the “the platform isn’t the limitation, unfamiliarity is” framing.
• Acxiom — SFCC SEO: Important Considerations Before Your SFRA Launch — the 60–70%-of-launch-effort redirect-strategy framing.

Test yourself: Salesforce Commerce Cloud SEO

Five quick questions on how SEO works on Salesforce Commerce Cloud. Pick an answer for each, then check.

Salesforce Commerce Cloud SEO

Salesforce 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.

Related: Faceted Navigation, Canonicalization, Hreflang, Product Variant SEO

Salesforce Commerce Cloud SEO

Salesforce Commerce Cloud (officially B2C Commerce, formerly Demandware, and commonly shortened to SFCC) is an enterprise SaaS ecommerce platform. Like Shopify and BigCommerce it’s hosted for you, but it sits a tier up in complexity and price, and almost everything SEO-related is configured through its admin console, Business Manager, under Merchant Tools → site → SEO.

What SFCC gets right natively is a genuinely strong set of building blocks: you can edit robots.txt per site directly in Business Manager, XML sitemaps are auto-generated by a scheduled job, meta titles and descriptions can be templated across a whole catalog with Meta Tag Rules, and the product data model is canonical-by-design — a single master product with multiple variation products (color, size), where variation URLs are meant to canonicalize to the master. That last point maps almost one-to-one onto Google’s own ProductGroup/hasVariant/isVariantOf structured-data guidance for variants.

What SFCC does not do for you: nothing works well without setup. Hreflang has no dedicated admin screen in B2C Commerce (unlike the separate B2B Commerce “Alternate Language Links” feature) and runs through the sitemap’s “Include Alternate URLs” checkbox or custom <link> tags; faceted-navigation and refinement URLs need custom development to be SEO-friendly; structured data is a template/developer responsibility rather than a Business Manager toggle; and headless storefronts built on PWA Kit server-side render the first load then hydrate client-side, so crawlability depends on whether the SSR output actually contains the SEO-critical content. SFCC gives SEOs the levers — but you have to know Business Manager and general technical SEO to pull them correctly.

Related: Faceted Navigation, Canonicalization, Hreflang, Product Variant SEO

Changelog