Six Pages, Thirty-Six Tags
You have a page in six languages. Correct hreflang requires each page to reference every version including itself — so six tags per page, on six pages. Thirty-six tags total.
Add a seventh language and you're at forty-nine. Ten languages gives you a hundred. Twelve languages across three regional variants each — thirty-six pages — needs 1,296 tags for a single piece of content.
Now multiply by every page on the site.
At that scale, hand-maintaining hreflang stops being tedious and starts being impossible. Every new language, every URL change, every page deletion requires updating tags across every other version. Miss one and the reciprocity requirement fails.
The question stops being "what should the tags say" and becomes "where should they live."
Three Places Hreflang Can Go
HTML head tags
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page/">
<link rel="alternate" hreflang="de-DE" href="https://example.com/de-de/page/">
<link rel="alternate" hreflang="x-default" href="https://example.com/page/">
Advantages: Easy to inspect — view source and they're there. Works without server configuration. Familiar to everyone.
Disadvantages: Adds weight to every page. At fifty language-region combinations you're shipping several kilobytes of link tags on every request. Requires the page to be crawled and rendered to be discovered.
Best for: Sites with a small number of language versions, up to roughly ten.
HTTP response headers
Link: <https://example.com/en-gb/page/>; rel="alternate"; hreflang="en-GB",
<https://example.com/de-de/page/>; rel="alternate"; hreflang="de-DE"
Advantages: The only option for non-HTML resources — PDFs, images, downloadable documents that exist in multiple languages. Keeps HTML clean.
Disadvantages: Harder to inspect and debug. Requires server or CDN configuration. Header size limits become a real constraint at scale, and some infrastructure truncates long headers without warning.
Best for: Non-HTML documents, and situations where you can't modify the HTML.
XML sitemap annotations
<url>
<loc>https://example.com/en-gb/page/</loc>
<xhtml:link rel="alternate" hreflang="en-GB"
href="https://example.com/en-gb/page/"/>
<xhtml:link rel="alternate" hreflang="de-DE"
href="https://example.com/de-de/page/"/>
</url>
Advantages: Zero page weight. Centralised — all your hreflang lives in files you generate programmatically. Easiest to validate, because you can parse and check the whole thing offline. Changes don't require touching page templates or server config.
Disadvantages: Sitemaps must be discoverable and processed. Errors are less visible than in HTML. The XML gets large.
Best for: Large sites and any site with more than about ten language versions.
Pick one method and use it consistently. Implementing hreflang in two places creates opportunities for the two to disagree, and conflicting signals are worse than a single imperfect one.
Generating Tags Programmatically
The rule that makes automation necessary: every version must link to every version, including itself.
If page A links to B but B doesn't link back to A, the relationship is not confirmed and search engines may disregard it. This bidirectionality is what makes manual maintenance fail — adding a language means editing every existing page, not just creating a new one.
The Hreflang Generator produces correct tag sets:
- Enter each URL with its language and region code.
- Generate the tag block.
- Verify the codes and reciprocity before deploying.
For a large site, use the generator to establish the correct pattern, then implement that pattern in your build pipeline.
The data model
The architecture that works is a translation group: a set of URLs that are versions of the same content, with a shared identifier.
group_id: 4471
├─ en-GB → /en-gb/pricing/
├─ en-US → /en-us/pricing/
├─ de-DE → /de/preise/
├─ fr-FR → /fr/tarifs/
└─ x-default → /pricing/
Generate hreflang by querying the group and emitting a tag for every member. Reciprocity is automatic because every page in the group generates from the same source data.
This is the single most important architectural decision. Without a translation group, hreflang has to be maintained as pairwise relationships, and pairwise relationships between n items number n(n−1) — which is exactly the scaling problem.
The Codes
Language codes are ISO 639-1 (two letters). Region codes are ISO 3166-1 Alpha 2 (two letters). They're joined with a hyphen.
en language only
en-GB language + region
en-US language + region
de-AT German as used in Austria
x-default fallback for unmatched users
Points that cause errors:
Region alone is invalid. hreflang="GB" doesn't work. Language is mandatory; region is optional.
Underscores are wrong. en_GB is the format used in many programming locale systems and is not valid hreflang. It's silently ignored, which makes it particularly nasty to debug.
Some codes aren't what you'd guess. The United Kingdom is GB, not UK. Sweden is SE with language sv. Japan is JP with language ja. Greece is GR with language el. Check rather than assume.
Case is not significant but convention is lowercase language and uppercase region: en-GB.
Script subtags exist for languages written in multiple scripts: zh-Hans for Simplified Chinese, zh-Hant for Traditional. These use ISO 15924 script codes and can be combined with a region: zh-Hant-TW.
x-default and Fallback Logic
x-default marks the page shown to users whose language and region don't match any of your versions.
<link rel="alternate" hreflang="x-default" href="https://example.com/">
Common choices for the target:
- A language selector page
- Your primary language version
- A global homepage
One x-default per translation group. It's optional but strongly recommended — without it, users outside your targeted markets get whichever version search engines guess at.
Matching behaviour
Search engines match progressively. A user set to de-CH (German, Switzerland):
- Looks for an exact
de-CHmatch - Falls back to
deif no regional match exists - Falls back to
x-default
This means a language-only tag serves as a catch-all for every region of that language. If you have de and de-AT, Austrian users get the Austrian version and everyone else who speaks German gets the generic one.
Don't create regional variants unless the content genuinely differs. Separate en-GB, en-US, en-AU, en-CA and en-IE versions that contain identical content add complexity and duplicate content risk without benefit. Use en unless prices, legal terms, shipping, or terminology actually differ.
Validating at Scale
Manual spot-checking doesn't work past a handful of pages. Build validation into your pipeline:
Reciprocity check. For every hreflang relationship A→B, confirm B→A exists. This is the most common failure and the easiest to test programmatically.
Self-reference check. Every page must include a tag pointing to itself.
Code validation. Check every language code against the ISO 639-1 list and every region code against ISO 3166-1. Reject underscores.
URL resolution. Every hreflang target must return 200. A tag pointing to a redirect, a 404, or a noindexed page is a broken relationship.
Canonical consistency. Each page's canonical should point to itself, not to another language version. Canonicalising a German page to its English equivalent tells search engines the German page shouldn't be indexed — which defeats the entire purpose.
Duplicate code check. Two tags with the same hreflang value in one group is ambiguous. Search engines may ignore both.
Absolute URLs. Relative hreflang URLs are invalid.
Run these as a build step or a scheduled crawl. Hreflang errors are silent — nothing breaks visibly, traffic just goes to the wrong version.
Practical Tips
Choose your implementation method based on scale. HTML for small sites, sitemaps for large ones, headers for non-HTML files.
Store translation groups in your CMS, not in templates. Generate tags from data.
Deploy all versions of a page together. Partial deployments create temporary reciprocity failures.
Handle deletions properly. Removing a language version means regenerating tags for every remaining version in the group. A tag pointing to a deleted page is a broken relationship.
Don't mix hreflang and geo-redirects carelessly. Automatically redirecting by IP can prevent crawlers from reaching versions they're trying to index. If you redirect, make sure each version remains directly accessible.
Keep canonicals self-referential on every language version.
FAQ
Which implementation method is best? Sitemaps for large multilingual sites, HTML head tags for smaller ones, HTTP headers for non-HTML resources. Consistency matters more than the specific choice.
Do pages need to reference themselves? Yes. Self-reference is required, and omitting it is a common cause of hreflang being disregarded.
Is en_GB valid?
No. Hreflang uses a hyphen. Underscore format is silently ignored.
How many hreflang tags can a page have? There's no hard specified limit, but page weight and header size limits become practical constraints. Past roughly ten versions, move to sitemap implementation.
Should I use en or en-GB?
Use language-only unless the regional versions genuinely differ in content. Unnecessary regional splitting adds complexity for no gain.
Can hreflang and canonical conflict? Yes, and it's a serious error. Each language version should canonicalise to itself; canonicalising across languages removes pages from the index.
The Takeaway
Hreflang is simple in principle and fails at scale for one reason: the reciprocity requirement means every change touches every version. Solving it properly means storing translation groups as data and generating tags from that data — at which point adding a language is a database row rather than an editing project across dozens of templates.
Generate correct hreflang tags free with the Hreflang Generator at sadiqbd.com — no sign-up, instant results.
