Configure SEO-Friendly Storefront URLs

Configure SEO-friendly URLs for product, category, and standalone content pages in Storefront Next. These URLs use the URL rules that you define in Business Manager, so shoppers and search engines see consistent, descriptive paths such as /p/summer-dress/12345 and /c/outdoor-furniture/567. Storefront Next resolves well-formed product and category URLs directly from the path. SEO-friendly URLs help avoid a URL-mapping lookup for those requests and help keep routing fast and predictable.

Before you enable SEO-friendly URLs, complete these prerequisites:

• Define the URL grammar for each site in Business Manager. For more information, see Configure SEO URLs for B2C Commerce in Salesforce Help.
• Decide the product prefix, category prefix, and category URL mode for every active site.
• Identify indexed legacy URLs and prepare redirects to their new canonical URLs.
• Verify that slug-path category URLs have Shopper Products version 1.13, Shopper Search version 1.15, and authoritative category slugs on every category-link surface.

In config.server.ts, configure url.seoRoutes for every active Commerce site. Prefixes are path segments without leading or trailing slashes.

This example produces product URLs beginning with /p/, category URLs beginning with /c/, and optional standalone content URLs beginning with /cms/. Any configured MRT base path and the site and locale prefix remain part of the full public URL. Storefront Next adds the MRT base path automatically. For more information, see Configure Base Paths.

Add an entry for every active site. Storefront Next validates the configuration during the build and rejects invalid, shared, reserved, or colliding prefixes. Changes to seoRoutes require a rebuild and redeployment. They can’t be supplied as a runtime environment-variable override.

Set content.prefix only when Storefront Next owns standalone content for that site. It supports separate deterministic forms for content assets (/{content-prefix}/content/{slug}/{content-id}) and Page Designer pages (/{content-prefix}/page/{slug}/{page-id}), while embedded content regions and slots continue to use the URL of their host page.

If you use Shopper SEO URL Mapping fallback for content, set seoFallback.sites.<siteId>.contentOwned to true. This setting authorizes fallback mappings for owned content. It doesn’t affect the direct content URLs described above.

Choose one category URL mode per site.

Product URLs always end with the product ID. A descriptive product slug is optional. Include one when it’s available. The product ID keeps the URL stable if a product name or category placement changes.

These examples omit any configured MRT base path and the site and locale prefix for clarity. Use them to understand how Storefront Next serves common URL patterns, redirects stale paths, and preserves compatibility.

Without seoRoutes, Storefront Next supports the built-in ID routes, such as /p/mens-cotton-hoodie and /c/women. These routes keep existing storefronts compatible with B2C Commerce versions that don’t provide the slug data required by slug-path category URLs.

When you enable seoRoutes, configure product, category, and optional content prefixes for every active site. The configuration determines the URL grammar that Storefront Next serves. Changing a prefix requires an update to config.server.ts, a rebuild, and a redeployment.

• /p/men/knitwear/mens-cotton-hoodie — The final segment is the authoritative product ID. Earlier segments are a readable product-slug hierarchy. The route resolves without a URL Mapping call.
• /p/mens-cotton-hoodie?pid=mens-cotton-hoodie-xs — The path identifies the product and pid selects a variation. Because it changes the displayed variation, pid is retained in the canonical URL.
• /p/outdated/mens-cotton-hoodie — If the final product ID resolves but the earlier slug hierarchy is stale, Storefront Next returns one 301 redirect to the configured canonical product URL.

• /c/women/dresses/25502 in id-suffix mode — The final segment is the authoritative category ID, so the route resolves deterministically without an extra lookup.
• /c/women/dresses in slug-path mode — The complete path is the category slug. Storefront Next uses the slug in the existing category and product-search requests without a URL Mapping call or an additional product-search waterfall.
• /c/outdated/25502 in id-suffix mode — A stale category slug hierarchy converges with one 301 redirect to the configured canonical category URL because the final category ID is authoritative.

• /p/men/knitwear/mens-cotton-hoodie.html — Storefront Next accepts a Commerce-generated terminal .html suffix and redirects it to the configured suffix-free canonical URL.
• /cms/content/campaigns/about and /cms/page/campaigns/spring-sale — When a content prefix is configured, standalone content and Page Designer pages use deterministic routes.
• /seo-test/product — An otherwise unmatched eligible GET or HEAD request can use Shopper SEO URL Mapping fallback. Configure the fallback policy and the sfcc.shopper-seo SLAS scope; the fallback makes at most one URL Mapping call.
• /product/mens-cotton-hoodie or /category/women — These legacy forms aren’t automatically native routes after you enable seoRoutes. Use a Business Manager mapping, an edge redirect, or a hybrid handoff to support them.

