Skip to content
Go Live

SEO indexing

This page covers URL and crawling concerns so search engines index the right Adobe Commerce storefront pages on Edge Delivery Services. For how indexing fits with platform SEO and metadata on first-load HTML, start with SEO overview.

These recommendations come from customer and partner storefront projects on Edge Delivery Services. Use them to keep URLs, canonical signals, and crawlers aligned.

  • When product detail pages (PDPs) have multiple URLs, set a consistent canonical URL for each product.
  • Make sure that canonical URLs do not point to redirects (301).

For configurable products, ensure that the canonical URL is set to the parent product URL. Without this, Google may index child product URLs instead, creating duplicate content issues.

The default PDP URL format is:

/products/{urlKey}/{sku}

The urlKey carries the SEO-relevant product name, and the sku is required for Catalog Service queries. You can customize the format, but changes to the URL structure require CDN configuration.

For multi-store setups or stores supporting multiple locales:

  • Verify a correct hreflang setup . You can validate using the hreflang Tags Testing Tool .

  • Verify that the Magento-Store-Code header value defined in your storefront configuration is part of the URL for every Catalog Service or Live Search request.

The Commerce boilerplate template includes a mechanism to prevent stale data from being served. It does this by adding a dynamic cache-busting parameter to Catalog Service requests.

When your configuration headers change, the browser fetches fresh data instead of using cached responses. This helps keep your storefront content up to date.

Here’s how the boilerplate handles it:

  1. It collects headers from your storefront configurationpublic.headers.all.* and public.headers.cs.*
  2. It creates a short hash (5 characters by default) based on those headers.
  3. It adds the hash to the Catalog Service URL using the format ?cb=<hash>.
  4. When the headers change, it generates a new hash automatically.

This ensures that any change—like a new store code or view code—triggers a fresh fetch and bypasses CDN-cached GET requests to the Catalog Service.

You don’t need to enable or configure anything. The Commerce boilerplate handles everything automatically when:

  • The PDP drop-in component initializes.
  • Any component sends a request to the Catalog Service.
  • Your configuration headers update.

The boilerplate always manages the cb parameter for you.

The Edge Delivery Services redirect sheet handles most migration-time URL changes: removing .html suffixes, restructuring content paths, and remapping product URLs after a replatform. Create the redirect list as a spreadsheet called redirects in the root of your project folder. Each row maps a source path to a destination URL or path. Preview changes before publishing so stakeholders can verify them on the .page preview site.

The redirect sheet matches URL paths only. The Source column accepts a relative path, so query parameters are not part of the match. It cannot target individual search terms like /search?q=running. For that use case, see the search redirects tutorial. For CDN-level wildcard redirects, see Content delivery network.

If you are migrating from Adobe Commerce on Cloud (PaaS) to Adobe Commerce as a Cloud Service or Adobe Commerce Optimizer, PaaS URL rewrites (Marketing > SEO & Search > URL Rewrites) don’t transfer automatically. Add any active ones as rows in the EDS redirect sheet.

For the full reference — spreadsheet column names, wildcard CDN redirects, and SEO guidance for site migrations — see Redirects on AEM.live .

Edge Delivery Services generates a sitemap automatically upon publication. Commerce storefronts often require additional sitemap configuration to support prerendered catalog pages, multi-store hreflang tags, and large catalogs that exceed the 50,000-URL-per-file limit.

See Sitemaps for configuration options and Commerce-specific guidance.

  • You can validate indexing using Google Search Console by inspecting the markup of the crawl to see if all important information was tracked.
  • Transactional pages (for example, cart, checkout, and account) should not be indexed.
  • Staging or any non-production environments must not be indexed. Once indexed, URLs from a staging environment can reduce traffic to the production environment. It takes a significant amount of time to remove staging URLs from the Google index.