International SEO Basics: Hreflang Without the Headaches

International SEO Basics: Hreflang Without the Headaches

ByAdam


Targeting multiple countries or languages? Learn how hreflang works, the mistakes that cause wrong-region rankings, and how to implement it cleanly.

If your site targets users in multiple countries or languages, hreflang tells Google which version of a page to serve to which audience. Without it, Google has to guess — and it often gets it wrong, showing the English version to Spanish-speaking users, or the US pricing page to UK shoppers. Hreflang solves this, but it’s one of the most commonly misimplemented technical SEO signals, and the mistakes compound: incorrect implementation can confuse Google more than no implementation at all.

This guide covers the basics cleanly — what hreflang does, how to implement it, and the errors that most often cause it to fail.

The Short Version

  • Hreflang signals which regional/language version to serve — it doesn’t control indexing or rankings, only which version appears for which audience.
  • Annotations must be fully reciprocal — every page in the set must reference every other page, plus itself, or Google may ignore the whole cluster.
  • Non-reciprocal annotations are the single most common cause of hreflang failure — always validate with Search Console’s International Targeting report.
  • Subdirectories are generally the easiest URL structure to manage for international SEO, sharing one domain’s authority across all regions.

What hreflang does (and doesn’t do)

Hreflang annotations tell Google: “For users searching in [language/region], show [this URL].” A page targeting UK English and US English would have annotations pointing to the UK URL for en-gb and the US URL for en-us. Google then uses this signal — along with user location and language settings — to serve the appropriate version in search results.

What hreflang doesn’t do: it doesn’t prevent pages from being indexed. Both the UK and US versions will be indexed; hreflang only influences which one appears for which regional audience. It also doesn’t affect rankings for keywords — it’s purely a regional targeting signal, not a content quality or authority signal.

The hreflang tag format

Hreflang is implemented either in the <head> of each page, in HTTP headers, or in the XML sitemap. The <head> method is most common and easiest to manage for WordPress and CMS sites:

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

The x-default tag designates the fallback URL for users who don’t match any of the specific language/region targets. This is typically the default or global version of the page.

Language codes follow ISO 639-1 (two letters: en, fr, de). Region codes follow ISO 3166-1 Alpha-2 (two letters: GB, US, AU). You can target language only (en), region only (not supported — must have a language), or language + region (en-gb).

The reciprocal link requirement

The most common implementation mistake: hreflang annotations must be reciprocal. If the UK page lists the US page as its US alternate, the US page must also list the UK page as its UK alternate — and both must reference themselves with a self-referential hreflang tag. If any page in the set doesn’t reciprocate, Google may ignore all the annotations in that cluster.

A complete, valid set for two English versions looks like this on the UK page:

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

And the same three tags must appear on the US page and the default page, with all three URLs referenced in each set. For sites with many regional versions, this creates a large number of hreflang tags — a page targeting 10 regions needs 10 + 1 (x-default) hreflang tags, all reciprocated. Sitemap-based implementation is often more manageable at scale.

Common hreflang errors

ErrorWhy it breaks the implementation
Missing x-defaultUsers who don’t match any specific target have no designated fallback version
Non-reciprocal annotationsThe most frequent cause of failure — the annotation set is incomplete on one or more pages in the group
Hreflang pointing to redirecting URLsAll URLs in hreflang annotations must return 200 — a redirect breaks the implementation for that region
Wrong language or region codesCase mismatches (EN vs en) or country names instead of ISO codes invalidate the annotation
Hreflang on noindexed pagesHreflang only works on indexable pages — pointing to a noindexed URL produces no benefit

Validate your implementation with Google Search Console (International Targeting report under Legacy Tools) or use the hreflang checker at ahrefs.com/hreflang-checker or hreflang.net to catch reciprocity and code errors. For the full technical audit framework, see the SEO audit checklist.

Choosing a URL structure for international targeting

Three structures, one tradeoff

ccTLD
example.co.uk
Strongest regional signal, but each domain builds authority separately from scratch.
Subdomain
uk.example.com
More manageable than ccTLDs but still treated as a largely separate authority signal.
Subdirectory
example.com/uk/
Shares the root domain’s authority — generally easiest to manage with a single CMS.

A worked example: three regions, one broken reciprocal set