• The canonical URL, og:url, and JSON-LD URL use the same preferred URL. hreflang provides the equivalent URL for each supported locale, and crawlers receive fully rendered HTML.
• Normal product, category, and configured content routes make no URL Mapping call. Only an eligible compatibility fallback can make one mapping request.

Changing a prefix or category mode changes URLs that might already be indexed or linked from campaigns, affiliates, and other sites. Release the URL configuration and redirects together.

1. Update the matching URL rules in Business Manager and config.server.ts.
2. Add a single permanent (301) redirect from every legacy URL pattern to the new canonical URL. Configure redirects in Business Manager or at the CDN for paths that Storefront Next doesn’t own.
3. Redirect .html legacy URLs to the suffix-free canonical URL when applicable.
4. Verify that a redirect reaches its final destination in one hop and that the destination page’s canonical URL matches it.
5. Update sitemaps, campaign links, and other controlled inbound links to use the new URL format.
6. Rebuild, deploy, and verify a product URL, a category URL, and any configured content URL for each site.

Avoid redirect chains and loops. An old URL should redirect directly to the URL that Storefront Next now generates. That URL must not redirect back to an older format.

Storefront Next includes these crawler protections by default:

• Complete HTML for crawlers: The storefront streams the page shell to shoppers for a responsive experience, while recognized crawlers receive the fully rendered HTML response.
• Crawlable category pagination: Shoppers can use Load More on category pages. Crawlers can reach each result window through ?page=N URLs with rel="prev" and rel="next" links. The canonical URL remains the base category URL, which consolidates ranking signals.
• Consistent canonical URLs: Canonical, Open Graph, and structured-data URLs use the same preferred public URL. Tracking and other non-content query parameters aren’t included in the canonical URL.
• Efficient deterministic routing: Storefront Next resolves product, category, and configured standalone-content URLs from the URL pattern rather than with a URL-mapping lookup.

To keep this behavior effective as your storefront evolves:

• Keep Business Manager URL rules and seoRoutes synchronized, then rebuild and redeploy after each change.
• Use the configured URL builders for new product, category, and content links instead of hard-coded URL paths.
• Keep the redirect target, canonical URL, sitemap entry, and internal links aligned on one preferred URL.
• Test representative URLs as both a shopper and a crawler after a release. Confirm that a crawler receives page content and can follow paginated category results.
• Monitor crawl errors, redirect reports, and indexed canonical URLs in your search-engine tools after a rollout. Correct unexpected 404 responses, redirect chains, or canonical mismatches promptly.

For canonical URLs, hreflang, metadata, and indexing controls, see SEO and Metadata.

Validate the release in a nonproduction environment for every active site before you deploy it to production.

• Confirm that the build completes with an entry in seoRoutes for every active site.
• Test a product URL, category URL, and, if configured, a standalone-content URL. Each must resolve to the intended page without an extra URL-mapping lookup.
• Test legacy and .html URLs. Each must redirect once to the current canonical URL.

• Compare representative product and category pages with your pre-release baseline. Review page-load and server-response times for shopper and crawler requests.
• Verify that well-formed product, category, and configured content URLs use deterministic routing rather than a URL-mapping lookup.
• Confirm that category pagination remains crawlable with ?page=N URLs and working rel="prev" and rel="next" links.

• Confirm that each page’s canonical URL matches its redirect target, sitemap entry, and internal links.
• Verify that crawlers receive complete HTML for representative product and category pages.
• Review crawl errors, redirect reports, and indexed canonical URLs in your search-engine tools after release. Investigate unexpected 404 responses, redirect chains, and canonical mismatches promptly.

When you enable seoRoutes, the storefront replaces its built-in product and category URL grammar with your configured prefixes. Redirect existing indexed URLs to the new grammar so shoppers and crawlers don’t reach a 404 page.

In a hybrid storefront, configure SEO-friendly URLs only for paths that Storefront Next owns. Paths owned by the existing SFRA or SiteGenesis storefront retain their Commerce-managed URLs. For an unmatched eligible GET or HEAD request, Storefront Next can use the Shopper SEO URL Mapping fallback; a mapping miss or ineligible request remains a 404. Keep legacy-route ownership and redirect rules aligned so every URL reaches the storefront that serves it.