The hreflang attribute tells Google which language or regional version of a page to show a given searcher. Implemented badly, it almost never triggers a visible error: pages keep getting indexed, the site keeps working, which is exactly what makes the problem hard to spot. The real symptoms, lost traffic on one language version, the wrong page surfacing in results, often only show up weeks after a multilingual site goes live.
What hreflang actually does, and what it doesn’t
hreflang translates nothing and redirects no one automatically. It simply declares relationships between URLs: “this French page has an English equivalent at this address, a Spanish equivalent at that one.” Google then uses that information to decide which URL to surface based on a searcher’s language and location. Without hreflang, a multilingual site stays indexable, but Google has to guess the right version to show, and gets it wrong more often than people assume on high-traffic international pages.
The most common mistakes
Most hreflang issues found on production sites come down to a handful of recurring causes.
| Error | Observed symptom | Typical cause | Fix |
|---|---|---|---|
| Non-reciprocal tags | Search Console reports a “return tag error” | Page B points to A, but A doesn’t point back to B | Generate tags in pairs, never by hand page by page |
| Invalid language code | Google silently ignores the tag | Using a malformed country code alone (“fr-FR” done wrong) or a made-up code | Follow ISO 639-1 for language, ISO 3166-1 for region, in that order |
| Missing x-default | Wrong version served to searchers outside the covered languages | No fallback page declared | Add an hreflang="x-default" tag pointing to the generic version or language picker |
| Non-canonical URLs in hreflang | Conflict between canonical and hreflang tags | hreflang URLs point to parameterized or non-canonical versions | Only use exact canonical URLs, as indexed |
| Mismatch between sitemap and HTML tags | Some pages handled correctly, others not, with no clear pattern | The two mechanisms declare different relationships | Pick a single implementation method per site, never both at once |
Google silently ignores mismatched hreflang tags, with no visible error in Search Console for weeks.
Auditing an existing site
Search Console’s “International Targeting” report remains the most reliable starting point: it lists return-tag errors found on a sample of pages. It doesn’t cover the entire site, though, and its update lag can exceed a week. For a full audit, a technical crawl (Screaming Frog, Sitebulb, or an in-house script) is still necessary: it checks, URL by URL, that every hreflang relationship is genuinely reciprocal and that language codes are valid.
This detection lag ties into a broader monitoring problem: without a regular dashboard cross-referencing indexing and performance by language, an hreflang error can stay invisible for months. Setting up a GA4 and Search Console dashboard segmented by language makes it easier to spot a localized traffic drop on a single language version, a frequent sign of an hreflang issue rather than a general visibility decline.
Implementing hreflang correctly
Two methods coexist: <link> tags in each page’s <head>, or a declaration in the XML sitemap. The latter is preferable on large sites, since it avoids bloating every page and centralizes the relationships in a single file to maintain.
<!-- In the head of the English page -->
<link rel="alternate" hreflang="en" href="https://example.com/en/hreflang-guide/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/guide-hreflang/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/guia-hreflang/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/hreflang-leitfaden/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
<!-- Equivalent declaration in the XML sitemap -->
<url>
<loc>https://example.com/en/hreflang-guide/</loc>
<xhtml:link rel="alternate" hreflang="fr"
href="https://example.com/fr/guide-hreflang/" />
<xhtml:link rel="alternate" hreflang="es"
href="https://example.com/es/guia-hreflang/" />
<xhtml:link rel="alternate" hreflang="x-default"
href="https://example.com/" />
</url>
Outside Search Console: other control tools
Search Console alone isn’t enough for regular monitoring, given its sampling scope and processing delay. Three kinds of tools cover most of what a technical team needs. A standard SEO crawler (Screaming Frog, Sitebulb) has a dedicated tab that automatically lists non-reciprocal hreflang tags, invalid language codes, and pages missing a self-reference, across the whole site rather than a sample. For sites publishing several times a day, a check script run in continuous integration catches regressions before they ship, rather than weeks later via Search Console. Finally, Merkle’s hreflang testing tool (technicalseo.com) remains a reference for manually checking a handful of URLs without running a full crawl.
A common scenario: adding a language after launch
Most hreflang errors found in audits don’t appear at a multilingual site’s launch, but when a language is added to a site that already had two or three. The pattern repeats: a team adds German to a French-English-Spanish site, but the script or configuration generating hreflang tags was only ever built for three languages. The new German pages exist and get indexed, but appear in no existing page’s hreflang tags, and their own tags point to URLs that don’t reference them back. The result is a return-tag error across every new page, invisible until someone runs a full audit again.
The fix is less about tooling than process: treat any language addition as a data-schema change rather than an isolated content addition, and systematically re-run a full site crawl afterward, not just on the new pages.
The case of multilingual CMS platforms
On WordPress, multilingual plugins (Polylang, WPML) generally generate hreflang tags automatically from linked translations in the database, which avoids most manual errors. The risk shifts to configuration instead: an untranslated section or category can break the link chain, and republishing a post in a default language without going through the theme’s translation mechanism often produces an orphan page with no hreflang tag pointing to it at all. Choosing a CMS and its multilingual architecture is worth settling early in a project; the CMS selection guide covers what to weigh before layering a translation system onto an existing site.
Key takeaways
hreflang doesn’t forgive sloppiness: an orphaned tag or a malformed language code breaks nothing visibly, but silently denies part of an international audience the right version of a site. A regular audit, a single implementation method per site (HTML or sitemap, not both), and systematic self-referencing cover most cases seen in production.
In nearly every multilingual audit that lands on my desk, the problem is never a lack of intent, it’s an oversight at the moment a fifth language gets added to a site that started with two. The tag-generation script wasn’t updated, and nobody notices until traffic drops on the new version. My rule of thumb: treat hreflang as code, with an automated test checking tag reciprocity on every deploy, rather than as a checkbox in a plugin. — Simon Janvier
To go further: Google’s official documentation on localized versions and hreflang.
