Four rules that keep the set interpretable
Hreflang is a cluster of annotations, so errors on one side can affect how Google interprets the relationship. Google says missing return links or otherwise invalid annotations may be ignored or interpreted incorrectly; it does not promise that one mistake always voids the entire cluster.
- Complete: every version in the group lists every other version.
- Mutual: if X points to Y, Y should point back to X. Missing return links can cause annotations to be ignored or interpreted incorrectly.
- Self-referencing: each page lists itself alongside the others.
- Valid: the codes must parse as real language and region codes.
The mutuality rule is the one that catches teams, because hreflang describes relationships between pages rather than a property of one page in isolation. Roll out corresponding return links together so each published relationship is complete when Google crawls either side.
Where to put the annotations
Three placements are available and they are equivalent in effect. Pick one and use it everywhere — mixing them across a site is how sets end up half-declared.
| Method | Best for | Watch out for |
|---|---|---|
| HTML link elements | Small to mid-size sites | Page weight when there are many versions |
| HTTP headers | PDFs and other non-HTML files | Header size limits on large sets |
| Sitemap entries | Large sites, many locales | Kept in sync with the pages themselves |
<link rel="alternate" hreflang="en" href="https://example.com/guide/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/guide/" />
<link rel="alternate" hreflang="pt-br" href="https://example.com/pt-br/guide/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/guide/" />Note that the English page in that sample lists itself. That is the self-reference, and its absence is the single most common defect in otherwise careful implementations — because it looks redundant and reads like a mistake to anyone tidying the template.
Codes, and the ones that don't exist
Language is ISO 639-1. It may optionally be followed by a dash and an ISO 3166-1 Alpha 2 region. A region on its own is never valid: there is no way to say "this page is for Canada" without saying which language it is in.
| Code | Verdict | Why |
|---|---|---|
| en | Valid | Language only — English, any region |
| en-GB | Valid | English as written for the United Kingdom |
| GB | Invalid | Region without a language |
| uk | Valid, but not the UK | uk is Ukrainian; the UK is GB |
| eu | Invalid as a region | The EU is not a country code |
| en-UK | Invalid | The country code for the UK is GB |
What x-default is for
x-default catches the languages you did not list. It is the fallback for a visitor whose language matches none of your versions, and its natural home is a selector page or a home page that routes visitors by itself.
It is not a way to nominate a primary version. Pointing x-default at your English page because English feels like the default tells the engine that English is what an unmatched Japanese or Turkish visitor should get, which may be true and is worth deciding deliberately rather than by habit.
Hreflang and canonical are different jobs
These two get tangled more than any other pair in technical SEO, and the failure mode is severe. A canonical says "index this other URL instead of me". Hreflang says "this other URL is the same content for a different audience".
Point the canonical of your German page at the English one and you have told the engine the German page should not be indexed at all — which removes it from the results, and simultaneously breaks the hreflang set that referenced it. Each localised page should canonicalise to itself, and use hreflang to describe its siblings.