Multi-language sites: hreflang and the mistakes that break it

Hreflang tags tell search engines which language and regional version of a page to show a given searcher, and they're conceptually simple: point each language version at every other language version, including itself. In practice, they're one of the most commonly broken pieces of technical SEO we find on multi-language sites, usually from a small implementation mistake that quietly undermines the entire setup.

The gap between how simple hreflang sounds and how often it's broken in practice comes down to one thing: the tags are invisible in normal browsing. A page can look completely correct to a human visitor while the underlying hreflang relationships are silently broken, and nobody notices until an SEO audit or a drop in international traffic prompts someone to actually check the markup directly.

A common mistake is a page listing hreflang tags for every other language version but omitting a self-referencing tag for its own language. Google's guidelines are explicit that self-reference is required, and omitting it can cause the whole hreflang cluster for that page to be ignored, silently reverting to default language detection.

We see this specific mistake most often on sites where hreflang was implemented manually, page by page, rather than generated programmatically from a single language-mapping source. A manual process is exactly where a repetitive, easy-to-forget requirement like self-referencing tags tends to get dropped, especially once a site has more than a handful of language versions to keep track of.

If your English page points to a French page via hreflang, the French page needs to point back to the English page. A missing or mismatched return tag on either side invalidates the relationship for search engines, and this kind of asymmetry is surprisingly common on sites where language versions were added at different times by different people.

We've found this most often on sites that added a new language months or years after the original site launched, where whoever built the new language version didn't go back and update the existing pages' hreflang tags to include the new addition. The new page points correctly to the old ones, but the old ones never learned the new page exists, which breaks the required symmetry for every page involved.

`en` covers English broadly; `en-GB` and `en-US` are only worth specifying separately if content genuinely differs by region (currency, spelling, region-specific offers). Over-specifying regional variants when the content is identical just adds maintenance surface area without any real targeting benefit, and it's a common case of implementing a feature more granularly than the actual content justifies.

We ask a simple question before recommending regional variants: does a searcher in one region actually see different content, pricing, or offers than a searcher in another region speaking the same language. If the answer is no, a single broad language code serves everyone correctly with far less ongoing markup to maintain, and regional variants only get added once there's a genuine, content-level reason for them.

Because hreflang errors are invisible in normal browsing, we validate every multi-language site with a dedicated crawler that checks the full return-tag relationship across every page pair, rather than relying on a manual spot check of a handful of pages. Running this validation as a standing part of technical SEO monitoring, not just at initial launch, is what catches new errors introduced as a site's language versions continue to grow and change over time.

We run this validation on a monthly schedule for any active multi-language client, treating it with the same routine seriousness as a broken-link check or a Core Web Vitals review, rather than as a one-time launch task. Multi-language sites accumulate hreflang errors gradually, page by page, as new content gets added, and a monthly check catches each new error while it's still isolated rather than letting a whole quarter's worth of new content ship with a broken relationship nobody noticed.

For sites with a large number of language and regional variants, implementing hreflang through an XML sitemap rather than inline HTML tags on every page can be meaningfully easier to maintain correctly, since it centralizes all the relationships in one generated file rather than requiring every individual page template to render the full correct set of tags. We recommend this approach specifically once a site passes a certain complexity threshold, generally more than three or four language variants, where the inline approach starts becoming genuinely difficult to keep consistent by hand.

Search Console's international targeting report shows exactly how Google is interpreting a site's hreflang relationships, including specific errors like missing return tags, flagged directly by page. We check this report as a standard step after any multi-language launch or major update, since it's the most direct confirmation available that the implementation is actually being read correctly, rather than relying purely on our own crawler's interpretation of what the markup should mean, and the two occasionally disagree in ways worth investigating further.

For a business genuinely serving multiple language markets, correctly working hreflang can be the difference between a French searcher landing on the English homepage and bouncing immediately, versus landing directly on the French version built for them. We've seen organic conversion rates from non-English markets improve meaningfully after fixing a broken hreflang setup, purely because searchers were finally being routed to the version of the site that actually matched their language, without any new content or design work involved at all.

That result tends to surprise clients more than any other technical SEO fix we make, precisely because nothing about the site's visible content or design changed. It's a useful example to keep in reserve for any client skeptical that technical SEO work is worth the invoice, since it demonstrates concretely that markup nobody ever sees can still move real revenue when it's routing the right visitor to the right page.