hreflang for UK and Ireland: A Practical Implementation Guide

What hreflang is, and what it is not

hreflang is an annotation on a page that tells Google which language and regional version of that page exists, and where it lives. It is the machine-readable answer to the question a visitor answers with a flag icon: this is the British version, that is the Irish version.

It is a hint. Google is not obliged to act on it, and it will not force a version on a user. It is also not a ranking factor: an annotation will not lift a page above a better competitor. It does not redirect anyone, it does not consolidate signals the way a canonical does, and it does not fix duplicate content. It changes who is shown which version, and nothing else.

One change in the platform makes this more important than it used to be. Google retired the International Targeting tool in Search Console in September 2022, stating that country targeting "was determined to have little value for the ecosystem". There is no longer a country setting to point at the UK. hreflang is the primary lever, and it is a lever you have to pull correctly because it fails silently.

en, en-GB, en-IE — and why en-UK is invalid

An hreflang value has two parts. The first is an ISO 639-1 language code. The optional second part, after a hyphen, is an ISO 3166-1 Alpha-2 country code. Both parts have to come from those lists, because those are the lists Google matches against.

• en — English, with no regional variant. Use it when you have one English page serving every market, or as the fallback for English speakers whose region you do not serve separately.
• en-GB — English for the United Kingdom. GB is the ISO 3166-1 code for the United Kingdom.
• en-IE — English for Ireland. IE is the ISO 3166-1 code for Ireland. It is not the same thing as ga, which is the Irish language.
• en-UK — invalid, and invalid in a way that does nothing visible. UK is a common two-letter abbreviation, but it is not an ISO 3166-1 country code. The code for the United Kingdom is GB. Google does not return an error for an unrecognised value; it treats the annotation as unusable. The same applies to en-EU, because the European Union is not a country.

This is the single most common error in UK-facing international setups, and it is invisible. The tag is present, the page loads, and no report anywhere says the value was rejected.

Is en-IE actually worth it?

Sometimes, and less often than agencies suggest. Ireland is an English-speaking market, so an en-IE annotation earns its place only when the Irish page is materially different from the UK page. Differences that justify it: prices shown in euro, Irish delivery or service terms, an Irish business address or phone number, Irish regulatory and tax wording, and Irish opening hours or support commitments.

If your Irish version is the UK page with a paragraph swapped, do not build it. Two near-identical pages carrying an en-GB and an en-IE annotation create a near-duplicate pair you now have to maintain in two places forever, for a market a fraction of the size of the UK. One English page annotated en that serves both markets is usually the better decision, and it is the honest one.

The test is simple: if a customer in Dublin and a customer in Manchester would see exactly the same page and be equally well served, you have no Irish version. You have a UK version and a Dublin visitor.

The two rules people break most often

Self-reference

Every page in a cluster must include an annotation pointing at itself, alongside the annotations pointing at its alternates. This looks redundant and is not: it is how Google confirms that the page knows it belongs to the cluster. A page that lists three alternates but not itself is not in the cluster it appears to advertise.

Reciprocity

If the UK page points at the Irish page, the Irish page must point back at the UK page. One-directional pairs are ignored. Google treats the confirmation as required rather than optional, and a missing return tag voids the pair.

The consequence is silence

Conflicting or non-reciprocal annotations are not reported as errors. The pair is simply dropped, no warning appears in Search Console, and Google falls back to its own language detection. You have written a careful matrix, deployed it, verified the tags render in the page source, and it is doing nothing. This is the failure mode to design your verification around, because the implementation looks correct from every angle except the one that matters.

What x-default is actually for

x-default marks the page to serve to a user whose language and region match none of your annotations. It is the catch-all, not the English version by default and not the home page by default, although in practice it is often one of those.

Use it when you have a genuine fallback: a global English page, or a language-selection page, that serves an unmatched visitor well. Include it once per cluster, and list it as an alternate on every page in that cluster, exactly like any other value. If every visitor you care about is already covered by a real annotation, or if your only sensible fallback is a page that would confuse a Spanish speaker looking for Spanish content, skip x-default entirely. A wrong x-default is worse than none.

What a broken implementation actually looks like

This is not theoretical for us. Our engineers were asked to diagnose and repair the hreflang on a live multilingual site, and the deployment failed in three separate ways at once. Every French page advertised the homepage as its French alternate, so each pair contradicted another pair and Google discarded the conflicting set. Other pairs were one-directional: the French page pointed at the English page and nothing pointed back. And a number of targets pointed at URLs that returned 404.

Every one of those annotations was present in the page source and looked correct to a spot check. The only way we found them was by extracting every annotation from the deployed HTML, building the graph of edges, and testing each one against the live URLs. That is the process below, and it is the process we would run on any site before believing its hreflang works.

How to verify an implementation

• 1. Extract every annotation, not a sample. Crawl the site and record, for each URL, the full set of hreflang values and targets it declares, plus which method declared them. This is a crawl report or a short script; it is not a browser spot check.
• 2. Test the graph, not the page. Build the edges from each source URL to each target and assert three things: every URL references itself, every edge has a matching return edge, and no value uses a code that is not on the ISO lists.
• 3. Resolve every target. Request each unique hreflang target directly and confirm a 200 with no redirect. Report the ones that chain, and the ones that fail.
• 4. Diff the placement methods. If you use a head block and a sitemap, parse both and compare them set by set. Anything that appears in one and not the other is a discrepancy you are currently serving.
• 5. Check the content matches the code. An en-GB annotation should sit on a page priced in pounds with UK terms and a UK service description. If the target is a translated global page with no regional difference, the annotation is decorative.
• 6. Re-run after every release. hreflang breaks when templates change and when locales are added, which is exactly when nobody is looking at it. Put the check in the release process rather than in an annual audit.

There is no Search Console report that will flag a dropped pair for you, which is why this is a build-time check rather than a dashboard. The closest thing to ongoing confirmation is watching which regional URL actually receives impressions for the market you intended. hreflang decides which version is served; it does nothing about how fast that version arrives, so if your TTFB is the real bottleneck that is an infrastructure question, not an annotation question.

Frequently asked questions about hreflang

Is en-UK accepted by Google?

No. UK is not an ISO 3166-1 country code, so the value cannot be matched and the annotation is discarded. Use en-GB. The same reasoning rules out en-EU and any other invented region token.

Will hreflang improve my rankings?

No. It is a hint about which version to serve, not a ranking factor. Done correctly it can improve click-through and conversion for visitors who land on the right version, and it can stop two regional URLs from competing for the same query. It will not outrank a better page.

My site is English-only. Do I need hreflang at all?

Usually not. If one English page serves every English-speaking market, there is nothing to annotate and no cluster to build. You need it when you maintain separate regional versions with different prices, currencies, terms or legal wording, which is the point at which the versions genuinely diverge.

Can I use hreflang and canonical tags together?

Yes, and on a correctly built multilingual site you normally should. They answer different questions: the canonical says which URL is the definitive one for a piece of content, and hreflang says which language and regional alternates of that content exist. The canonical must be self-referencing on a genuinely localised page, or the localised version will never be indexed.

How long does it take to work?

There is no switch. Google has to recrawl the pages, see the corrected annotations and re-evaluate the cluster, which usually takes weeks and varies with crawl rate. Treat it as a fix that removes an obstacle rather than one that produces a same-week result.

Does a .ma domain stop me ranking in the UK?

The country-code domain carries a standing Morocco association that cannot be switched off, and the old Search Console country-targeting setting no longer exists. That is an obstacle, not a prohibition: on task-specific and pricing queries, content relevance does the work. hreflang cannot override a ccTLD signal either, so do not expect it to.