How to fix hreflang errors
Fix hreflang by making every annotation reciprocal, self-referencing and written with valid ISO codes. Each URL in a language set must list every other version including itself, and each of those versions must link back. If a single return tag is missing, Google discards the whole cluster and may serve the wrong language in search results.
Last updated 2026-07-28
What does hreflang actually do?
It decides which language or regional version of a page a given searcher is shown — nothing more. Hreflang is a targeting annotation, not a ranking signal: it does not make any version rank higher, it swaps which version appears once the page already ranks.
Done right, a searcher in Lyon gets the French page and a searcher in Montreal gets the Canadian French one. Done wrong, both land on the English page, bounce, and take the engagement metrics down with them.
It also protects you from your own duplicate content. Three near-identical English pages for the US, UK and Australia look like duplicates without hreflang, and like deliberate regional targeting with it.
Why do most hreflang implementations fail?
Because of reciprocity. If page A declares page B as its French version, page B must declare page A as its English version, and a missing return tag invalidates the pairing — Google treats an unconfirmed annotation as untrusted and ignores it.
The common shape of the bug is a marketing site where the English page dutifully lists all eight translations, while each translation lists only itself and English. Seven of the eight relationships then evaporate. Nothing on any individual page looks wrong, which is precisely why the error survives so long: it exists only in the relationship between pages, so inspecting one URL at a time can never reveal it.
Which rules break implementations most often?
Six rules account for nearly every broken cluster: reciprocity, self-reference, valid codes, absolute URLs, agreement with the canonical, and an x-default fallback. Each has a characteristic mistake attached to it.
| Rule | Common mistake |
|---|---|
| Reciprocal links | The English page lists all translations; the translations link back only to English |
| Self-reference required | Each page omits its own hreflang entry, which invalidates the set |
| Valid codes only | Writing "en-UK" instead of the correct "en-GB", or "uk" as a language when it means Ukrainian |
| Language first, region second | Writing "gb-en"; the order is ISO 639-1 language then optional ISO 3166-1 Alpha 2 region |
| Absolute URLs | Relative hrefs, which are ignored outright |
| Canonical agreement | Hreflang points at a URL that canonicalises somewhere else, cancelling the annotation |
| x-default for fallback | No x-default entry for users whose language matches none of your versions |
| One method only | Declaring hreflang in the HTML head and the sitemap with different contents |
What does a complete hreflang set look like?
Every page in the cluster carries the identical block, listing all versions including itself, plus an x-default. The block below goes on the English page and the French page unchanged — that sameness is what makes the set reciprocal.
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
<!-- Regional variants: language first, region second, both valid ISO codes -->
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="fr-CA" href="https://example.com/ca-fr/" />Should hreflang go in the HTML, the sitemap, or an HTTP header?
Pick one method and use it consistently. All three are equally valid to Google; the failure comes from mixing them, because two sources with different contents produce conflicting annotations and the cluster is dropped.
Use the HTML <head> when you have a handful of languages and control over the template — it is the easiest to inspect and debug. Use the XML sitemap when you have many languages or many URLs, because it keeps every page's markup small and lets you update the whole matrix in one file. Use the HTTP Link header for non-HTML files such as PDFs, which have no head to put tags in.
Whichever you choose, hreflang belongs alongside a correct html lang attribute on the root element. They are different mechanisms — lang tells the browser and screen reader how to render this page, hreflang tells a search engine which page to show whom — and a multilingual site needs both.
How do I check hreflang across every language version?
Crawl every language version in one pass and build a matrix of which URL declares which alternates, then look for pairs where only one direction exists. This is the only reliable way to find missing return tags, because the error lives between two pages rather than on either one.
Audra records the hreflang annotations present on each crawled page, so a whole-site crawl gives you the raw material for that matrix without visiting each URL by hand. Raise the default 100-page crawl cap or use include globs to cover each language directory. For very large multilingual estates, Screaming Frog has a dedicated hreflang report that does the reciprocity comparison for you.
The fix, step by step
- 1Crawl every language version of the site in a single pass.
- 2For each URL, list the hreflang entries it declares and the method used to declare them.
- 3Verify every declared alternate links back, and that each page includes a self-reference.
- 4Validate that language codes are ISO 639-1 and region codes are ISO 3166-1 Alpha 2, in that order.
- 5Confirm each hreflang target is self-canonical, then add an x-default for unmatched users.
Frequently asked questions
Do I need hreflang for a single-language site?
No. It only applies when the same content exists in more than one language or regional variant. A single-language site gains nothing from it.
What is x-default for?
It marks the fallback page shown to users whose language and region match none of your versions — typically a language selector or the international English page. It is optional but strongly recommended.
Does hreflang improve rankings?
Not directly. It changes which version is served rather than how well any version ranks. The indirect benefit is real though: users landing on a page in their own language engage more and bounce less.
Can hreflang point at a page that canonicalises elsewhere?
No — that combination cancels itself out. Every hreflang target must be self-canonical, otherwise you are simultaneously telling Google that the page is a valid alternate and that it should be replaced by a different URL.