How the annotation works
Each page lists every language version of itself, including itself, using a language code and optionally a region: en, en-gb, de-ch. A page that lists others without being listed by them in return is ignored.
The maths is why this gets out of hand. Four languages across eight markets is not twelve annotations, it is every version referencing every other version, and the count grows with the square of the combinations.
| Mistake | Symptom | Fix |
|---|---|---|
| Missing return links | The whole cluster is ignored | Every version lists every version, itself included |
| Invalid region code | Annotation silently dropped | Use ISO codes; en-eu is not one |
| Pointing at redirects | Signals diluted | Reference the final URL |
| No x-default | Wrong version served to unlisted markets | Add an x-default fallback |
| Conflicts with canonical | Engine ignores both | Each version canonicalises to itself |
The failures that actually happen
- Missing return links, so the whole cluster is discarded
- Invented region codes, such as en-eu, which is not a valid region
- Pointing at URLs that redirect rather than at the final address
- No x-default for visitors who match no version
- Annotations that disagree with the canonical tags on the same pages
At enterprise scale
On Klipboard's global rebrand we generated 6,082 hreflang annotations across four languages and eight markets. At that volume the tags cannot be written by hand: they have to be produced from the CMS so that adding a page or a locale cannot break the return links.
Why it matters for B2B marketing teams
If you are running more than two locales, hand-maintained hreflang will break, and it will break silently. The only version that survives a growing site is one generated from the CMS, so adding a page or a market cannot orphan a cluster.