hreflang for UK and US English sites

I keep this site in British English on a single URL, so I do not ship hreflang here, but I have to get the same UK and US split right in app store copy, which is why the guide to localising iOS apps for UK English exists. The method below is the website version of that discipline: only create a second page when the difference is real, then annotate it accurately.

When two English versions are actually two pages

Create two URLs when a person in the UK and a person in the US should not be shown the same document. Typical, genuine differences:

• Currency, tax display and shipping. A price in pounds with VAT included is not a price in dollars.
• Legal and policy copy: consumer rights, returns, privacy wording, and company details.
• The offer itself: a product you only ship to one country, a service you only provide in one market, a support phone number that only works in one.
• Substantial wording differences that go with those facts, including spelling, dates and units, once the underlying content already differs.

A language switcher that changes “colour” to “color” and leaves the same £ price on the page is not a second version. Neither is a JavaScript geo overlay that does not have its own crawlable URL. hreflang annotates URLs. If there is only one URL, there is nothing to annotate.

If you are unsure, write the one-line job of each page, the same way you would when checking keyword cannibalisation. If both pages would satisfy the same query for the same person, merge them. If a UK searcher should see one and a US searcher the other, you have a cluster.

en, en-GB, en-US and x-default

The codes are a language, optionally plus a region. Google documents them in its localised versions guide. The details that matter for a UK and US English pair:

• en-GB is English as used in the United Kingdom. The region code is GB, not UK. en-UK is a common mistake and is not a valid combination you should ship.
• en-US is English as used in the United States.
• en is English with no region. It is useful if you also have a generic English page, but it is not a substitute for en-GB and en-US when those pages are meant for those countries.
• x-default is the fallback for people whose language or region you have not named. It often points at a country chooser, or at the version you are willing to show the rest of the world. For a UK-first business that also maintains a US page, x-default might be the UK page, or a neutral chooser, but it should be a conscious choice, not a missing tag.

Every page in the cluster should list all of the alternates, including itself. Google recommends that self-referencing annotation. A UK page that only points at the US page, and never at itself, is incomplete.

An HTML sketch for a pair plus a default:

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

Those three tags belong on both URLs, with the same absolute HTTPS addresses, which must be the canonical addresses of the two pages. The hreflang Generator will shape the tags; you still have to choose the default and the real URLs.

Return tags, clustering and a single host versus two

A cluster only works if it is reciprocal. If the UK page points at the US page, the US page must point back at the UK page, with the same URLs. A broken return is one of the main reasons hreflang is ignored. The hreflang Cluster Validator is built to catch that, along with codes that look plausible and are wrong.

You can host the pair in several ways:

• Paths on one host, such as example.com/uk/ and example.com/us/. This is usually the least ceremony for a small site, if the rest of the URL after the locale prefix otherwise matches.
• Subdomains, such as uk.example.com and us.example.com.
• Separate domains, such as example.co.uk and example.com. This is common for older UK businesses, and it works, but both hosts must stay in the same cluster, with absolute links, and both must be verified where you use Search Console.

Pick one pattern and keep the slugs aligned where you can. A slug generator is only a naming aid; the important part is that /uk/pricing and /us/pricing really are the same document in two regional versions, not two unrelated pages that happen to share a word.

Query parameters (?region=us) can work if they are the stable, indexable URLs you annotate, but they collide easily with tracking parameters and with canonical tags. I would not choose them for a new site.

The canonical on each page should be itself, not the “main” language. hreflang says “these are alternates”. A canonical that points the UK page at the US page says “the UK page is a duplicate”. Search engines will not be able to honour both stories. The canonical tags guide is the place for that mechanism; here, just do not mix them up.

Currency, spelling and legal copy that really differs

The content has to justify the cluster.

Currency and tax should be written as they will be charged, not converted approximately in a footnote. If you show pounds inclusive of VAT on the UK page, the US page should show the US offer as you actually sell it. Do not put both prices on both URLs “just in case” and then expect hreflang to choose; you have made two mixed pages.

Spelling and units should follow the region once you have two pages: colour, organise, 12 November, metres and postcodes on en-GB; color, organize, November 12, meters and ZIP codes on en-US. This is the same editorial care as localising an iOS app into UK English. Spelling alone, though, is a weak reason to maintain two full copies. If nothing else differs, keep one page in the English you actually use, and say so.

