Multi-Region, Same-Language hreflang: How en-US, en-GB, and en-AU Stop Fighting
One language across several regions (en-US, en-GB, en-AU) is the setup where hreflang cannibalizes itself most easily: to Google the three pages are almost the same English content, so if the annotation is incomplete or the pages have no local differences at all, the algorithm merges them into one and then picks a single regional version to serve everyone. The fix is a two-layer fallback—“language-region” combo codes plus a plain en (language only) and an x-default—together with genuine local differentiation on each regional page, because without it Google will ignore the tags even when they’re correct.
Why is “same language, many regions” harder than “many languages”?
When multiple languages (English/Chinese/Japanese) break, Google can still tell them apart with language detection. But en-US versus en-GB share the same script and are 90% identical—language detection can’t help at all, so the entire burden of splitting them falls on hreflang. That creates two problems unique to this scenario:
- Too similar, so merged. If the three regional versions differ only by a currency symbol or a spelling or two, Google routinely judges them duplicate content, indexes just one page, and zeroes out the rankings and traffic of the other two.
- A wrong region code voids the tag.
en-UK(the correct form isen-GB), or using the region codeuson its own as a language, invalidates that annotation—so it’s as if you never tagged it.
In short, same-language multi-region means winning two battles at once—“correct annotation” and “genuinely different content.” Winning only one isn’t enough.
The correct language-region annotation (with code)
The rule: write the region code as ISO 3166-1 alpha-2 in uppercase, joined to the language code with a hyphen; list every regional version plus a self-reference on every page, then add one plain-en line and one x-default line. Here’s an English pricing page sold into the US, UK, and Australia:
<link rel="alternate" hreflang="en-US" href="https://example.com/us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/pricing/" />
<link rel="alternate" hreflang="en-AU" href="https://example.com/au/pricing/" />
<link rel="alternate" hreflang="en" href="https://example.com/us/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/us/pricing/" />These five lines must appear, word for word, on all three pages at /us/, /uk/, and /au/. A few key points:
- Keep the extra plain
enline: when a user’s browser language is English but their region isn’t US/UK/AU (say, India or Singapore), Google falls back to the version this line names instead of picking one at random. x-defaultis the final catch-all, usually pointing at your primary market or a global, region-neutral version.enandx-defaultcan point to the same URL or to different ones.- Use region codes only for content that genuinely differs by region. If you only have one global English version, you shouldn’t split en-US/en-GB at all—just use a single
en. Forcing a split only manufactures cannibalization.
Which of the three approaches? A decision table
| Your actual situation | The annotation to use | Why |
|---|---|---|
| One global English version, no local differences | A single en + x-default |
Splitting into region codes over identical content gets merged by Google—wasted effort |
| Each region genuinely differs (currency, tax, regulation, local cases) | en-US / en-GB / en-AU + en + x-default |
Only content that’s different enough can support multi-region splitting |
| Same language, but you only serve the US and UK | en-US / en-GB + en + x-default |
The plain-language line catches every other English-speaking region so nothing falls through |
The one-line principle: ask “is the content different enough?” first, then decide whether to split by region. The annotation is the effect; local differentiation is the cause—don’t reverse the order.
The minimum local differences each regional version needs
Google states plainly that regional variants with substantially identical content are treated as duplicates and merged. To make en-US/en-GB/en-AU hold up, deliver at least three of these on every version:
- Currency and pricing: $ / £ / A$, and real local prices rather than an exchange-rate-converted string.
- Spelling and word choice: color/colour, optimization/optimisation, shipping/delivery—consistent across the whole page, not just the title.
- Local regulation and tax: GDPR (UK) versus CCPA (US), tax-inclusive or tax-exclusive labeling, local return policy.
- Local cases and contact details: local customer stories, local phone and address, local shipping options.
- Dates and units: MM/DD/YYYY versus DD/MM/YYYY, miles versus kilometers.
Doing nothing but “swap the currency symbol” is the most common failure—three or more substantive differences is the threshold at which Google is willing to index the pages separately.
How do you verify it’s working?
- GSC country × page cross-analysis: filter by “Page” for /us/, /uk/, /au/ and check whether each one’s impressions land in the right country. If /uk/ is pulling heavy impressions from the US, either the split has failed or the pages were merged.
- Spot-check the source for two-way consistency: pull 5 random pages and verify line by line that all five tags are identical across the three regional versions and that they link back to each other.
- Duplicate-content self-check: put two regional versions side by side—if you can’t name three or more differences yourself, Google will treat them as one page too.
FAQ
Q1: I only sell to the US and UK—do I need to split en-US and en-GB?
It depends on the content. If US and UK prices, tax, and cases genuinely differ, split them and give each its own canonical; if it’s just one English version, a single en is more robust—forcing a split manufactures cannibalization.
Q2: Is the UK en-GB or en-UK?
en-GB. UK is not an ISO 3166-1 region code, so en-UK is judged an invalid annotation and ignored outright—this is the most common rookie mistake in same-language multi-region setups.
Q3: Do I really need that extra plain en line?
Strongly recommended. Without it, users from regions that speak English but aren’t on your list—Singapore, India, South Africa—leave Google to pick a version at random. Adding en gives a defined landing spot and also catches cases x-default doesn’t cover.
Q4: My three regional versions are nearly identical—is tagging hreflang even useful?
It’s useless and possibly harmful. When content is substantially identical, Google merges the pages and ignores the multi-region tags. At that point you either create real local differences or collapse to a single en—don’t get stuck in the middle state of “tagged but not different.”
Q5: Which region should x-default point to? Your primary market or the most universal version (usually en-US or a region-neutral global page). x-default catches users who match none of your language-region conditions, so point it at the version least likely to be wrong.
The five-line, same-language multi-region annotation is easy to fumble—a missing region or a mistyped code—so GeoSeoToday’s hreflang generator and GEO checker auto-fills the full region list, the plain-language line, and x-default, heading off rookie errors like en-UK. To build your hreflang foundation first, read What Is hreflang? The Essential Guide for Multilingual Sites; for the full call on where x-default should point, see Where Should x-default Point?; and for the overall architecture, see the pillar The Complete Guide to Multilingual / International SEO.