Hreflang Implementation: The Five Errors That Break It Every Time

Hreflang tells Google which language and region version of a page to show which users. It is simple in theory and broken on most international sites in practice. Five errors account for the large majority of failures, and every one of them is avoidable once you know the pattern.

What hreflang does

Hreflang is an annotation that links the alternate versions of a page together and labels each with a language, and optionally a region. It does not change rankings. It helps the right version appear for the right user, and it prevents your own regional pages from being treated as duplicates of each other. It can live in the HTML head, in HTTP headers, or in the XML sitemap.

One thing to be clear about before the errors: hreflang is not a fix for thin or duplicate content, and it is not a ranking booster. If your German and Austrian pages are genuinely near-identical, hreflang tells Google which to show where, but it does not make either page stronger. Treat it as a routing and disambiguation tool for sites that legitimately serve different languages or regions, and keep your expectations matched to that job. With that framing set, here are the five errors that break it in practice.

Error 1: missing return tags

Hreflang must be reciprocal. If the English page points to the German page, the German page has to point back. When the return tag is missing, Google ignores the annotation. This is the most common failure, especially when different teams manage different locales and one side forgets the other.

<!-- On the English (US) page -->
<link rel="alternate" hreflang="en-us" href="https://example.com/us/page" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/us/page" />

<!-- The German page must carry the same complete set -->

Error 2: wrong language and region codes

The values follow specific standards: ISO 639-1 for language and ISO 3166-1 Alpha 2 for region. People invent codes that feel right but are wrong. The classic is using en-uk instead of the correct en-gb, since UK is not the ISO country code for the United Kingdom. Another is putting a country where a language belongs.

Error 3: pointing to non-canonical URLs

Every hreflang target must be a canonical, indexable URL that returns a 200. If a hreflang tag points to a URL that redirects, or to one whose canonical points elsewhere, the annotation conflicts with itself and Google discards it. Hreflang and canonical have to agree: each page should be self-canonical and its alternates should also be self-canonical.

Error 4: relative URLs and other syntax slips

Hreflang URLs must be absolute, including the protocol. Relative paths do not work. Small syntax errors break clusters too: a trailing slash inconsistency, a mix of http and https, or listing the same locale twice with different URLs. If you generate hreflang from a template, one bad variable can break thousands of pages at once, so validate after any change.

Error 5: no x-default

The x-default value tells Google which page to show users whose language or region you do not target specifically. It is not strictly required, though leaving it out means visitors outside your defined set get an arbitrary version. Set x-default to your global or default-language page so the fallback is deliberate.

To check all of this, crawl the site and pull a hreflang report, then cross-check it against your sitemap for reciprocity and canonical agreement. This is exactly the kind of tedious, high-value verification that a proper technical SEO audit should include on any international site.

Validating at scale

On a site with three languages and a few hundred pages, you can eyeball hreflang. On a site with a dozen locales and tens of thousands of URLs, manual checking is hopeless, and this is exactly where templated hreflang breaks silently. One wrong variable in the template multiplies into thousands of broken clusters, and nobody notices until rankings drift in a specific market.

Build validation into the process instead of treating it as a one-off. Crawl the site with a tool that produces a hreflang report, and check three things systematically: that every annotation is reciprocal, that every target returns a 200 and is self-canonical, and that the language-region codes are all valid ISO values. Cross-reference the crawled hreflang set against the XML sitemap, since sitemap-based hreflang is often the easiest to manage at scale and the easiest to audit in one place.

Prefer XML sitemap hreflang for large sites. It keeps the annotations out of the page head, where they bloat the HTML, and puts them in one file you can generate and validate programmatically. Whatever method you choose, re-run the validation after every release, because a template change or a new locale is the moment hreflang quietly breaks again.

The takeaway: hreflang fails in predictable ways. Make the tags reciprocal and self-inclusive, use the correct ISO codes, point only to canonical 200 URLs, keep the URLs absolute and consistent, and set an x-default. Validate after every change, because templated hreflang breaks at scale. If your site spans many locales and the clusters keep failing, our work as a technical SEO agency covers international setups where the combinations get genuinely hard to manage by hand.