A Salesforce Commerce Cloud (SFCC) storefront is the website where your customers shop, check prices, and order items. It merges the shopping experience with product catalogs, prices, inventories and check-out capabilities.
An SFCC storefront may look normal to shoppers, yet it can send mixed signals to search engines. Same product on category pages, different URLs, parameters or old URLs with different canonical tags, internal links & sitemap entries. These considerations can affect:
- Crawling efficiency
- Indexation
- Discovering product
- Speed of search
You need to understand how the storefront is built and align its technical SEO signals to get the proper repair. This guide covers the major SFCC SEO problems, how to fix them and how to prevent them from recurring.
Fixing Common SFCC Technical SEO Issues
As product catalogs, URLs, and storefront setups start to grow, SFCC businesses might run into technical SEO issues. These flaws can lead to problems with how search engines crawl pages, interpret canonical signals, and finally index the products.
To actually solve it, you need to spot what’s happening first, fix it properly, and then test everything again just to confirm the change works the way you expect.
The next steps describe common SFCC technical SEO issues, explain why they matter, and show how to fix them.
1. Identify the Storefront Architecture First
SFCC supports several storefront architectures, each with its unique approach to establishing and operating an online business.
- SFRA: A Salesforce framework that supports server-based rendering to create storefront pages.
- SiteGenesis: Another Salesforce storefront architecture that also supports server-side rendering.
- PWA Kit: A framework for constructing modern shops with React, a distinct front end and back end.
Also, each architecture treats URLs, metadata, and page rendering distinctly and knowing the architecture helps you detect and fix SEO issues.
This section is a quick rundown of their SEO control points.
| Storefront | Primary SEO control points | First diagnostic and fix |
| SFRA or SiteGenesis | Business Manager URL Rules, URLUtils, ISML templates, controllers, sitemap jobs, and page cache | Compare the rendered DOM with the HTML source. Fix canonical and metadata creation, fix duplicate URL patterns, and regenerate sitemaps after fixing URL rules. Check the URL rule output. |
| PWA Kit | React routes, React Helmet, server-side rendering, managed runtime, request processor, and SCAPI data | Load the route server-side and check the title, canonical, content, status and schema in the first HTML. Fix missing metadata in rendering logic, and fix redirects and HTTP status codes. |
| Storefront Next | Business Manager URL grammar, SEO routes, SEOMeta, route loaders, sitemaps, and redirect alignment | Check route ownership, loader output, canonical normalization, and initial HTTP response. Setting up routes properly, matching canonical URLs with sitemap entries, and fixing redirect conflicts. |
| Hybrid | Legacy and composable routes divide ownership, cross-system redirection | Map each product, category, content and utility path to one storefront owner. Correct overlapping routes, harmonize canonical and redirect rules, and make sure each sitemap has the proper indexable URLs. |
Do not identify the architecture based solely on the visual design. Check response headers, route patterns, HTML, asset paths, deployment configuration, and the codebase. In a hybrid implementation, clearly assign each important path to one storefront owner. Then trace each SEO issue to the component generating it and correct the underlying cause to prevent the same problem from recurring.
2. Build an Evidence-Based Audit Baseline
Instead of crawling the entire inventory right away, begin with a representative sampling. Major categories, deep categories, paginated pages, filters, master and variation products, unavailable products, localized pages, content pages, search results, and known redirects. Where possible, include server logs and Search Console data.
For each URL, capture:
- Requested and final URL
- Redirect chain and HTTP status
- Robots and meta-robots status
- Canonical URL
- Title, description, H1, product name, price, and availability
- Internal links and sitemap membership
- Structured data and validation errors
- Hreflang and locale information
- LCP, image dimensions, render-blocking requests, and layout shifts
The goal is not simply to collect errors. Look for conflicting signals. A sitemap URL that redirects, for example, shows a disagreement between discovery and canonicalization. Similarly, a page blocked by robots.txt cannot reliably communicate a noindex directive because the crawler may not access it.
3. Fix URL Duplication and Canonical Conflicts
SFCC Catalogs can offer the same product through category pathways, direct URLs, variations, search refinements, campaign settings and older URL patterns. When these options return essentially the same content, they can lead to wasteful redundancy.
First, organize the URLs by product or category ID. Then compare the URLs that give the same content. Missing, redirected, banned, non-200 or conflicting with the final URL flaURLs orals.
Also review navigation, recommendations, and content assets for links to noncanonical URLs or adding extraneous parameters.
Use URL rules as URL structure for SFRA and SiteGenesis and produce links utilizing platform URL utilities such as URLUtils instead of hard-coding destinations. When you change a rule, be sure to evaluate the output, update redirects, regenerate sitemaps and crawl the final URLs.
Ensure Business Manager URL settings and SEO routes are consistent for Storefront Next. Canonical URLs in PWA Kit should be produced with normalized approved query parameters. Marketing parameters should be removed from canonical tags.
Use self-referencing canonical tags on indexable pages. Combine truly equivalent variations when necessary, but preserve separate variant pages indexable where they have distinct demand, content, imagery, availability and stable URLs. A canonical should supplement clean URLs, not replace them.
4. Control Faceted Navigation Without Hiding Valuable Demand
Faceted navigation can generate large numbers of URLs from filters such as color, size, price, availability, and sorting. The goal is not to block every filtered page. Instead, separate useful search destinations from combinations that add little value.
The table below shows how different URL types can be handled:
| URL class | Recommended treatment | Reason |
| Curated facet landing page | Make it indexable and self-canonical. Link to it in HTML and include it in the sitemap when appropriate. | It has durable demand, useful content, inventory, and internal prominence. |
| Useful but non-targeted filter | Consider noindex or canonicalization where appropriate. | It may help shoppers without needing its own search presence. |
| Sort, view, tracking, or session state | Keep it out of canonical URLs and internal crawl paths. | These parameters usually do not create useful search destinations. |
| Invalid or excessive combinations | Prevent generation and return 404 for invalid states. | Stopping unnecessary URLs at the source reduces crawl waste. |
Do not block a page in robots.txt and expect a noindex directive to remove it. Google needs to crawl the page to see that directive. Also avoid blanket canonicalization when filtered pages provide materially different content or search value.
Create a parameter inventory covering the owner, function, allowed values, indexation policy, canonical behavior, and cache behavior. Use standard anchor links only for approved crawl paths and prevent the storefront from generating unnecessary combinations.
5. Make Pagination and Product Discovery Crawlable
Infinite scroll and load-more interfaces can hide products behind user interaction. Every product set should therefore have a crawlable URL that does not depend on the interface being clicked.
Give each paginated category state a stable URL and link the pages with standard anchors. Keep the same URL convention across internal links, canonicals, and sitemaps.
If a paginated page represents a separate product set, it should usually be self-canonicalized. If you canonicalize every page to the top page, it can be tougher to discover deeper products.
For headless storefronts, render the first set of products and pagination links in the server response. In case your experience employs infinite scroll, offer paginated URLs that operate without JavaScript.
6. Maintain Consistency of Sitemaps, Robots, and Indexation Signals
Sitemaps should really only include canonical URLs, and those URLs should be indexable and return a 200 status code. In Salesforce B2C Commerce, sitemaps can be generated through Business Manager, though headless sites sometimes need extra configuration, so the whole setup isn’t always plug-and-play.
Use these checks to make sure your sitemap content and your indexation signals are consistent:
| Check | What to verify |
| Status | Every sitemap URL returns 200 without a redirect. |
| Canonical | Each URL is the preferred canonical destination. |
| Indexability | URLs are allowed by robots and meta robots directives. |
| Page quality | Offline, expired, empty, and private pages are excluded. |
| URL consistency | Hostname, protocol, locale path, trailing slash, and URL structure match internal links. |
| Freshness | Lastmod changes when the page changes materially. |
Use robots.txt to steer crawling, not deindexing. Don’t block CSS or JavaScript, they’re needed to actually render those key pages. Also verify the production runtime, and ensure the domain is properly serving the robots.txt file and the sitemap for both the PWA Kit and the hybrid sites.
7. Handle Product Variants, Discontinued Products, and Redirects
Clear technique for indexing product variants. Some stores may have a single product page with versions to choose from. Some may require different URLs for versions with different search demand and full-page content.
Google’s product variation guidance provides structured representations for multi-variant products. Each indexable version should have a persistent URL with product information.
If the product is no longer made, the correct answer will depend on what is replacing it-
| Situation | Recommended response |
| Temporary stockout | Keep the page live and show accurate availability and useful alternatives. |
| Permanent replacement | Redirect to the closest relevant successor. |
| Permanent removal with no replacement | Return 404 or 410. |
| Temporarily empty category | Remove it from the navigation and sitemap, then use the appropriate indexation response. |
Use one-hop permanent redirects for migrations, renamed categories, URL changes, and retired content. Test redirects for chains, loops, broad homepage redirects, and cross-locale errors.
8. Render Complete Metadata and Content in Initial HTML
A page may seem full in a browser but the initial HTML can contain a generic title, inadequate product content or missing metadata. This is particularly critical for headless stores.
Some crawlers don’t run JavaScript, therefore, Salesforce recommends placing important product information like names, descriptions, and prices in server-rendered HTML. Google suggests utilizing stable HTML signals for important SEO elements.
For the PWA Kit, check the server-rendered response and verify that it includes:
- One title
- One canonical
- One robots directive
- The correct H1
- Product or category content
- Crawlable links
- JSON-LD
- The correct HTTP status
But a React page returning a 200 status code while not found can still be a soft 404 issue.
For Storefront Next, loaders should return information crucial for SEO before rendering such as title, description, canonical, structured data, status and layout-defining media dimensions.
9. Implement Product and Breadcrumb Structured Data
Structured data helps search engines understand products, offers, availability, variants and breadcrumbs. It’s not promising a rich outcome, and the markup has to match the information accessible on the page.
For product templates, make sure that:
- Use Product and Offer or Aggregate Offer where appropriate.
- Keep SKU and other identifiers consistent.
- Match price, currency, availability, image, and product name to the selected page.
- Use ProductGroup and variant properties when supported.
- Add a BreadcrumbList that reflects the canonical browse path.
- Keep policy markup limited to policies the business actually publishes.
- Put frequently changing product information in the initial HTML when possible.
Validate templates with Google’s Rich Results Test and then sample live URLs in Search Console. Schema validation alone is not enough. Compare the markup against the visible product information and canonical URL.
10. Keep International and Multi-Site Signals Consistent
Multi-site SFCC implementations can create duplicate locale URLs, incorrect regional canonicals, missing alternates, and cross-domain redirect problems. Start with a locale matrix covering each market, language, hostname, path format, currency, canonical rule, and x-default target.
For each locale:
- Use a self-canonical unless the page is intentionally consolidated.
- Make hreflang references reciprocal.
- Point to alternate indexable 200-status pages.
- Use valid language-region codes such as en-GB.
- Make sure your canonical and hreflang signals are consistent.
- Check the production hostname and localized URLs in the sitemaps are valid.
- Make location redirects visitor- and crawler-friendly.
Choose one consistent locale structure and apply it across your SFCC site settings, navigation, sitemaps, canonical URLs, and hreflang tags.
11. Improve Core Web Vitals Without Breaking Commerce
Performance and technical SEO often depend on the same storefront systems. Slow SCAPI requests can delay server rendering, oversized images can increase LCP, missing dimensions can cause layout shifts, and excessive hydration can delay interaction. Any performance fix must also preserve pricing, inventory, personalization, and caching behavior.
Here is a practical breakdown of common SFCC performance risks and fixes-
| Metric | Typical SFCC cause | Practical fix |
| LCP | Uncached SSR, sequential API requests, oversized product images | Improve caching, parallelize critical requests, and optimize the actual LCP image. |
| CLS | Images without dimensions, late promotional content, font changes | Reserve space and stabilize above-the-fold elements. |
| INP | Heavy React hydration, variation handlers, third-party scripts | Reduce main-thread work and delay unnecessary programs. |
| TTFB | Cache misses, wide SCAPI extensions, personalization in shared HTML | Cache correctly and just ask for needed data. |
Measure field performance by template and market, rather than assuming one strong product-page score represents the whole catalog.
12. Validate Releases and Monitor Regressions
Technical SEO should be part of the release process rather than a check performed after traffic drops.
Before deployment:
- Snapshot status, canonical, robots, title, H1, hreflang, and schema.
- Crawl a protected preview environment.
- Compare old and new URL inventories.
- Approve redirects for valuable retired URLs.
- Test server-only, JavaScript-disabled, and rendered versions.
- Validate sitemap samples.
- Test performance across home, category, product, search, cart, and content templates.
After deployment, take a look at a handful of live URLs for 404s, 5xx errors, redirect trouble, and changes in Googlebot activity.
Also scan for wrong canonicals, soft 404s, schema mismatches, and those orphan product pages that seem to vanish. Don’t forget to write down the release date so you can line up organic performance before and after and see if any shifts are tied to the launch itself.
Otherwise, it might just be seasonal demand, merchandising updates, or some other things happening in the same window.
Conclusion - Keep the Signals Aligned
Technical SEO works best when the storefront gives search systems a consistent version of each page. URLs, canonicals, internal links, sitemaps, structured data, rendering, and locale signals should all point in the same direction. That consistency also makes future releases easier to test because teams can identify whether a change came from the storefront, catalog, routing, or content layer.
There are many tools that can help teams monitor technical health, search performance, and brand discovery. Once the core SFCC setup is working properly, tools such as AirPulse can add another view by showing how a brand appears across AI search and social conversations. It can sit alongside the existing SEO and analytics workflow rather than replacing it.
Frequently Asked Questions
Should every SFCC filter page be blocked?
No. Keep filtered pages that satisfy durable search demand and can support useful content, inventory, internal links, and a stable URL. Suppress or noindex combinations that represent transient states, thin inventory, sorting, or near-duplicate results.
Does robots.txt follow Google’s approach?
No. robots.txt is for crawling; it does not guarantee removal from the index. A blocked crawler may not see a noindex directive. For pages you want to hide but still want to keep accessible, use a crawlable noindex response. Permanently remove resources with 404 or 410.
How might AirPulse help with brand visibility tracking?
Technical SEO helps search engines crawl, understand, and index your pages. Once you fix the technical issues, businesses can go with AirPulse to track how their brand shows up in the more relevant AI search results, plus social conversations. That way, teams can also connect the technical SEO improvements with the wider brand visibility efforts.