US, UK and Australian English pages: when hreflang is worth it

Short answer: Build separate US, UK and Australian English pages only when something real differs for each market, such as price and currency, shipping, contact details or product range; spelling alone rarely justifies tripling your pages. If you do build them, connect every version with hreflang (en-US, en-GB, en-AU), include a self-reference and an x-default fallback, and make sure every page links back. Google's documentation explicitly lists "small regional variations in a single language" as a case where hreflang is recommended.

Decide first: do you need regional versions at all?

Most small businesses selling to several English-speaking countries are better off with one English site. Regional versions mean every page, every update and every blog post now exists three times. Before you commit, run each page type through these questions.

A common middle ground: one shared English blog and resource section, with regional versions only for the homepage, pricing, product, shipping and contact pages. The pages where money and logistics differ are the ones searchers in each country notice.

What makes regional versions more than duplicates

Google's own documentation says localized versions are only considered duplicates if the main content remains untranslated, and its multi-regional guidance adds that when you have similar content on different URLs in the same language, you should pick a preferred version and use canonical and hreflang so the right regional URL is served. For three English versions, that means each must earn its existence with local details: prices in USD, GBP or AUD, local delivery information, local contact details, and spelling that matches the market. Google's multi-regional page lists local addresses, phone numbers, local language and currency among the signals it uses to understand who a site is for.

Choosing a URL structure

You have three common choices:

• Subfolders on one domain: example.com/us/, example.com/uk/, example.com/au/. Easiest to run and keeps all links on one domain.
• Country domains: example.com, example.co.uk, example.com.au. Strong local signal, but three sites to maintain and promote.
• Subdomains: us.example.com and so on. Possible, but they usually combine the drawbacks of the other two.

For a small team, subfolders are almost always the practical choice.

Implementation steps

1. Use the right codes

Google's localized-versions documentation says the hreflang value is a language code in ISO 639-1, optionally followed by a region in ISO 3166-1 Alpha 2. That gives you:

• en-US for the United States
• en-GB for the United Kingdom (not "en-UK", which isn't a valid region code)
• en-AU for Australia
• en on its own for English speakers anywhere

You can't use a country code alone; the first part is always the language.

2. Add a fallback

Google recommends a catchall for users of the same language who aren't in any of your specified regions, and an x-default value for unmatched languages, especially on country selectors or auto-redirecting home pages. In practice, point x-default (and optionally a plain en) at the version you'd show someone in Canada or New Zealand.

3. List every version on every version

Each page must list itself as well as all its alternates, with fully qualified URLs including https. For the pricing page, every regional version carries the same block:

<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="x-default" href="https://example.com/pricing/" />

Google's documentation is explicit that if two pages don't both point to each other, the tags are ignored. A missing return link is the most common reason hreflang "does nothing".

4. Pick one method and stay with it

Google treats HTML link tags, HTTP headers and XML sitemap entries as equivalent. For large sites, the sitemap is easier to keep consistent: each URL gets its own entry listing every variant, including itself, using the xhtml namespace.

5. Keep canonicals self-referencing

Each regional page should point its canonical at itself, not at the US version. A canonical pointing elsewhere tells Google the regional page is a copy, which undermines the hreflang set.

6. Don't auto-redirect by location

Google's multi-regional guidance says to avoid automatically redirecting users to a language version based on what you think they need, because it can stop users and search engines from seeing all versions. Offer a visible country switcher instead, and remember which one the visitor chose.

Spelling and currency details people notice

• Use local spelling throughout each version, including product names you control and button labels.
• Show prices in local currency with the right symbol and format.
• Swap dates to the local format (11/02 means different days in the US and UK).
• Use local phone numbers with country codes in the right format.
• Adjust units where it matters (inches vs centimeters).

FAQ

Will hreflang make my UK pages rank in the UK?

It helps Google show the right version to the right searcher. It doesn't make a page rank by itself; the page still has to deserve it.

Can I just use one page and let Google figure it out?

Google says it may find alternate versions on its own, but recommends telling it explicitly. With one shared page, there's nothing to signal.

Does Google use the html lang attribute to detect language?

No. Google's documentation says it doesn't use hreflang or the lang attribute to detect a page's language; it uses its own algorithms.

Should Canada and New Zealand get their own pages too?

Only if something real differs. Otherwise let x-default or the generic en page serve them.

Weighing regional English pages against one well-built international site? Describe your markets and we'll sketch the structure.

Sources

• https://developers.google.com/search/docs/specialty/international/localized-versions
• https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites