BigCommerce Hreflang and Multi-Storefront SEO

BigCommerce multi-storefront unlocked genuine international selling for merchants stuck running parallel installs. One control panel, multiple storefronts, each with its own domain, currency, and language. That sounds clean in a sales deck. In production, it creates a dense web of duplicate content signals, conflicting structured data, and geo-targeting rules that actively block Googlebot from indexing your international pages.

This post documents the exact implementation steps we use to deploy hreflang, fix currency schema, and prevent Akamai geo-redirects from hiding storefronts from Google. Every code snippet here has been tested on live BigCommerce multi-storefront builds. If you’re looking for a broader overview of BigCommerce SEO, start there. This guide goes deep on the international layer.

BigCommerce Multi-Storefront Architecture: Shared vs Separate Catalogues

BigCommerce multi-storefront ships two distinct catalogue models, and each one creates a different SEO problem. Understanding which model you’re running determines every hreflang and indexation decision that follows.

Shared Catalogue (One Product Set, Multiple Storefronts)

A shared catalogue means one master product set powers every storefront. You create a product once in Products > View, and it appears on storefront A (US), storefront B (UK), storefront C (DE), and any others you’ve configured. Pricing adjusts per currency. Product URLs follow each storefront’s domain. The product data itself lives in one place.

The SEO implication is immediate: every storefront generates its own URL for the same product. us.example.com/blue-widget/ and uk.example.com/blue-widget/ serve nearly identical content. Google sees two pages with the same title, the same description, the same product copy, differentiated only by price and currency symbol. Without hreflang, Google treats these as duplicates and picks one to index. Usually, it picks the US version because Googlebot’s primary crawl originates from US data centres.

Shared catalogues require hreflang on every product page, every category page, and every brand page. Miss one template and you’ve got partial hreflang coverage, which Google handles worse than no hreflang at all. Google’s John Mueller has stated this directly: inconsistent hreflang signals get ignored entirely.

Separate Catalogues (Independent Product Sets per Storefront)

Separate catalogues assign distinct product sets to each storefront. Your UK store sells different SKUs than your US store, or the overlap is partial. You control this via Products > View > Storefront Assignment in the BigCommerce admin, toggling which products appear on which storefront.

Separate catalogues don’t eliminate the SEO problem. They change it. Products unique to one storefront don’t need hreflang. Products shared across storefronts still do. You end up with a hybrid: some pages need hreflang annotations, others don’t. That partial deployment is harder to maintain than full deployment because you need logic that checks whether a given product exists on the sibling storefront before outputting the tag.

For a comprehensive walkthrough of BigCommerce SEO fundamentals that apply across both models, see our BigCommerce SEO guide.

How the Control Panel Handles Multi-Storefront

Navigate to Channel Manager > Storefronts in the BigCommerce admin. Each storefront gets its own channel ID. This channel ID is critical for API-driven hreflang because it’s the identifier you’ll use to pull storefront-specific URLs from the Catalog API. Each channel also gets its own theme assignment under Storefront > Themes, its own Script Manager instance under Storefront > Script Manager, and its own SEO settings under Storefront > SEO.

The per-storefront isolation is both the feature and the constraint. You can’t inject a script into storefront A’s Script Manager and have it execute on storefront B. Every storefront operates as an independent frontend. That means every hreflang implementation must be deployed to every storefront individually.

Hreflang Implementation via Script Manager

BigCommerce’s Stencil themes don’t expose a global header partial that spans multiple storefronts. Each storefront runs its own theme instance. Editing one theme’s templates/layout/base.html only affects that storefront. You’d need to maintain synchronised hreflang blocks across every theme, and they’d fall out of sync the moment you updated one storefront’s theme without updating the others.

Script Manager solves this. It injects scripts into the <head> or <footer> of every page on a given storefront, and it’s accessible per-storefront under Storefront > Script Manager. The approach: deploy a JavaScript snippet to each storefront’s Script Manager that dynamically generates hreflang link elements based on the current URL path.

The Script Manager Hreflang Snippet

Here’s the exact snippet. Deploy this to each storefront’s Script Manager, placed in the Head location, with the All Pages scope selected.

