Salesforce Commerce Cloud (SFCC, formerly Demandware) is one of the most powerful enterprise commerce platforms on the market - and one of the most idiosyncratic from an SEO standpoint. Its URL routing, controller architecture, and templating model are unlike anything in the Shopify, BigCommerce, or Magento world. The platform has been through two major architectural eras: SiteGenesis (the legacy reference application, originally written in JavaScript controllers) and SFRA (Storefront Reference Architecture, the modern controller-and-script-API-based replacement). A SFCC merchant is on one or the other - and the SEO surface differs meaningfully between them.
This post walks through what you need to know about SFCC URL controls in both eras, plus the supporting structure (OCAPI, SCAPI, hostname aliasing, and catalog assignment) that shapes how Googlebot interacts with the storefront.
The SFCC URL anatomy in 60 seconds
A canonical SFCC URL on SiteGenesis looks like:
https://www.example.com/on/demandware.store/Sites-USA-Site/en_US/Product-Show?pid=ABC123
That URL is a literal representation of the controller-action-parameter routing. Sites-USA-Site is the site, en_US is the locale, Product-Show is the controller-action, and pid=ABC123 is the product identifier. Out of the box, this is what gets generated for every product page.
No SEO professional in 2026 wants to ship that URL.
The fix is URL Rules- SFCC's configurable URL rewriting layer. URL Rules generate clean SEO-friendly URLs (/products/abc123/product-name, or category-based slugs, or locale-prefixed slugs) by mapping incoming requests to the underlying controller actions. URL Rules are configured in Business Manager (Merchant Tools → Site Preferences → SEO → URL Rules).
The two main rule sets:
- Catalog URL Rules- for category and product URLs.
- Content URL Rules- for content asset URLs.
A correctly configured URL Rules setup produces URLs like https://www.example.com/men/shirts/dress-shirt-blue-cotton that bear no resemblance to the underlying controller structure. That is the goal.
SiteGenesis vs SFRA - what changes
SiteGenesis is the legacy reference application. It is still in production at many enterprise SFCC merchants. SFRA (Storefront Reference Architecture) is the modern replacement, released in 2017 and the default for new builds since 2019.
What changes for SEO between the two:
- Templating engine. SiteGenesis uses ISML (Internet Store Markup Language) extensively with controller-rendered views. SFRA uses ISML too, but with cleaner controller separation and a script-API layer that makes it easier to emit clean HTML.
- Performance. SFRA is generally faster - less template overhead, leaner JavaScript bundles. CWV scores on SFRA out-of-the-box are meaningfully better than SiteGenesis out-of-the-box.
- Maintainability of SEO templates. SFRA's separation of concerns makes it easier to drop in JSON-LD, canonical, and hreflang tags reliably across all pages. SiteGenesis SEO templates are often scattered across includes and require deeper code archaeology.
- API access. SFRA encourages the use of the script API and the SCAPI (Shopper API). SiteGenesis predates SCAPI.
If you are still on SiteGenesis and have the budget to migrate to SFRA, the SEO case alone often justifies it - especially when paired with a CWV-driven theme overhaul.
OCAPI vs SCAPI - the headless question
Salesforce has two API surfaces for headless storefronts:
- OCAPI (Open Commerce API) - the older REST API, still supported, still the basis for many integrations.
- SCAPI (Shopper API and Admin API, sometimes branded as the Commerce API) - the newer, GraphQL-and-REST-blended API that Salesforce is actively developing.
If you are building a headless SFCC storefront in Next.js, Remix, or another modern framework, SCAPI is the right surface to target. The same SEO principles that apply to a Hydrogen headless Shopify build or a Catalyst BigCommerce build apply to a headless SFCC build:
- SSR or streaming SSR for indexable routes.
ProductJSON-LD emitted in the SSR response.- Canonical and hreflang in the head, not hydrated client-side.
- AI crawlers do not execute JavaScript.
The cornerstone for cross-platform headless work is headless commerce SEO.
Hostname aliasing and the multi-site question
SFCC supports multi-site at the platform level. A single SFCC instance can host dozens of separate storefronts - different brands, different geographies, different languages - all from the same Business Manager. Each storefront gets its own hostname (or set of hostnames) via the hostname aliasing configuration.
The SEO implications:
- Each storefront's canonical hostname must be set correctly. The
Site URLconfiguration in Business Manager drives canonical generation. - Cross-storefront duplicate content is a real risk when the same products are listed under different brands or different country sites. Each storefront needs its own canonical URL set, and hreflang annotations between localized storefronts must be reciprocal.
- Robots policy is per-storefront. A development storefront should have
Disallow: /set.
Catalog assignment and category trees
SFCC's catalog model is structural: a master catalog holds the products, storefront catalogs (sometimes the same as the master, often different) define the category trees that customers actually navigate. The same product can appear in multiple categories across multiple storefront catalogs.
For SEO, this means:
- The primary category for a product determines its canonical URL via URL Rules.
- Products listed in multiple categories need a single, stable canonical - typically pointing to the primary category's URL.
- Category landing pages need their own ranking content, separate from product listings.
A common SiteGenesis-era mistake is to allow product URLs to render under any category they belong to, generating multiple URLs for the same product and splitting ranking authority. Set a single canonical via URL Rules, and confirm the canonical tag is emitted correctly on every product page.
Faceted nav on SFCC
SFCC's refinement (faceted) navigation is configured per category in Business Manager. The default behavior generates URLs like:
/men/shirts?prefn1=color&prefv1=Blue
Every refinement combination is a unique URL. The fix is the same as on every other platform:
- Restrict the refinement attributes to those that drive genuine search demand.
- Canonicalize filtered URLs to the unfiltered category.
- Disallow
?prefn*=*parameters in robots.txt. - For the small number of high-demand facet combinations (color-specific category pages), generate them as dedicated category landing pages via the storefront catalog.
Page Designer and content slot SEO
SFCC's Page Designer lets merchandisers compose category and content pages from reusable components without developer involvement. The SEO catch: Page Designer components must emit clean HTML with proper heading hierarchy, alt text on images, and structured data where applicable. The default components do most of this; custom components written for a brand-specific layout often do not.
Audit every Page Designer page template by viewing rendered source and confirming:
<h1>is present and unique per page.- Heading hierarchy is logical.
- Images have alt text.
- Any component that renders a product card emits
ProductJSON-LD.
Common SFCC SEO regressions
Recurring failures we see on SFCC audits:
- URL Rules misconfigured so that legacy
/on/demandware.store/...URLs are still indexable alongside the clean URLs - splitting authority. - Hreflang missing between localized storefronts on a multi-site SFCC instance.
- Faceted refinement URLs indexed because the canonical was set incorrectly on the category template.
- Page Designer components emitting H2 or H3 instead of H1 on category pages.
- Development hostnames indexed because robots policy was not set per-storefront.
- Legacy SiteGenesis sites with poor CWV that have not been addressed because no one on the team has shipped the SFRA migration.
Key takeaways
- SFCC URL Rules are the single most important SEO configuration on the platform. Get them right or the rest of the work is undermined.
- SFRA is meaningfully better than SiteGenesis for SEO. If you are still on SiteGenesis, the migration is worth it.
- SCAPI is the right API surface for new headless builds. OCAPI is supported but no longer the strategic direction.
- Multi-site instances need explicit hostname aliasing, canonical, and hreflang configuration per storefront.
- Refinement URLs are a crawl trap by default. Canonicalize and disallow.
For the SFCC-specific cornerstone, see our Salesforce Commerce Cloud SEO practice. The cross-platform headless commerce SEO overview applies if you are building a modern front end on top of SCAPI. The full platform-by-platform view lives at SEO by platform, and the broader eCommerce SEO agency services cover the strategic side. When you are ready to talk, we are here.