Legal copy is often the real reason for a split. Refund rights, company numbers, privacy contacts and consumer terms can differ, and they should not be lightly copied across. I am not giving legal advice here; I am saying that if those pages differ, they are good hreflang candidates, and if you cannot maintain the difference, you should not pretend you have two regional products. That maintenance has a cost, in the same way what an iOS app really costs includes the localisation you plan to keep current, not only the first screenshot.

Contact details, opening hours and shipping promises belong to the region they describe. A “call us on this UK number” block should not be the leading contact method on the US page.

Implementation in HTML, headers or a sitemap

Google accepts three equivalent places for the annotations. Use one as the source of truth, not two that can drift.

1. HTML <link rel="alternate"> tags in the head of each page, as in the sketch above. This is the usual choice for a small site, and it is easy to see in the first response. The tags must be in the raw HTML, not only injected after JavaScript, if you want a crawler that does not render to see them.
2. HTTP headers on each response: http Link: <https://example.com/uk/pricing>; rel="alternate"; hreflang="en-GB", <https://example.com/us/pricing>; rel="alternate"; hreflang="en-US", <https://example.com/uk/pricing>; rel="alternate"; hreflang="x-default" This is useful for PDFs or other non-HTML files, and for an edge worker that already controls headers. It is harder to inspect at a glance than the HTML tags.
3. A sitemap with xhtml:link alternates on each URL. This scales when you have many pairs, as long as the sitemap is generated from the same list as the pages. Do not hand-edit a second list.

Whichever you choose, generate the annotations from a single table of pairs, the same way you would generate a consistent release artefact in the App Store launch process. A typo in one direction is a broken cluster.

The mistakes that make both URLs compete

These are the failures I look for first:

• en-UK or other invented codes. Use en-GB.
• Missing return tags, or one side still pointing at an old path after a rename.
• Annotations that point at redirects, 404s, or noindex URLs. Point at the final, indexable canonical of each version.
• Canonicals that all lead to one country, which tells search engines the others are duplicates.
• Identical pages on two URLs, hoping hreflang will sort out a problem you created by publishing a copy.
• A country selector that is the only way to reach the other version, with no crawlable link and no annotation.
• Mixed clusters, where the UK pricing page points at the US home page, or at a generic /en/ that is not its counterpart.
• Relative URLs in hreflang. Use absolute HTTPS URLs on the canonical host.

When these go wrong, both URLs can appear in the same country, or the wrong one can appear, which is the competition hreflang was meant to prevent. Search Console’s international report, where it is available, and a cluster validator are more useful than eyeballing a single page.

How to test a cluster

A practical test, after each change to the pair:

1. List every URL that should be in the cluster, including x-default if it is a distinct page.
2. Fetch each one logged out, follow redirects, and record the final URL, status, canonical, and the hreflang tags or headers.
3. Run the set through the hreflang Cluster Validator. Every member should mention every other member, including itself, with matching absolute URLs and valid codes.
4. Confirm that a person can reach the other version through a visible, ordinary link, not only through an automatic redirect that a crawler might not choose to treat as an alternate.
5. After launch, search for a distinctive phrase on the UK page and on the US page, or use Search Console, and see which URL is shown in which region when you have data. Do not expect an overnight swap, and do not treat a single anecdotal result as proof.

If both versions go live together, add the cluster to the technical SEO launch checklist. Fix errors in the generator, not by editing one live page and leaving the other.

When hreflang is more trouble than it is worth

Skip the cluster, or delay it, when:

• You only have one English site, written in the English you use, and you ship worldwide from that site with a clear currency and a clear legal entity. That is a legitimate choice, and it is the one I have made on this site.
• The second version would be a thin copy you cannot keep updated. A stale US page with last year’s prices is worse than a single honest UK page.
• You cannot guarantee reciprocal tags, because the two sites are owned by different systems that do not share a URL list.
• The “US version” is only a currency switcher on the same URL. Fix the offer display if you need to, but do not invent a second path for it.

hreflang is careful bookkeeping for real alternatives. It is not a way to get twice the English coverage from one article, and it is not required for a single-language site to rank in another country.

Key takeaways

• Use hreflang for UK and US English only when the two URLs are genuinely different regional documents, not when they differ by a spelling.
• Annotate with en-GB and en-US (never en-UK), include a self-reference, add a deliberate x-default, and make the tags reciprocal.
• Keep each page canonical to itself. Point annotations only at final, indexable URLs, generated from one list, in HTML, headers or a sitemap.
• Let currency, tax, legal copy and the offer justify the split, and keep the wording consistent with each region.
• Validate the cluster after every rename, and do not start a second version you cannot maintain.

If you want a second pair of eyes on a UK and US pair that still compete in the same results, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.