<script>
(function() {
  var defined = [
    { href: 'https://us.example.com', hreflang: 'en-US' },
    { href: 'https://uk.example.com', hreflang: 'en-GB' },
    { href: 'https://de.example.com', hreflang: 'de-DE' },
    { href: 'https://fr.example.com', hreflang: 'fr-FR' }
  ];
  var path = window.location.pathname + window.location.search;
  var head = document.head;

  defined.forEach(function(entry) {
    var link = document.createElement('link');
    link.rel = 'alternate';
    link.hreflang = entry.hreflang;
    link.href = entry.href + path;
    head.appendChild(link);
  });

  // x-default points to primary storefront
  var xDefault = document.createElement('link');
  xDefault.rel = 'alternate';
  xDefault.hreflang = 'x-default';
  xDefault.href = 'https://us.example.com' + path;
  head.appendChild(xDefault);
})();
</script>

Why This Approach Works (and Its Limits)

This snippet runs client-side. Google renders JavaScript, so it reads dynamically injected <link> elements. Google has confirmed this in their documentation on JavaScript SEO. The tags land in the rendered DOM, and Googlebot processes them during the rendering phase.

The limit: Google’s rendering queue introduces a delay. Pages that rely on JavaScript-injected hreflang may take longer to have their international targeting recognised compared to server-rendered hreflang in raw HTML. For most merchants, the delay is acceptable. For large catalogues with thousands of products across multiple storefronts, consider the sitemap-level approach described later in this post as a supplement.

Another limit is path parity. The snippet assumes every storefront uses the same URL path for the same product. If us.example.com/blue-widget/ maps to de.example.com/blaues-widget/, the simple path concatenation breaks. You’d need a lookup table or API call to resolve the correct path per storefront. BigCommerce’s Catalog API (GET /v3/catalog/products/{id} with the channel_id parameter) returns the storefront-specific custom URL, which you can use to build that mapping.

Deploying Across All Storefronts

You must add this snippet to every storefront. Log into BigCommerce, go to Channel Manager > Storefronts, select each storefront in turn, navigate to Storefront > Script Manager, and create a new script with the same code. The defined array stays identical across all storefronts. The snippet self-references correctly because it includes the current storefront’s domain in the array, satisfying the self-referencing requirement.

Hreflang Tag Syntax and Common Mistakes

Hreflang annotations use ISO 639-1 language codes and optional ISO 3166-1 Alpha 2 region codes. The syntax is precise, and Google silently ignores malformed tags without reporting errors in most cases.

Correct Tag Format

<link rel="alternate" hreflang="en-US" href="https://us.example.com/blue-widget/" />
<link rel="alternate" hreflang="en-GB" href="https://uk.example.com/blue-widget/" />
<link rel="alternate" hreflang="de-DE" href="https://de.example.com/blue-widget/" />
<link rel="alternate" hreflang="x-default" href="https://us.example.com/blue-widget/" />

The x-default Tag

The x-default value tells Google which URL to show users whose language/region doesn’t match any of the defined hreflang values. Set this to your primary storefront. If you don’t include x-default, Google picks one, and it’s not always the one you want.

Self-Referencing Tags Are Mandatory

Every page must include a hreflang tag pointing to itself. The UK product page must include hreflang="en-GB" pointing to its own URL. Omitting the self-reference is the single most common hreflang mistake, and it causes Google to discard the entire hreflang set for that page. The Script Manager snippet above handles this automatically because the current storefront’s domain is included in the defined array.

Bidirectional Confirmation

Hreflang requires confirmation from both sides. If the US page declares an alternate for the UK page, the UK page must also declare an alternate for the US page. One-directional hreflang gets ignored. This is why deploying the same snippet to every storefront matters. If you forget one storefront, the bidirectional chain breaks and Google ignores the entire set.

Common Syntax Failures

• Wrong region codes: Using en-UK instead of en-GB. The UK’s ISO 3166-1 code is GB, not UK. Google silently drops the tag.
• HTTP/HTTPS mismatch: Declaring http://uk.example.com when the site serves https://. The URLs must match exactly, including protocol.
• Trailing slash inconsistency: One storefront’s canonical uses a trailing slash, the other doesn’t. The hreflang href must match the canonical URL precisely.
• Language-only codes for region-specific content: Using en when you mean en-US. If you’re targeting a specific region with specific pricing, use the full language-region code.
• Missing pages: Pointing hreflang to a URL that returns 404. This breaks the entire annotation set for that page group.

