International SEO and hreflang
Country and language targeting, correct hreflang syntax and return links, choosing between ccTLD, subfolder and subdomain, and the failures that silently disable the whole cluster.
Language and country codes
hreflang uses ISO 639-1 for language and optional ISO 3166-1 alpha-2 for region. It tells an engine which version of a page to serve to which audience; it does not translate anything and it is not a substitute for localised content.
<link rel="alternate" hreflang="en" href="https://example.com/guides/dns/ttl" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/guides/dns/ttl" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/guides/dns/ttl" />
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/guides/dns/ttl" />
<link rel="alternate" hreflang="x-default" href="https://example.com/guides/dns/ttl" />- Every page in the cluster lists every page in the cluster, including itself. Missing return links is the most common reason hreflang is ignored entirely.
x-defaultbelongs on the version served when no other match exists - usually the language-selector page or the global English page.- Use
enfor an undifferentiated English page anden-GBoren-USfor region variants. Do not mixenanden-USfor the same page. - Language and region codes go in the URL only if you commit to it: a
/en-gb/path that later becomes/uk/costs a redirect on every page.
Choosing a structure
| Option | Example | Pros | Cons |
|---|---|---|---|
| ccTLD | example.de | Strongest local signal, unambiguous | One domain to build authority for, per country cost |
| Subfolder | example.com/de/ | All authority accumulates on one domain | Shared hosting and infra decisions across markets |
| Subdomain | de.example.com | Independent deployment and teams | Authority is split; needs its own reputation |
| Parameters | example.com?lang=de | Trivial to implement | Weak signal, messy URLs, hard to manage |
Recommendation order for most teams
1. subfolder - simplest to run, one domain, one certificate, one CDN
2. ccTLD - when local trust or legal presence demands it
3. subdomain - only when markets genuinely need separate infrastructure
never: parameters - the effort saved is repaid many times overWhatever you choose, the localised page must be genuinely localised. Machine-translated pages with prices in the wrong currency, an unchanged phone number or untranslated navigation are what turn a multi-language site into a set of near-duplicate pages.
The failures that disable it all
- Self-reference missing. A page that lists the other versions but not itself invalidates the cluster.
- Non-return links. A to B, but B does not link to A - the relationship is dropped.
- Wrong codes.
en-UKis not a valid region; the correct code isen-GB. - Conflicting signals. A canonical pointing to the
x-defaultversion from a localised page tells an engine to ignore the localisation. - URLs that redirect. hreflang must point at the final URL, not a redirect source.
- Both headers and HTML carrying different sets. Use one mechanism, consistently.
| Check | How to verify | Expected |
|---|---|---|
| Self reference | Search the page source for its own URL | Present, with the right code |
| Reciprocity | Pick any pair and confirm both directions | Mutual links in both files |
| Valid codes | Validate against the ISO lists | No invented regions |
| Canonical alignment | Compare canonical and hreflang sets | Canonical points within the same locale |
| Final URLs | Curl each hreflang URL | 200, no redirect |
FAQ
Do I need hreflang if I only have one language?
Does hreflang replace localised content?
Related
Site architecture, URLs and internal linking Site migrations, redirects and recovery
Last refreshed 2026-09-18.