A subscription business targeting the UK, US, and Australia in English added a new Australian subdirectory (/au/) alongside its existing UK and US versions. The team added a full, correct hreflang set to the new /au/ pages — referencing UK, US, and itself — but didn’t go back and update the existing UK and US pages to add the new Australian alternate. Search Console’s International Targeting report flagged this almost immediately as a reciprocity error, and the Australian pages weren’t appearing for Australian searches despite having seemingly complete markup.

The fix required updating both the UK and US page templates to add the missing en-au alternate tag, completing the three-way reciprocal set across all pages rather than just the newest one. Within roughly two weeks of Google re-crawling all three regional versions, the International Targeting report showed “Confirmed” status, and Australian search queries began returning the /au/ version rather than defaulting to the UK or US page. The broader lesson: any change to a hreflang cluster — adding, removing, or renaming a regional URL — requires updating every other page in that cluster, not just the one that changed.

Frequently asked questions

Yes — hreflang is useful when targeting multiple regions even in the same language. English content targeting the UK, US, and Australia can use en-gb, en-us, and en-au to ensure Google serves the regional version with local pricing, spelling, or references to the appropriate audience. If the content is truly identical with no regional differentiation, hreflang provides less value — but if the pages differ (pricing, currency, local references, regional terms), hreflang prevents the wrong version from appearing in the wrong market’s search results.

Three common URL structures for international sites: country-code TLDs (example.co.uk, example.fr) send the strongest regional signal but require separate domain authority building for each country. Subdomains (uk.example.com, fr.example.com) are more manageable but still require separate authority signals. Subdirectories (example.com/uk/, example.com/fr/) share the root domain’s authority and are easiest to manage with a single CMS. Google has said all three approaches can work for international targeting, but subdirectories are generally easiest from an SEO management perspective — one domain to build authority, one Search Console property to monitor (though you can add regional properties for reporting).

The most direct check: search for a target keyword on Google.co.uk (with a UK VPN or Google’s region-specific search) and verify the UK version of your page appears rather than the US or global version. Also check Search Console — under Legacy Tools → International Targeting → Language. This shows detected hreflang tags and any errors in the implementation. A “Confirmation” status means Google has confirmed the annotations are valid and reciprocal. An “Error” status means something in the annotation set is incorrect. Fix errors in the order they’re reported — broken reciprocity is typically the root cause of most hreflang errors.

Hreflang is agnostic about how the content was created — it just signals regional targeting. AI-generated translations can work for international SEO if the quality is sufficient (human review is strongly recommended, particularly for fluency and local idiom). The risk with low-quality machine translation isn’t hreflang — it’s content quality. A page that reads like unedited machine translation may be indexed but rank poorly because it fails quality signals. Use AI translation as a starting point with human editing for the target market, and hreflang to ensure the right version reaches the right audience.

Google will still index all your regional or language versions and will attempt to serve the most relevant one based on the searcher’s location and language settings, plus content signals like on-page language and local references. Without hreflang, this guess is frequently wrong — UK searchers seeing US pricing, or French speakers landing on the English version. For sites with only minor regional differences (e.g., currency symbol only) this risk may be tolerable; for sites with materially different content, pricing, or legal terms per region, the wrong version showing up is a real conversion and trust problem worth the implementation effort to prevent.

The hreflang output requirement is identical either way — what differs is how you generate it. WordPress multisite setups and dedicated multilingual plugins (WPML, Polylang) generate and maintain reciprocal hreflang sets automatically as you link translated content together, which removes most of the manual reciprocity risk. A single installation managing regional content without a dedicated plugin requires more manual care to keep every page’s annotation set complete and in sync as pages are added, renamed, or removed. For sites with more than two or three regions, a dedicated multilingual plugin is usually worth it just for the automated reciprocity handling.

International SEO without chaos

Hreflang is worth implementing correctly once and maintaining. The alternative — Google choosing which regional version to rank for which audience without guidance — typically means inconsistent results that are hard to diagnose and fix. A clean implementation with reciprocal annotations and valid URLs is straightforward to maintain in a CMS and largely automatic once set up correctly.

If you’re planning a multilingual or multi-region site and want the technical implementation reviewed before you build, get in touch.

Similar Posts