Currency SEO and JSON-LD Overrides

BigCommerce’s default Product structured data outputs a priceCurrency value based on the storefront’s default currency. On a well-configured multi-storefront setup, storefront A (US) outputs "priceCurrency": "USD" and storefront B (UK) outputs "priceCurrency": "GBP". That part works if each storefront’s default currency is set correctly under Settings > Currency.

The problem appears with the Offer schema. BigCommerce’s built-in schema template in Stencil outputs product schema via the templates/components/products/product-view.html partial, which pulls pricing from the theme’s context object. The context object reflects the shopper’s selected currency, not necessarily the storefront’s primary currency. If a US shopper switches to EUR on the US storefront, the schema outputs EUR pricing on a page that Google indexed with USD pricing. This creates inconsistent structured data across crawls.

Manual JSON-LD Override in Stencil

The fix is to hardcode the correct currency in each storefront’s theme. In your Stencil theme’s templates/pages/product.html, override the default schema with a custom JSON-LD block. For detailed guidance on Product schema beyond currency, see our BigCommerce structured data guide.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "{{product.title}}",
  "image": "{{product.main_image.data}}",
  "description": "{{product.description}}",
  "sku": "{{product.sku}}",
  "brand": {
    "@type": "Brand",
    "name": "{{product.brand.name}}"
  },
  "offers": {
    "@type": "Offer",
    "url": "{{product.url}}",
    "priceCurrency": "GBP",
    "price": "{{product.price.without_tax.value}}",
    "availability": "{{#if product.availability}}https://schema.org/InStock{{else}}https://schema.org/OutOfStock{{/if}}",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

Deploy a version of this block to each storefront’s theme, changing only the priceCurrency value. The US theme gets "USD". The UK theme gets "GBP". The DE theme gets "EUR". This ensures Google’s Rich Results validator always sees the correct currency for the storefront it’s crawling.

Suppressing BigCommerce’s Default Schema

BigCommerce injects its own Product schema by default. If you add a custom block without removing the default, you’ll get duplicate Product schema on the page. Google handles duplicate schema poorly. It picks one, and you can’t control which one.

To suppress the default, edit the Stencil theme’s templates/components/products/product-view.html and remove or comment out the existing itemscope itemtype="http://schema.org/Product" microdata attributes. BigCommerce uses microdata, not JSON-LD, for its default product schema. Your custom JSON-LD and BigCommerce’s microdata can coexist technically, but Google may read conflicting currency values. Remove the microdata to avoid the conflict.

Akamai Geo-Targeting and Googlebot Crawl Problems

BigCommerce runs its storefronts behind Akamai’s CDN. Akamai can be configured to geo-target visitors, redirecting them to the storefront matching their geographic location. A visitor from the UK hitting us.example.com gets 302-redirected to uk.example.com. This feels like a good user experience. It’s an SEO disaster.

Googlebot’s primary crawl infrastructure operates from US-based IP addresses. When Akamai geo-redirects US IPs to the US storefront, Googlebot can never reach the UK storefront. It requests uk.example.com, Akamai sees a US IP, and redirects to us.example.com. Google indexes the US version. The UK version doesn’t exist in Google’s index. Your UK storefront is invisible to Google.

Failure Modes We’ve Seen

This isn’t theoretical. We’ve diagnosed this exact problem on live BigCommerce stores. The symptoms:

• Google Search Console’s URL Inspection tool shows the UK storefront’s pages as “Crawled – currently not indexed” or “Page with redirect.”
• The Coverage report shows a spike in “Redirect” entries for the UK storefront’s submitted sitemap URLs.
• Search results for UK-targeted keywords show the US storefront URL instead of the UK URL.
• Hreflang tags appear correct in the source, but GSC’s International Targeting report shows no recognised hreflang data for the UK property.

For related CDN and performance concerns on BigCommerce, our BigCommerce site speed and Akamai guide covers the CDN layer in more detail.

Fix: Whitelist Googlebot IP Ranges

Google publishes its crawler IP ranges. You can retrieve them by querying the DNS TXT record for _netblocks.google.com or by checking Google’s published JSON file at https://developers.google.com/search/apis/ipranges/googlebot.json.

Configure Akamai to exempt these IP ranges from geo-redirect rules. The implementation path depends on your Akamai configuration access. BigCommerce Enterprise merchants can request this through BigCommerce support, who manage the Akamai property. Provide the Googlebot IP list and specify that requests from those IPs should be served the content of the requested domain without redirection.

Akamai’s Property Manager uses “match conditions” based on client IP. The rule logic is:

IF Client IP is in [Googlebot IP ranges]
  THEN skip geo-redirect behavior
  AND serve requested origin

After implementing the whitelist, verify in GSC’s URL Inspection tool that Googlebot can now reach and render each storefront’s pages without redirect chains.

Alternative Fix: Remove Geo-Redirects, Use Hreflang

The cleaner long-term solution is to remove server-side geo-redirects entirely and let hreflang do the work. Hreflang tells Google which version to show in which country’s search results. There’s no need to redirect Googlebot. Present a language/region selector on the page for human visitors who land on the wrong storefront. This approach eliminates the Googlebot access problem entirely and gives users control over which storefront they browse.

Google explicitly recommends against geo-based redirects for this reason. Their documentation states: “Don’t use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl your site properly.”

Sitemap-Level Hreflang as an Alternative to On-Page Tags

On-page hreflang tags (via Script Manager or theme code) aren’t the only implementation method. Google also supports hreflang annotations within XML sitemaps. For large multi-storefront catalogues, the sitemap approach offers several advantages.

Sitemap Hreflang Syntax

Each URL entry in the sitemap includes xhtml:link elements declaring its alternates:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://us.example.com/blue-widget/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://us.example.com/blue-widget/" />
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://uk.example.com/blue-widget/" />
    <xhtml:link rel="alternate" hreflang="de-DE" href="https://de.example.com/blue-widget/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://us.example.com/blue-widget/" />
  </url>
</urlset>

Why Sitemap Hreflang Works Better for Large Stores

BigCommerce auto-generates sitemaps for each storefront. The default sitemaps don’t include hreflang annotations. You’ll need to generate custom sitemaps externally and either host them on your domain or submit them via GSC.

The advantage: sitemap-level hreflang doesn’t depend on JavaScript rendering. Google processes sitemaps directly during crawl scheduling. There’s no rendering delay. For a store with 10,000 products across four storefronts, that’s 40,000 pages that need hreflang. Processing 40,000 JavaScript-rendered pages takes longer than processing four sitemap files with hreflang annotations baked in.

The disadvantage: you must keep the custom sitemaps synchronised with your catalogue. Every time you add, remove, or change a product URL, the sitemaps need updating. This typically requires a scheduled job that pulls product URLs from the BigCommerce Catalog API (using the /v3/catalog/products endpoint with the include=custom_url parameter for each channel) and regenerates the sitemap XML.

Combining On-Page and Sitemap Hreflang

You can use both methods simultaneously. Google will process both and reconcile them. If there’s a conflict, Google picks the one it trusts more. Running both provides redundancy. The Script Manager approach catches pages that might not be in your custom sitemap, and the sitemap approach covers pages before Google renders them.

Language-Specific Metadata in Stencil Themes

Hreflang tells Google which page to show in which region. It doesn’t handle on-page content. Each storefront’s Stencil theme needs language-appropriate metadata: title tags, meta descriptions, Open Graph tags, and HTML lang attributes.

Setting the HTML Lang Attribute

BigCommerce Stencil themes set the lang attribute in templates/layout/base.html. The default is usually en. For a German storefront, change it to de. For a French storefront, fr. This is a per-theme edit.

<!-- In templates/layout/base.html for DE storefront -->
<html lang="de">

The lang attribute doesn’t affect Google’s hreflang processing directly, but it does affect accessibility tools, browser translation prompts, and third-party SEO audit tools that flag mismatched lang attributes and hreflang values.

Localised Title Tags and Meta Descriptions

BigCommerce generates title tags and meta descriptions from product data entered in the admin. Under Products > [Product] > SEO, you set the page title and meta description. The catch: these fields are shared across storefronts in a shared catalogue model. You can’t set a German meta description for the DE storefront and an English one for the US storefront from the same product record.

The workaround uses Stencil’s Handlebars templating. In each storefront’s theme, you can append or prepend localised text to the default title tag. Edit templates/layout/base.html:

<!-- DE storefront: append German suffix -->
<title>{{head.title}} | Jetzt kaufen bei Example DE</title>

For full localisation of product descriptions, you’d need to use BigCommerce’s metafields API or a third-party translation layer. The metafields approach stores translated content as custom fields on each product, which you then render in the Stencil template via Handlebars.

Open Graph Tags for Social Sharing

Each storefront should output its own og:locale tag. BigCommerce Stencil doesn’t set og:locale by default. Add it to templates/layout/base.html:

<!-- US storefront -->
<meta property="og:locale" content="en_US" />

<!-- DE storefront -->
<meta property="og:locale" content="de_DE" />

Also add og:locale:alternate tags for each sibling storefront. This tells Facebook and LinkedIn which localised versions exist when someone shares a product link:

<!-- On DE storefront, declare US and UK alternates -->
<meta property="og:locale:alternate" content="en_US" />
<meta property="og:locale:alternate" content="en_GB" />

Canonical Tags Across Storefronts

Each storefront must self-canonicalise. The US storefront’s /blue-widget/ page should have a canonical pointing to https://us.example.com/blue-widget/, not to any other storefront. BigCommerce handles this correctly by default, as each storefront generates its own canonical tags. Verify this in the rendered source. If canonicals point cross-storefront, Google will consolidate indexing to one version and ignore the other, regardless of your hreflang setup.

Testing Hreflang: Tools and Google Search Console

Hreflang errors are silent. Google doesn’t report most hreflang issues in Search Console. You’ll only notice problems when your international pages don’t appear in the correct regional search results. Proactive testing is the only way to catch issues before they affect traffic.

Aleyda Solis’ Hreflang Tag Generator and Validator

The hreflang Tags Testing Tool at aleydasolis.com/english/international-seo-tools/hreflang-tags-generator/ is the industry standard validator. Enter your URL, and it crawls the page (or sitemap), extracts hreflang annotations, and reports:

• Missing self-referencing tags
• Missing return tags (broken bidirectional confirmation)
• Invalid language or region codes
• URLs that return non-200 status codes
• Mismatched canonical and hreflang URLs

Run this tool against a sample of product, category, and landing pages from each storefront. Don’t just test the homepage. Hreflang errors often appear on specific page types because of template-level issues that don’t affect the homepage.

Google Search Console International Targeting Report

In GSC, navigate to Legacy tools and reports > International Targeting. This report shows two things:

1. Language tab: Displays the hreflang tags Google has detected and any errors. Common errors include “No return tags” and “Unknown language code.” If this tab shows zero data for a storefront’s property, Google isn’t reading your hreflang tags at all. Check whether Akamai is redirecting Googlebot away from the storefront.
2. Country tab: Lets you set a geographic target for the property. For ccTLD-based storefronts (like example.co.uk), Google infers the target country automatically. For subdomain or subdirectory setups on gTLDs, set the country target explicitly here.

URL Inspection for Rendered Hreflang

GSC’s URL Inspection tool renders the page as Googlebot sees it. Use it to verify that your Script Manager hreflang tags appear in the rendered HTML. Enter a URL, click “Test Live URL,” and inspect the rendered HTML output. Search for hreflang in the rendered source. If the tags don’t appear, Google isn’t processing them. Common causes: the Script Manager script is set to load in the footer instead of the head, or there’s a JavaScript error preventing execution.

Chrome DevTools Verification

Before testing in GSC, verify locally. Open a product page in Chrome, open DevTools (F12), go to the Elements panel, and search for hreflang in the head. You should see one <link> element per storefront plus one for x-default. If you have four storefronts, you should see five <link rel="alternate"> elements.

Bulk Validation with Screaming Frog

Screaming Frog’s SEO Spider can crawl all storefronts and extract hreflang data in bulk. Configure the spider to crawl each storefront’s domain, enable JavaScript rendering (Configuration > Spider > Rendering > JavaScript), and check the Hreflang tab in the results. The tool flags missing return tags, missing self-references, and inconsistent URLs across the entire crawl. For a store with thousands of pages, this is the fastest way to audit hreflang coverage.

Implementation Checklist

Before launching international storefronts, walk through this checklist. Each item corresponds to a specific failure mode we’ve encountered on live BigCommerce multi-storefront deployments.

1. Catalogue model confirmed. Shared or separate. Documented which products overlap across storefronts.
2. Script Manager snippet deployed to every storefront. Verified in each storefront’s Script Manager under Storefront > Script Manager.
3. x-default tag points to primary storefront. Confirmed in rendered source.
4. Self-referencing tags present on every storefront. Verified with Aleyda Solis tool.
5. Bidirectional confirmation working. Every storefront’s tags reference every other storefront, and every other storefront reciprocates.
6. Canonical tags self-reference per storefront. No cross-storefront canonicals.
7. JSON-LD Product schema uses correct priceCurrency per storefront. Tested with Google’s Rich Results Test for each storefront’s product page.
8. Default BigCommerce microdata suppressed or aligned. No conflicting currency in microdata and JSON-LD.
9. Akamai geo-redirect exempts Googlebot IPs. Confirmed via GSC URL Inspection that Googlebot can access every storefront without redirect.
10. HTML lang attribute correct per storefront theme. Checked in templates/layout/base.html for each theme.
11. og:locale and og:locale:alternate tags deployed. Verified in rendered source.
12. GSC International Targeting report shows recognised hreflang. No errors in the Language tab.
13. Custom sitemaps with hreflang submitted (if applicable). Verified processing in GSC Sitemaps report.

For ongoing BigCommerce development and multi-storefront maintenance, these checks should be part of every deployment cycle.

Frequently Asked Questions

Does BigCommerce natively support hreflang tags for multi-storefront setups?

BigCommerce does not generate hreflang tags automatically for multi-storefront configurations. The platform treats each storefront as an independent channel with its own theme, metadata, and scripts. You must implement hreflang manually through Script Manager, custom Stencil theme code, or sitemap-level annotations. There’s no toggle in the admin panel that enables cross-storefront hreflang.

Can Googlebot crawl all my BigCommerce storefronts if I use Akamai geo-targeting?

Not by default. Akamai geo-targeting redirects visitors based on IP location, and Googlebot crawls primarily from US-based IPs. If your Akamai configuration redirects non-local IPs to a different storefront, Googlebot gets redirected away from your international storefronts and can only access the US version. The fix is to whitelist Googlebot’s published IP ranges in the Akamai Property Manager so those requests bypass geo-redirect rules. Alternatively, remove geo-redirects entirely and rely on hreflang to direct users to the correct regional search result.

Should I use on-page hreflang tags or sitemap-level hreflang?

Both methods work, and you can use them simultaneously. On-page tags via Script Manager are easier to deploy and maintain for smaller catalogues. Sitemap-level hreflang scales better for stores with thousands of products because Google processes sitemaps during the crawl scheduling phase without needing to render JavaScript. For large BigCommerce multi-storefront setups, we deploy both: Script Manager for immediate coverage and custom sitemaps for rendering-independent redundancy.

How do I handle product schema when different storefronts use different currencies?

Override BigCommerce’s default Product microdata with custom JSON-LD in each storefront’s Stencil theme. Hardcode the correct priceCurrency value (e.g., “USD”, “GBP”, “EUR”) in each theme’s product template. Suppress or remove the default microdata from templates/components/products/product-view.html to prevent conflicting currency values. Each storefront’s theme is independent, so you can set different currency values without affecting other storefronts.

What happens if my hreflang implementation is only partially deployed across storefronts?

Google requires bidirectional confirmation for hreflang to work. If storefront A declares an alternate pointing to storefront B, but storefront B doesn’t reciprocate, Google ignores the entire hreflang set for those pages. Partial deployment is worse than no deployment. Google’s systems treat unconfirmed hreflang signals as unreliable and discard them. Deploy hreflang to all storefronts simultaneously, and verify bidirectional confirmation with Aleyda Solis’ testing tool before considering the implementation complete.