hreflang, and the four ways it usually breaks
hreflang tells search engines which language or regional version of a page to show which user. It is unusually unforgiving: a cluster with one missing return link, one wrong code or one non-canonical URL is not partially working — it is ignored, and the fallback is whatever the engine guesses.
Part ofTechnical SEO Engineering
International SEO has one hard technical component and a lot of ordinary content work. The hard component is hreflang, and it fails quietly — there is no error page, no ranking penalty, just the wrong version shown to the wrong audience while everything appears configured.
Decide the URL structure first
hreflang annotates a structure; it cannot rescue a bad one. Three options are viable, and the choice is mostly about resources rather than search performance.
For most organisations the subdirectory is correct. It concentrates authority on one domain, it is the cheapest to maintain, and the geo-targeting loss relative to a country domain is smaller than the cost of building authority in several places at once.
Language, country, or both
This is where most implementations go wrong conceptually before any code is written. The hreflang value can specify a language, or a language and a region — and they mean different things.
en— English speakers anywhere. Correct when you have one English version for everyone.en-GB— English speakers in the United Kingdom. Correct only when content genuinely differs by country.en-IN— English speakers in India. Same rule: use it when pricing, availability or legal content actually differs.- A region code alone, such as
IN, is invalid. The language subtag is mandatory.
The four ways it breaks
Search Console's International Targeting report surfaces most of these, but understanding the mechanism is what stops them recurring.
- Missing return links. hreflang must be reciprocal. If the English page lists the Hindi page, the Hindi page must list the English one. A one-way declaration is discarded entirely — this is by far the most common failure.
- Not self-referencing. Every page in a cluster must include an hreflang entry pointing at itself. Omitting it is treated as a malformed cluster.
- Pointing at non-canonical URLs. hreflang must reference the canonical URL of each alternate. Pointing at a URL that canonicals elsewhere sends contradictory instructions and the annotation is ignored.
- Invalid or invented codes. Language codes are ISO 639-1, region codes are ISO 3166-1 alpha-2.
en-UKis wrong — the country code isGB. So is any made-up combination.
Notice that both pages carry an identical hreflang block. That is the correct pattern, and it is why generating these tags from one shared source of truth — rather than hand-authoring them per template — is the only implementation that stays correct as pages are added.
x-default, and what it is for
x-default nominates the page to serve when no other version matches the user's language or region. It is not "the English one" by definition — it is the fallback, which is often a language selector or the most broadly applicable version.
It is optional but worth including. Without it, a user whose language matches nothing in your cluster gets whichever version the engine considers closest, which may be a language they cannot read.
Head tags, sitemap, or headers
What hreflang does not do
It is a targeting hint, not a ranking factor and not a duplicate-content solution. Three common misconceptions are worth correcting directly.
- It does not make translated pages rank better — it decides which existing version is shown to whom
- It does not consolidate ranking signals the way a canonical does; each version ranks on its own merits
- It does not substitute for genuine localisation — machine-translated pages with correct hreflang are still thin content
That last point is where international SEO projects actually succeed or fail. The annotation is a day's engineering. Content that is genuinely useful in each target market is the real work, and no amount of correct markup compensates for its absence.
Verifying it works
- Fetch each page in the cluster and confirm the hreflang block is identical and complete across all of them.
- Confirm every URL referenced is the canonical for that version and returns 200 — not a redirect.
- Validate every language and region code against ISO 639-1 and ISO 3166-1.
- Check Search Console's International Targeting report for "no return tags" errors after recrawl.
- Add an automated test asserting reciprocity, since this breaks whenever someone adds a locale.
Questions
Do I need hreflang if all my pages are in English?
Only if you have separate pages for different English-speaking markets with genuinely different content — different pricing, availability or legal terms. If there is one English page for everyone, hreflang adds nothing. Creating country variants of identical content makes the situation worse, not better.
Should I use subdirectories or country-code domains?
Subdirectories for most organisations. Authority concentrates on one domain, operations are simpler, and the geo-targeting advantage of a country-code domain rarely offsets having to build authority separately for each one. Country domains make sense when a market needs genuine legal or brand separation.
What is the most common hreflang mistake?
Missing return links. hreflang has to be reciprocal — if page A declares page B as an alternate, page B must declare page A. A one-directional annotation is discarded entirely rather than partially honoured, which is why the failure is so easy to miss: everything looks configured and nothing is working.
Does hreflang fix duplicate content across country versions?
No. hreflang tells engines which version to show which user; it does not consolidate ranking signals the way a canonical tag does. Near-identical pages across several country variants still compete with one another. If the content does not genuinely differ, the correct fix is fewer pages, not more annotation.