Hreflang
What hreflang is, the three ways to implement it, the reciprocal and self-referential rules, valid language/region codes, and how to audit clusters at scale.
1 evidence signal on this page
- Related live toolhreflang Generator + Linter
Hreflang tells search engines which language/region version of a page to show which user. You declare it one of three ways — HTML head tags, HTTP headers, or XML sitemap — using ISO 639-1 language + ISO 3166-1 alpha-2 region codes. It only works as a reciprocal cluster: every page must link to itself and to all its alternates, and if any return link is missing, Google ignores the pair. It's a hint, not a directive — wrong hreflang is ignored, not penalized. It's also fragile: in my study of 374,756 hreflang-using domains, over 67% had at least one issue. Bing barely uses it (content-language is the stronger signal there). This hub explains the whole thing and points you to the deep dives.
TL;DR — Hreflang tells search engines which version of a page is meant for which language or region — so a Spanish speaker gets your Spanish page and a French speaker gets the French one. You add a small annotation to each page listing all the language versions. The catch: every page has to point back at every other one, or Google may ignore the affected annotations.
What hreflang is
If you publish the same page in more than one language — or in the same language for different countries — hreflang is how you tell Google which is which. It’s an annotation that lists all the alternate versions of a page and the language (and optionally the region) each one targets. When someone searches, Google can use it to swap in the version that matches their language and location — it’s a signal that helps Google choose the right localized URL, not a guarantee of indexing, ranking, traffic, which URL gets shown, or citation in AI answers.
Evidence for this claim Google accepts hreflang in HTML, HTTP headers, or XML sitemaps and says the methods are equivalent from its perspective. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versionsIt looks like this in the page’s HTML <head>:
<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />Each line says: “there’s an alternate version of this page, it’s for this language/region, and it lives at this URL.”
The three ways to add it
Generate valid tags with the hreflang Generator + Linter:
- In the locale/URL matrix, add one row per language version of your page (locale code + URL) — the output updates live as you type.
- Pick the format you need from the output tabs — Head tags, Sitemap XML, Link headers, or framework Snippets.
- Check the linter panel for invalid-code or missing-return-link warnings, then Copy or Download the result.
You only need to pick one of these:
- HTML
<head>tags — the most common method, shown above. Good for smaller sites. - HTTP
Linkheaders — the same information sent in the server response instead of the HTML. This is the only option for non-HTML files like PDFs. - XML sitemap — you list the alternates inside your sitemap instead of on each page. Best for big sites, because you don’t have to touch every page’s HTML.
The codes have to be valid
The value is a language code, optionally followed by a dash and a region code:
- Language uses ISO 639-1
—
enfor English,esfor Spanish,defor German,jafor Japanese. - Region (optional) uses ISO 3166-1 alpha-2
—
en-us,en-gb,es-mx.
Two things people get wrong constantly: the United Kingdom is gb, so UK English
is en-GB, not en-UK (uk is reserved and actually means Ukrainian). And
you can target a language on its own (es = all Spanish speakers everywhere), but
you can’t target a region on its own — there’s always a language first.
Google’s documented hreflang contract is narrower than the code space the web
platform allows generally: Google recognizes language + optional region and says
reserved codes like EU, UN, and UK simply have no effect as region targets.
The broader HTML/BCP 47 language-tag standard that hreflang is built on also
supports script subtags (zh-Hant for Traditional Chinese, sr-Latn for
Latin-script Serbian) — worth knowing for lang attributes generally, but stick to
Google’s documented language-plus-region pattern for hreflang specifically.
The two rules that make it work
- Every page must point back. If your English page links to your Spanish page, the Spanish page has to link back to the English one. If that return link is missing, Google may ignore or misinterpret the affected annotations.
- Every page should point to itself. Each version lists itself in its own set of hreflang tags (the “self-referential” tag). Google calls this optional but good practice, and it’s the safest default.
When do you actually need hreflang?
You need it when you have genuinely different versions of a page for different languages or regions:
- Real translations (an English page and a Spanish page).
- The same language for meaningfully different markets (a US English page and a UK English page with different prices, spelling, or shipping info).
You don’t need it for a single-language site, and you shouldn’t bolt it onto thin or auto-translated pages just to have it. Hreflang doesn’t make you rank higher — it just helps the right version show up for the right person.
Want the implementation-at-scale version, the canonicalization edge cases, what Bing does instead, and how to audit a broken cluster? Switch to the Advanced tab.
Hreflang mistakes that break clusters
Publishing one-way annotations
Why it fails: an alternate that does not link back creates a missing return tag, so the pair may be ignored. Do instead: generate the complete reciprocal set on every member, including its self-reference.
Pointing hreflang at redirected or non-canonical URLs
Why it fails: the annotation names a URL that is not the final indexable version, creating conflicting signals. Do instead: target direct 200 canonical URLs and keep each page self-canonical unless consolidation is intentional.
Using a country code without a language
Why it fails: region is optional, but language is required. Do instead: use a valid language code such as en, optionally followed by a valid region such as en-GB.
Mixing implementation methods without one source of truth
Why it fails: HTML, headers, and sitemaps can drift into contradictory clusters. Do instead: choose the method your stack can generate reliably or derive all methods from the same locale map.
Test yourself: Hreflang
TL;DR — Hreflang is a reciprocal cluster signal: every page lists itself and all alternates, and a missing return tag voids the pair. Declare it one way only — HTML head, HTTP
Linkheaders (PDFs), or XML sitemap (best at scale). Codes are ISO 639-1 language + ISO 3166-1 alpha-2 region;en-UKis wrong, it’sen-GB. It’s a hint, not a directive (Mueller) — wrong hreflang is ignored, not penalized, and Google can override it for same-language consolidation or indexing reasons. It breaks constantly: in my Ahrefs study of 374,756 domains, over 67% had at least one issue. Bing treats it as a far weaker signal thancontent-language. Audit clusters visually rather than in spreadsheets.
Hreflang is a cluster, not a tag
© Patrick Stox LLC · CC BY 4.0 ·
© Patrick Stox LLC · CC BY 4.0 ·
The mental model that fixes most hreflang confusion: it isn’t a per-page tag, it’s a bidirectional graph. Google’s own requirement is blunt — “Each language version must list itself as well as all other language versions,” and “if two pages don’t both point to each other, the tags will be ignored.” So if page X points to Y but Y doesn’t point back to X, that edge is silently dropped. One missing return tag can cause the affected annotations to be ignored or interpreted incorrectly — but Google says it can still process the pairs that are correctly reciprocal, so one broken relationship doesn’t necessarily take down every annotation in a larger cluster.
Evidence for this claim Each hreflang set should include the page itself, use fully qualified URLs, and include return links; without reciprocity, the affected annotations may be ignored or misinterpreted. Scope: Google Search hreflang guidelines; the documentation does not say one missing return link invalidates every annotation in a cluster. Confidence: high · Verified: Google: Localized versions guidelinesTwo non-negotiables flow from that:
- Reciprocity. Every reference must be returned. This is where implementations break at scale — the moment one template, one CMS field, or one region’s pages fall out of sync, return links go missing.
- Self-reference. Each page lists itself. Mueller calls it “optional—but good practice”; in practice, a self-referential set is the cleanest way to keep clusters consistent and is flagged as an issue when missing.
Absolute, fully-qualified URLs are required too — https://example.com/foo, never
//example.com/foo or /foo.
Three methods — and the trade-offs
Google treats HTML tags, HTTP headers, and XML sitemaps as equivalent — there’s no Search benefit to implementing more than one. Pick one method per site based on what your stack can maintain reliably; mixing them invites conflicts.
- HTML
<head>tags. Simplest, most visible. Downside: on a site with dozens of locales, every page carries a large block of<link>tags, adding markup weight, and any page in the<body>(from malformed HTML or JS injection) is invalid — hreflang only counts in the<head>of the page as Google renders/parses it. - HTTP
Linkheaders. The only option for non-HTML resources like PDFs. Sent in the response, so they don’t bloat the document. - XML sitemaps. The right call at scale. The annotations live centrally
(
xhtml:linkchildren under each<url>, with thexmlns:xhtml="http://www.w3.org/1999/xhtml"namespace), so you can regenerate the whole cluster from a database without redeploying pages. There’s no “faster” method — both HTML and sitemaps are resolved at crawl time — but sitemaps are far easier to QA because you can validate the entire graph in one file instead of crawling every page.
Reciprocal linking at scale — where it breaks
In a 5-locale site, that’s a 5×5 matrix of references per page set, regenerated every time you add or remove a locale, fix a slug, or migrate a URL. The failure modes are predictable:
- Inconsistent URL formats. Trailing-slash vs. not,
httpvs.https,wwwvs. apex, or uppercase vs. lowercase paths — any mismatch between the URL in the hreflang and the URL Google actually indexes breaks the return-link match. - Pointing at redirected or broken URLs. A locale URL changes, the redirect
goes in, but the hreflang still points at the old URL. The cluster now references
a
301or a404. - Code drift.
jpinstead ofjafor Japanese, three-letter codes where two-letter is required,en-UKinstead ofen-GB. Invalid codes are ignored.
Worked deployment example: the return tag points to yesterday’s URL
Suppose the UK product page moved from /gb/shoes/ to /uk/shoes/. The US page was
not regenerated, so it still publishes:
<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/gb/shoes/" />The old UK URL redirects to /uk/shoes/, while the new UK page links back to the US
page from its final canonical URL. That leaves two distinct problems: the US
annotation targets a redirect, and the final UK URL is not the same URL the US page
declared. Fix the generator so both pages publish the complete set using final,
indexable URLs:
<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/uk/shoes/" />Validate both directions after deployment; checking only the US source tag would
miss the return-tag failure. This is an illustrative .example cluster.
The lesson from my conference talks holds: automate hreflang generation from a single source of truth. Hand-maintained hreflang at scale is a guarantee of return-tag rot.
Canonicalization conflicts
Hreflang depends on what’s indexed, not on what’s canonicalized — but the two interact, and getting it wrong breaks clusters:
- Self-referencing canonicals are the safe default. Each language version should canonicalize to itself. If your Spanish page canonicalizes to the English page, you’re telling Google the Spanish URL isn’t the one to index — and hreflang pointing at a non-canonical URL is one of the more common errors.
- The same-language, multi-country edge case. When you have, say,
en-usanden-gbpages that are near-identical, Google may consolidate them and index one — but it can still swap the displayed URL in the SERP to the correct country version via the hreflang links. So a “canonicalized-away” URL can still surface for the right user. That’s a feature, not a bug, but it surprises people auditing index coverage. - noindex and robots.txt. A page blocked from indexing can’t participate in a cluster — its hreflang can’t be acted on, and pointing to a noindexed/blocked URL breaks the return link. Don’t block or noindex language variants you want served.
It’s a hint, not a directive
This is the framing to internalize. In May 2025 on Bluesky, John Mueller responded
to a case of fr-be pages showing up in fr results despite correct hreflang:
“hreflang doesn’t guarantee indexing, so it can also just be that not all
variations are indexed,” and “I suspect this is a ‘same language’ case where our
systems just try to simplify things for sites.” Google reserves the right to
override hreflang for same-language consolidation, indexing gaps, or its own
canonical choices.
Google’s canonicalization guidance is the flip side of that: it recommends choosing a canonical in the same language as the page (or the best available substitute), and it says it prefers URLs that are part of a complete reciprocal hreflang cluster over otherwise-similar URLs sitting outside it. That’s a preference, not a promise — being in a correctly-built cluster improves your odds of the right URL getting selected, but it doesn’t guarantee indexing or which URL shows.
The practical consequence: wrong hreflang is ignored, not penalized. If your cluster is broken, Google falls back to its own language/region detection. The cost is opportunity (the wrong URL shows for some users), not a ranking hit. So “my hreflang is wrong” is rarely an emergency — but it’s also rarely doing anything useful.
Bing and the other engines use a different stack
Hreflang is a Google (and Yandex) signal. Bing’s signal stack is completely
different. Fabrice Canel, Principal Program Manager on Microsoft Bing, has said
plainly that “hreflang is indeed a far weaker signal than content-language at
Bing.” Bing leans on the content-language HTTP header / meta tag, the
<html lang=""> attribute, inbound links, visitor geography, and server/ccTLD
location, and Canel has advised against “duplicating URLs just to have them tagged
with these language-markets” in most cases. Baidu doesn’t support hreflang at
all (it keys off hosting location, Chinese domain registration, ICP licensing, and
content-language). So a robust international setup pairs hreflang for Google with a
correct content-language / html lang for everyone else.
The error rate is the story
When I ran the largest hreflang study to date at Ahrefs — 374,756 domains, nearly 10× larger than any prior study — over 67% of domains using hreflang had at least one issue. The distribution:
| Issue | % of domains |
|---|---|
| Missing x-default | 56.3% |
| Missing self-referencing tags | 18.0% |
| Referencing broken/redirected pages | 16.9% |
| Missing reciprocal tags | 15.3% |
| Pointing to non-canonical URLs | 8.0% |
| Incorrect language/country codes | 4.6% |
| Inconsistent language attributes | 3.2% |
| Multiple pages for same language | 2.5% |
| Same page for multiple languages | 2.5% |
My study’s summary still stands: hreflang is complex and hard to get right, and it can break in a lot of different ways.
Auditing at scale — visualize the cluster, don’t read a spreadsheet
See your own cluster with returntag:
- Paste one page URL, a sitemap URL, or a list of page URLs into the tool.
- Click Validate cluster.
- Read the GRAPH view — broken or missing return links stand out by severity color — or switch to MATRIX for a row-by-row view, and export a fix-list CSV if you need to hand it to someone else.
The reason hreflang errors hide is that a return-tag problem is a relationship
between pages, and relationships are nearly impossible to read across rows of a
spreadsheet. Ahrefs Site Audit was the first tool to render the hreflang cluster
as a graph — open any page’s URL details and the Hreflangs tab draws the
whole cluster as a network, with the broken pages and missing/incorrect links
highlighted in red. You can see at a glance which return tag is missing or
which link was added by mistake — and it’s far easier to show a stakeholder than a
CSV. Site Audit also runs the underlying checks (invalid annotation, missing
self-reference, more than one page per language, hreflang/html lang mismatch,
missing reciprocal tag, non-canonical target, broken target) that map directly to
the study’s error list.
Beyond that:
- GSC URL Inspection confirms how a single URL was crawled and indexed. Note the old International Targeting report was deprecated on September 22, 2022 — Google said it “had little value for the ecosystem.” Hreflang tags themselves still work; only the report is gone.
- Manual SERP testing with the
&hl=(host language) and&gl=(geolocation) parameters on a Google search URL lets you preview what a given locale’s results look like.
Hreflang is also a technical-SEO audit concern
Although hreflang’s home is international SEO, it shows up in nearly every technical SEO audit of a multi-language or multi-region site — it sits right alongside canonicalization, indexing, and crawl-accessibility checks, and it’s one of the items most likely to be silently broken. If you’re running a technical audit and the site has more than one locale, the hreflang cluster belongs on the checklist.
Where to go next
This hub is the map for the hreflang sub-cluster. The first deep dive:
- x-default — the fallback value for users whose locale matches none of your explicit tags (a country selector or a global homepage). It’s not required, but it was the single most common omission in my study (56.3% of sites). The dedicated subtopic covers when to use it, when to skip it, and how it interacts with the rest of the cluster.
For the broader strategy this implements, see the International SEO pillar — hreflang is the technical layer of an international strategy; it doesn’t replace genuine localization (local intent, local content, local authority).
AI summary
A condensed take on the Advanced version:
- Hreflang is a reciprocal cluster signal, not a per-page tag — and only a signal Google can use to pick a localized URL, not a guarantee of indexing, ranking, traffic, which URL displays, or AI citation. Every page lists itself and all alternates; a missing return tag voids that pair, though Google can still process the pairs elsewhere in the cluster that are correctly reciprocal.
- Three methods, pick one: HTML
<head>tags, HTTPLinkheaders (the only option for PDFs), or XML sitemap (best at scale, easiest to QA). Google treats all three as equivalent — no Search benefit to using more than one, and neither is “faster” (both resolve at crawl time). - Codes: ISO 639-1 language + optional ISO 3166-1 alpha-2 region.
en-GB, noten-UK; reserved codes likeEU/UN/UKhave no effect as regions. You can target a language alone but never a region alone. Absolute URLs required. (The broader BCP 47 standard hreflang is built on also allows script subtags likezh-Hant— Google’s documented hreflang contract doesn’t extend that far.) - Hint, not directive (Mueller, May 2025): wrong hreflang is ignored, not penalized; Google can override it for same-language consolidation or indexing reasons.
- Canonicalization: self-referencing canonicals are the safe default; Google prefers URLs inside a complete reciprocal cluster over similar URLs outside it, but that’s a preference, not a promise. Pointing hreflang at a non-canonical, redirected, broken, or noindexed URL breaks the cluster.
- Bing is different: hreflang is “a far weaker signal than content-language at
Bing” (Canel). Pair hreflang (Google/Yandex) with
content-language+html langfor the rest. Baidu doesn’t support it at all. - It breaks constantly: in my Ahrefs study of 374,756 hreflang-using domains, 67%+ had an issue; the top miss was x-default (56.3%).
- Audit it visually: Ahrefs Site Audit’s Hreflangs tab was the first to draw the cluster as a graph with errors in red — far better than a spreadsheet. GSC’s International Targeting report was deprecated Sept 22, 2022.
Official documentation
Primary-source documentation from the search engines.
- Localized versions of your pages — the primary hreflang doc: the three methods, the reciprocity requirement, valid codes, and absolute-URL rule.
- Managing multi-regional and multilingual sites — geotargeting signals Google does and doesn’t use, URL-structure options, and the auto-redirect warning.
- Tell Google about localized versions (x-default blog, 2013) — the original introduction of
x-default. - International Targeting report deprecation (Sept 2022) — why the report was removed and what to use instead.
Bing / Microsoft
- Bingbot Series: Maximizing Crawl Efficiency — context on how Bing thinks about international/multilingual sites; Bing prioritizes
content-languageover hreflang. - Bing Webmaster Tools — Help & How-To — Bing’s webmaster guidance, including its preference for
content-languageandhtml langsignals.
Quotes from the source
On-the-record statements from Google and Bing.
Google — reciprocity is the core rule
- “Each language version must list itself as well as all other language versions.” — Google Search Central docs. Jump to quote
- “If two pages don’t both point to each other, the tags will be ignored.” — Google Search Central docs. Jump to quote
- “Alternate URLs must be fully-qualified, including the transport method (http/https).” — Google Search Central docs. Jump to quote
John Mueller, Google — hints, not directives
- “hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed.” — John Mueller, Search Advocate, Google (Bluesky, May 2025). Coverage
- On self-referential tags: hreflang self-references are “optional—but good practice.” — John Mueller, Google. Reference
Fabrice Canel, Microsoft Bing — a weaker signal at Bing
- “hreflang is indeed a far weaker signal than content-language at Bing.” — Fabrice Canel, Principal Program Manager, Microsoft Bing. Coverage
Hreflang implementation checklist
Pre-launch
- Decided on one implementation method (HTML head / HTTP headers / XML sitemap) and used it consistently — no mixing.
- Every page lists itself (self-referential tag) and all alternates.
- References are reciprocal — if A points to B, B points back to A.
- Language codes are valid ISO 639-1; region codes are valid ISO 3166-1
alpha-2 (
en-GB, noten-UK;ja, notjp). - URLs are absolute and fully-qualified (
https://…), and match the form Google actually indexes (trailing slash, www, protocol, case). - Added an
x-defaultif you have a country selector or global fallback (optional, but the most-missed item — see the x-default subtopic). - hreflang tags are in the
<head>(or HTTP header / sitemap), never injected into the<body>by JS or broken HTML. - Each variant canonicalizes to itself — no canonical pointing at another language version.
- No variant is noindexed or blocked in robots.txt.
- For Bing/Baidu: set correct
content-languageand<html lang>— don’t rely on hreflang there.
Post-launch audit
- Run Ahrefs Site Audit and open the Hreflangs tab — check for red (broken) pages and missing/incorrect return links in the cluster graph.
- Resolve the standard Site Audit checks: invalid annotation, missing
self-reference, missing reciprocal tag, non-canonical target, broken/
redirected target, more-than-one-page-per-language, hreflang/
html langmismatch. - Spot-check a few URLs with GSC URL Inspection (the International Targeting report was deprecated Sept 2022 — don’t look for it).
- Preview locale results manually with
&hl=and&gl=parameters on a Google search URL. - Re-audit after any URL change, redirect, or new locale — that’s when return tags rot.
Hreflang cheat sheet
Code format
hreflang="<language>" or hreflang="<language>-<region>"
- Language — ISO 639-1, two letters (required).
- Region — ISO 3166-1 alpha-2, two letters (optional, always after a language).
- Language-only (
es) targets that language anywhere; language+region (es-MX) targets that language in that country. - You can’t target a region by itself — there’s always a language first.
x-defaultis the fallback value for unmatched locales.
Common codes (and the ones people get wrong)
| You want | Correct | Common mistake |
|---|---|---|
| English (US) | en-US | — |
| English (UK) | en-GB | en-UK ❌ (uk = Ukrainian) |
| Spanish (Mexico) | es-MX | — |
| Japanese | ja | jp ❌ |
| Chinese (Simplified, China) | zh-CN | cn ❌ |
| German | de | ger ❌ (three letters) |
| All Spanish speakers | es | es-ES (over-narrows) |
| Global fallback | x-default | omitting it (56.3% do) |
Reserved / avoid: EU, UN, UK as region codes — not valid ISO 3166-1
alpha-2 region targets.
Implementation method — when to use each
| Method | Where it lives | Best for | Watch out for |
|---|---|---|---|
HTML <head> tags | each page’s <head> | small/medium sites | markup weight; tags in <body> are invalid |
HTTP Link headers | server response headers | non-HTML files (PDFs) | needs server/CDN config |
| XML sitemap | central xhtml:link entries | large sites, many locales | needs the xmlns:xhtml namespace; keep in sync |
Pick one per site. None is “faster” — all resolve at crawl time. Sitemaps are easiest to QA because the whole cluster is in one file.
The rules in one line each
- Reciprocal: A → B requires B → A, or the pair is ignored.
- Self-referential: every page lists itself (“optional—but good practice”).
- Absolute URLs: fully-qualified
https://…, matching the indexed form. - Hint, not directive: wrong hreflang is ignored, not penalized.
Resources worth your time
My related writing
- Hreflang: The Easy Guide for Beginners — my Ahrefs guide: definition, syntax, the three methods, the nine common issues and fixes, and how to audit (with the cluster visualization).
- Over 67% of Domains Using Hreflang Have Issues — my hreflang study of 374,756 domains, the largest ever run, and the source of the error-rate breakdown on this page.
My speaking
- Hreflang Study and Interesting Issues — Brighton SEO 2023 — the deck behind the study, plus Google’s most-specific matching (language+country → language → x-default) and the most common code mistakes.
- International SEO: The Weird Technical Parts — Pubcon Vegas 2019 — the contrarian details: hreflang depends on what’s indexed (not canonicalized), HTML vs. sitemaps resolve equally, head-section injection breaks tags, and auto-redirects risk both de-indexing and EU anti-geoblocking rules.
- You’re Going To Screw Up International SEO — Pubcon Vegas 2017 — the ecosystem of implementation chaos: tools giving wrong info, content served from different URLs than indexed, duplicate pages.
From others
- Google’s Localized versions of your pages — the primary doc; worth reading in full before any implementation.
- Google’s Managing multi-regional and multilingual sites — geotargeting signals Google uses (and explicitly ignores), URL-structure options, and the auto-redirect warning.
- Google Reminds That Hreflang Tags Are Hints, Not Directives — Search Engine Journal, May 2025 — covers John Mueller’s Bluesky clarification on same-language consolidation overrides.
- Bing Says Hreflang A Weak Signal For Its Search Engine — SEO Round Table — Fabrice Canel’s on-record statement that
content-languageoutweighs hreflang at Bing. - Hreflang Magic Trick Revealed — GSQI — Mueller quotes explaining how Google can surface a canonicalized URL in SERPs via hreflang (the same-language, multi-country edge case).
- r/TechSEO — the community for debugging broken hreflang clusters.
Hreflang
Hreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others.
Related: x-default, Multilingual SEO, International SEO
Hreflang
Hreflang is an attribute used in <link rel="alternate"> annotations that signals to search engines — primarily Google and Yandex — which language and (optionally) which geographic region a page is meant for, plus where the alternate versions of that page live. When a user searches, the engine can swap in the version that best matches their language and location.
It can be declared three ways: HTML <link> tags in the <head>, HTTP Link headers (useful for non-HTML files like PDFs), or xhtml:link elements inside an XML sitemap. You pick one method per site. The value combines an ISO 639-1 language code with an optional ISO 3166-1 alpha-2 region code — en, en-US, es-MX — and en-GB for UK English (not the invalid en-UK).
The hard part is that hreflang works as a cluster: every version must list itself and all the others, and the references must be reciprocal. If page A points to page B but B doesn’t point back, Google ignores the pair. It’s a hint, not a directive — wrong hreflang is ignored rather than penalized, and Google may still override it. In an Ahrefs study of 374,756 domains, over 67% of sites using hreflang had at least one issue.
Related: x-default, Multilingual SEO, International SEO
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Revision history
Compare the published article with an archived editorial snapshot. Added and removed words are shown only after you open a comparison.
Updated Jul 28, 2026.
Editorial summary and recorded change details.Summary
Added an anonymized hreflang migration example combining a redirected alternate with a missing reciprocal return.
Change details
-
Added the exact broken declarations, the resulting pair-level failure, and the corrected final-URL annotations.
Full comparison unavailable — no prior snapshot was archived for this revision.
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Tightened evidence-gated qualifications on the definition, code contract, delivery methods, reciprocity, and canonicalization sections against current Google docs.
Change details
-
Scoped hreflang to a Google selection signal, not a guarantee of indexing, ranking, traffic, which URL displays, or AI citation.
-
Distinguished Google's documented language+region hreflang contract (with reserved codes having no effect) from the broader BCP 47 standard's script subtags.
-
Stated explicitly that Google treats HTML, HTTP headers, and XML sitemaps as equivalent with no Search benefit to using more than one.
-
Added that Google can still process correctly reciprocal pairs even when another pair in the same cluster is broken.
-
Added Google's canonical guidance preferring URLs inside a complete reciprocal hreflang cluster, framed as a preference rather than a guarantee.