Feature Request: en-GB / en-US as separate selectable languages (like zh-CN / zh-TW)

Shopify Discussion
1

We run a multi domain, multi market store with separate domains for each language, including two separate English domains, one targeting the US and one targeting the UK, alongside separate domains for German, French, and Dutch markets, with country based routing across all of them.

Right now Shopify only offers a single “English” language option in the admin, even though regional variants like zh CN and zh TW are already supported for Chinese.

I want to be precise about where the actual gap is, since I raised this in another thread and got great input. The hreflang side is fine, our en and en-GB tags are correctly split across the two English domains. Market level content adaptation through Translate & Adapt also works today, you can localize wording per market on the same en locale (Shopify’s own example is US Sweaters vs UK Jumpers).

The real problem is that locale derived fields, like URL slugs, are tied to the locale itself, not the market. When German is added as an actual language, slugs regenerate for that locale. With two markets sharing en, slugs stay identical across both English domains no matter what gets overridden in Localize, only the visible copy changes. That identical URL structure is what reads as duplicate content to Google, not the on page text.

What we’re asking for: allow en-GB, en-US, en-AU (and similar regional English variants) to be selectable as separate languages, the same way Chinese regional variants already work, so slugs and other locale derived fields can differentiate properly across English speaking markets.

If you’re running a multi region English setup and hitting the same wall, an upvote and a comment with your setup would really help get this in front of the product team.

4 Answers

4
2

Your distinction between visible market content and locale-derived handles is useful. One SEO nuance: the same slug text on two different domains does not, by itself, make the URLs duplicates. Google evaluates the page content and signals, and Shopify says properly configured Markets automatically generate hreflang and canonical URLs. The practical gap is market-specific handle control and redirect governance, not simply that both domains use the same path string.

Before changing architecture, I would crawl a small representative set across the US and UK domains and verify five things: the final domain, HTTP status, self-canonical, reciprocal en-US/en-GB hreflang, and whether the visible content actually differs. If those pass, separate expansion stores may be unnecessary. If you need region-specific handles for existing keyword URLs or to preserve URLs from a migration, then the feature request still matters.

Roughly how many indexed URLs are involved, and were the US and UK domains migrated from separate stores or launched together? That would show whether this is mainly a localization limitation or a migration/redirect QA problem.

Shopify references: https://help.shopify.com/en/manual/markets/seo and https://help.shopify.com/en/manual/markets/customizations/domains-and-languages
Google reference: Managing Multi-Regional and Multilingual Sites | Google Search Central  |  Documentation  |  Google for Developers

4

Thanks both, really useful pushback and this actually helps me narrow the ask.

To answer directly: 53 products and 17 collections, so this is a small catalog, not thousands of URLs. Both English domains are on the same store, .co.uk was added as an additional domain/market rather than migrated from a separate store, so there’s no legacy redirect debt here, this is a clean, current setup.

Confirmed on the slug question, one live example:
/collections/table-clocks-modern-decorative

That exact path exists identically on both English domains right now.

Kai, appreciate the reminder that identical slugs alone don’t equal duplicate content, that’s fair and I don’t want to overstate it. What we’re seeing isn’t a canonical or hreflang failure, both are configured correctly. It’s more that Localize only lets us differentiate visible copy, not the handle itself, so even wanting to run “sweaters” vs “jumpers” as genuinely different landing pages targeting different regional search intent isn’t possible without a workaround. At our current scale that’s manageable, but it’s a hard ceiling if the catalog grows.

J.brin, right now we’re just living with identical slugs, no redirects or separate theme files, since there’s no clean way to override the handle at the market level. And yes, I did raise this directly with Shopify Support before posting here, an advisor confirmed it’s a known gap and submitted it as an internal feedback report, though there’s no case number or way to track its status from our side, which is part of why I’m also raising it here.

So I’d frame this less as “duplicate content is definitely happening” and more as “the tooling doesn’t let us do regional handle differentiation even when we want to,” which matters for anyone running true multi region English content, not just at our scale.

5

Hello @Ozkan_Kaya
That’s a reasonable differentiation for stores catering to more than one English-speaking market. If you have already implemented hreflang and localized content, regional English locales can be useful for having more control over locale specific fields like url handles and other translated values. I’d also add a few concrete examples where having the same English urls is causing you issues with SEO or indexing, that gives the request a clearer technical context and makes the feature gap easier to evaluate.

6

Hi @Ozkan_Kaya

Building on what gotinker said, the handling_time/transit_time split is the right mechanism here.

The part that trips people up on Shopify specifically is where you actually set that override. If you’re running Google Shopping through the native Google & YouTube channel app, last I checked there’s no per-product field in that app’s UI for min_handling_time / max_handling_time. It only exposes shipping settings at the account or shipping-profile level. So even with the right plan, there’s nowhere in that app to type 7 and 10 for just the MTO SKUs.

The workaround that actually works: build a supplemental feed, just a Google Sheet with columns id, min_handling_time, max_handling_time, and register it in Merchant Center against your primary feed. It patches those two attributes for the MTO product IDs only, everything else keeps inheriting the account default. Google merges by ID, so your main feed doesn’t need to change at all.

Before BFCM I’d pull up Merchant Center diagnostics on a handful of those MTO SKUs and check that the shipping row actually shows the overridden value, not the account default. The merge doesn’t always take on the first crawl, sometimes it’s a day or two, so this isn’t something to set up the week of BFCM and assume is live.

Also worth a check while you’re at it: does your on-site shipping policy page for those MTO items literally say “7-10 days” somewhere generic? If auto-update ever gets re-enabled for a region you didn’t opt into on purpose, that’s the text it’ll crawl and smear back onto the fast SKUs.

Curious what the diagnostics rows show for you once you set up the supplement, that’ll tell you if the merge is actually being read correctly.