How to audit hreflang and find the mistakes that quietly break it

hreflang breaks without telling anyone. A UK page starts ranking in Ireland, the US version shows up for Australian searches, or a new German page never appears at all, and nothing in the CMS looks wrong. The annotations are there. Google has decided it cannot trust them. The cause is almost always one of a handful of mistakes, and an audit finds them. The basics of how hreflang works are in the international SEO guide.

Google is strict about what it accepts. If two pages do not both point to each other, it ignores the tags, so that another site cannot claim to be an alternate version of yours.¹ An annotation that fails that check does not raise an error on the page. It just stops counting.

Search Console used to have an International Targeting report that showed hreflang errors. It has been deprecated, and Google's help page says only that it will continue to support and use hreflang tags.² That leaves crawlers, sitemaps and your own checks. If nobody is running them, the first sign of a problem is a market report showing traffic landing on the wrong version.

The errors are common. Ahrefs' 2023 study of 374,756 domains using hreflang found that 67% had at least one issue, measured by the checks in its own site audit tool, which it sells.³ The breakdowns below come from the same study.

Missing return links and incomplete sets

Missing return links head the list of common mistakes in Google's documentation: if page X links to page Y, page Y must link back to page X. Each version should also list itself as well as every other version.¹ In the Ahrefs study, 15.3% of domains had pages missing reciprocal tags and 18% had pages missing self-referencing tags.³ In practice the set goes out of step when markets launch at different times. The French site adds a new product page and points it at the UK equivalent, but the UK template only outputs hreflang for markets it knew about at launch. The pair is broken from the UK side, and nobody on the French team can see it. Google does allow some slack: where a complete set is hard to maintain, some languages can be left off some pages, and the pairs that do point at each other are still processed.¹ That is a fallback for very large sets. In an audit I would still report every one-way pair.

There is a ranking consequence beyond the ignored tag. For canonicalisation, Google prefers URLs that are part of hreflang clusters. Its example is a set where the de-de and de-ch pages point to each other but not to the de-at page, and the de-de and de-ch pages are then preferred as canonicals over de-at.⁴ A market dropped from the cluster can lose out to the markets that stayed in it.

Invalid language and region codes

Only ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes are supported in hreflang, and es-419 is the documented example of a code that is not. A country code on its own is not allowed, because the first code always stands for the language. Codes reserved for something else, such as EU, UN or UK, cause Google to ignore that part of the annotation.¹ The usual offenders are en-UK for the United Kingdom, a bare region code such as "ie" meant as Ireland, and invented codes for regions like Latin America or the EU. Ahrefs found incorrect hreflang values on 4.6% of the domains it checked.³

Some of these codes slip through because they are valid elsewhere. es-419 is a correct BCP 47 language tag for Latin American Spanish, and fine in an html lang attribute.⁵ en-UK is not valid anywhere: the IETF registry of language subtags leaves UK out because it is an exact synonym for GB.⁶ Practitioners disagree on how Google handles it. Patrick Stox wrote in the Ahrefs study that Google does accept uk, which is not what its documentation says.³ Fix it to en-GB either way.

Canonicals that contradict hreflang

hreflang says which URLs are equivalents for different audiences. The canonical says which URL represents a set of duplicates. With hreflang in place, each page's canonical should be in the same language, or the best substitute language if none exists, and rel="canonical" annotations carrying an hreflang attribute are not used for canonicalisation.⁴ The pattern to look for is a market page that canonicalises to another market, often the home one. An en-AU page with a canonical pointing at en-GB is telling Google it is a duplicate of the UK page, while its hreflang is telling Google it is a distinct page for Australia. I would expect the canonical to win, though Stox reported that in many cases he looked at, the canonical was ignored in favour of the URL in hreflang.³ Either way the signals conflict and Google picks, which is the outcome an audit should remove.

Alternates that are not live, indexable pages

Every URL in a set should return a 200 status, be indexable and carry a self-referencing canonical. Google's hreflang documentation does not spell out what happens otherwise, but its canonical documentation does cover the pieces. A redirect is a strong signal that the redirect target should become canonical, and noindex completely blocks a page from Search.⁴ An hreflang entry that points at a redirecting, noindexed or missing URL is pointing at something Google will not show. It also cannot return the link, so the pair fails. In the Ahrefs study, 16.9% of domains had hreflang pointing at redirected or broken pages.³ I would treat URLs blocked in robots.txt the same way, because Google cannot fetch a blocked page to read its annotations.

Mixed methods that disagree

HTML tags, HTTP headers and sitemaps are equivalent for Google. All three can be used at once, but there is no benefit in Search and it may be much harder to manage.¹ The failure I would look for is a site that moved hreflang into sitemaps and left an old plugin writing tags into the page head, with the two sets drifting apart. Ahrefs found 2.5% of domains naming more than one page for the same language, and Stox noted this is often a mismatch between the page code and the sitemaps.³ Google's canonical guidance makes the same point for its own signals: do not specify different canonical URLs for the same page through different methods.⁴ Pick one hreflang method and remove the others.

Tags Google never reads

Some annotations are fine on paper and never processed. hreflang link elements have to sit inside a well-formed head.¹ Once Google detects an invalid element in the head, such as an img or iframe, it assumes the head has ended and ignores the elements after it.⁷ A tracking pixel injected near the top of the head can cut off every hreflang tag below it. This is not a rare fault. The HTTP Archive's 2024 Web Almanac found head-breaking invalid elements on 10.9% of mobile pages and 10.6% of desktop pages in its June 2024 crawl.⁸ Relative URLs are the other quiet failure, since alternate URLs must be fully qualified, including https.¹

The audit treats hreflang as a graph. Each URL is a node and each annotation is an edge, and you are checking that every edge has a partner going the other way and that every node is a page Google can index.

Most audits start from a complaint about rankings. This table is my starting point for working back to the likely fault.

An audit fixes today's graph. The graph changes every time a page is added, removed or moved in any market. After a site move, hreflang annotations have to be updated to the new URLs,¹¹ and the same applies at a smaller scale whenever a single product or article changes URL.

• Generate hreflang from one source of truth, such as the product catalogue or a table of page equivalents, so that removing a page from one market removes it from every set.
• Only include a market in a set when its version exists and is indexable. A placeholder page is worse than no entry.
• Add a reciprocity and status check to the release process for the templates that output hreflang. A failure caught before deploy costs minutes.
• Re-crawl the full graph on a schedule, monthly for most sites, and after any migration, CMS change or new market launch.

If the audit turns up a structural problem, such as markets split across subdomains and folders with no consistent pattern, fixing tags will only go so far. That decision is covered in choosing a URL structure for a new market.