Hreflang tells Google which version of a page to show users based on their language and country. The mechanism is simple in concept and treacherous in implementation. Most hreflang failures come from mistakes a careful audit catches before they reach production.
Hreflang was introduced by Google in 2011 to handle the multilingual and multinational web. A site serving content in multiple languages or targeting multiple countries uses hreflang to tell Google which version corresponds to which language-country combination. When the implementation works, users in France see French content, users in Germany see German content, and users in Spain see Spanish content. When the implementation fails, users see the wrong language version or no version at all, and the site ranks worse in international markets than it should.
Here’s the picture: what hreflang actually signals, the implementation patterns that work, and the specific mistakes that consistently break it.
What hreflang signals:
A hreflang tag tells Google two things about a page: which language it’s in, and (optionally) which country it targets. The format:
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />The hreflang attribute value uses ISO language codes (de for German, en for English, fr for French) and optionally ISO country codes (us for United States, gb for Great Britain, ca for Canada). The combination “en-us” means English content targeted at the United States.
The x-default value indicates which page should serve as the fallback when no other version matches the user’s language or location.
When Google trusts the hreflang implementation, the right version appears in each market’s search results. The user clicks a Google result and lands on the page in their language.
The three places hreflang can live:
Hreflang can be implemented in three locations, with the same effect when done correctly:
| Location | When it makes sense |
|---|---|
| <strong>HTML head</strong> | Most common. Works for any HTML page. Visible in source. |
| <strong>HTTP headers</strong> | Works for non-HTML resources (PDFs, etc.) or when HTML modification isn't practical. |
| <strong>XML sitemaps</strong> | Scales well for large sites with many language/country versions. Centralized management. |
The three methods are equivalent in terms of how Google processes them. Sites typically pick one and stick with it; mixing methods (some pages with HTML hreflang, some with sitemap-only) works but adds maintenance complexity.
For most sites, HTML head implementation is the easiest path. The tags get included automatically by the CMS or template; verification is straightforward (view source); debugging is direct.
For very large sites (10,000+ pages with multiple language versions), sitemap-based hreflang scales better. The hreflang relationships live in the sitemap XML, which the CMS generates once. The HTML pages don’t need per-page hreflang management.
The reciprocal requirement:
The single most important rule about hreflang: every reference must be reciprocal. If page A says “page B is the German version of me,” page B must say “page A is the English version of me.”
The pattern:
Page A (English at /page):
<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />Page B (German at /de/page):
<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />Both pages reference both versions, including themselves. Google processes the implementation only when the references are reciprocal across all language versions.
The most common implementation failure: page A points to page B as the German version, but page B doesn’t point back. Google sees the broken relationship and ignores the hreflang signals entirely for these pages.
The pattern that prevents the failure: build hreflang from a centralized source (a translation management system, a CMS field, or a database) that ensures both sides of every relationship get generated correctly. Manual hreflang implementation across many pages is error-prone.
John Mueller has reinforced this position repeatedly in Google Search Central Office Hours sessions through 2024 and 2025: hreflang failure on the reciprocal requirement is the single most frequent international SEO problem submitted for diagnosis, and the fix is structural (centralized generation) rather than per-page editorial work.
Language and country code accuracy:
The codes used in hreflang must match the ISO standards Google expects:
- Language codes: ISO 639-1 (two-letter codes). “en” for English, “de” for German, “ja” for Japanese, “zh” for Chinese.
- Country codes: ISO 3166-1 alpha-2 (two-letter codes). “us” for United States, “gb” for Great Britain (not “uk”), “cn” for China, “br” for Brazil.
Common mistakes:
- “uk” instead of “gb”: the ISO code for the United Kingdom is “gb,” not “uk.” Google specifically doesn’t recognize “uk” as a hreflang country code.
- Mixing language and country. “en-uk” is wrong (the country code is “gb,” not “uk”); “english-us” is wrong because “english” isn’t a language code (it’s “en”); “fr-france” is wrong because “france” isn’t a country code (it’s “fr” for France).
- Capitalization variations. Hreflang values aren’t case-sensitive in Google’s parsing, but mixing “EN-US” and “en-us” across the site indicates inconsistent implementation.
- Region codes that aren’t countries. “en-eu” doesn’t work because “eu” isn’t a country code. There’s no way to target “Europe” generally through hreflang; sites either pick specific countries or use language-only targeting.
The codes that work for common cases:
| Target | Code |
|---|---|
| English globally | en |
| English in United States | en-us |
| English in United Kingdom | en-gb |
| German in Germany | de-de |
| German globally (including Austria, Switzerland) | de |
| Spanish in Spain | es-es |
| Spanish in Mexico | es-mx |
| Chinese simplified | zh-hans |
| Chinese traditional | zh-hant |
The x-default tag:
The x-default value specifies which page to show when no other hreflang version matches the user’s language or location.
When x-default helps:
- Fallback for unmatched markets. A user in a country the site doesn’t specifically target sees the x-default page.
- Language selection pages. A landing page that lets users choose their language can be marked as x-default.
- The primary site version. Sites with one primary version and several localized versions can mark the primary as x-default.
When x-default isn’t necessary:
- Sites that target only one language with country variations. If the only versions are English-US, English-UK, and English-CA, language-only hreflang (“en”) may suffice as the fallback.
- Sites where every market has a specific version. If hreflang covers every plausible visitor, x-default has no role.
The technical detail: x-default isn’t required, but most sites benefit from including it. The fallback behavior without it depends on Google’s heuristics; with it, the behavior is explicit.
Implementation in HTML head:
The basic pattern in the HTML head:
<head>
<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</head>Every language version of the page includes the same set of hreflang tags. The tags reference all known versions, including the page’s own version (self-referencing tag).
Implementation considerations:
- Generate from templates. Manual hreflang tag management across hundreds of pages produces errors. The tags should be generated automatically based on the translation relationships stored in the CMS.
- Verify the rendered HTML. Some frameworks output hreflang tags differently in different rendering contexts. View source on production pages confirms the tags exist as expected.
- Don’t include hreflang for non-existent pages. A reference to a page that returns 404 breaks the entire hreflang cluster for affected pages.
Implementation in XML sitemaps:
For large sites, sitemap-based hreflang is the cleaner pattern:
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>
<url>
<loc>https://example.com/de/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>The sitemap pattern requires:
- Every URL in the sitemap with hreflang must include all language alternates as
<xhtml:link>elements. - The reciprocal requirement still applies; every URL’s hreflang block must match every other URL’s hreflang block.
- The sitemap needs to be submitted to Google Search Console and accessible at a public URL.
The advantage over HTML implementation: the relationships are managed in one place (the sitemap generation logic), and individual pages don’t need template changes.
Verification and debugging:
Verifying hreflang implementation involves several checks.
Google Search Console’s International Targeting report is the starting point. The report shows hreflang implementation issues Google has identified during crawling: missing return tags, invalid codes, and similar problems. Google retired the older “International Targeting” UI in 2022, but the underlying data continues to surface through Search Console’s main coverage reports and through the URL Inspection tool.
Third-party hreflang validators catch what Search Console misses. Tools like Merkle’s hreflang tester, Ahrefs’ hreflang validator, Sitebulb’s hreflang report, and Screaming Frog’s hreflang audit (added to the v18 release in 2023 and improved through v20 in 2025) crawl the implementation and report inconsistencies that Search Console’s report may not surface.
Manual verification of sample pages is the deepest check. Pulling the HTML source for representative pages across language versions and verifying the tags match expectations catches issues before they propagate.
Monitoring international search results confirms the end result. Searches in Google.de for the site’s content should show German pages, not English pages. Searches in Google.fr should show French pages. Drift from expected behavior signals hreflang problems even when the implementation looks correct.
Common hreflang mistakes:
Patterns that recur across implementations:
- Missing return tags. Page A points to B and C; B and C don’t point back. The hreflang cluster breaks.
- Pointing to URLs that 404 or redirect. A hreflang reference to a non-200 URL is invalid; Google may ignore the cluster.
- Mixed language codes. Some pages use “en” and others use “en-us” for the same content. Inconsistency signals broken implementation.
- Self-referencing tags missing. Each language version’s hreflang block should include a tag pointing to itself; some implementations skip this.
- Country codes used where language codes are needed. “us” alone (without a language) isn’t valid hreflang.
- Translating only some pages. A category page has hreflang for many languages; the products within it don’t. The hreflang signal is incomplete.
- Different hreflang sets on different pages. Page A’s block lists 10 languages; page B’s block lists 8. The discrepancy suggests management errors.
The mistakes share a common root: hreflang is generated inconsistently or manually rather than from a centralized source. Sites with strong implementations have a single source of truth for hreflang relationships; sites with weak implementations have ad-hoc tags scattered across templates.
Robots.txt interactions that break hreflang:
Hreflang fails silently when robots.txt blocks the URLs hreflang declares. The most common pattern:
# WRONG: blocking language directories that hreflang references
User-agent: *
Disallow: /de/
Disallow: /fr/Hreflang tags on /en/page declare <link rel="alternate" hreflang="de-DE" href="https://example.com/de/page">, but the robots.txt blocks /de/. Googlebot can’t crawl the German version, can’t verify the reciprocal hreflang relationship, and treats the hreflang cluster as broken.
The correct pattern:
# RIGHT: allow language directories; control indexation through other signals
User-agent: *
Allow: /en/
Allow: /de/
Allow: /fr/
Disallow: /en/admin/
Disallow: /de/admin/
Disallow: /fr/admin/If specific language versions shouldn’t be indexed (a staging German site, a country version under development), use noindex meta tags rather than Disallow, because hreflang depends on crawlability to establish the relationship cluster. The principle: hreflang’s reciprocal requirement and robots.txt’s crawl-blocking are mutually exclusive for the same URL.
Hreflang lives in the operations layer:
Hreflang is the operational layer of international SEO. The domain strategy (ccTLD, subdomain, subdirectory) sets the framework; hreflang fills in the language and country relationships within that framework.
The discipline that produces working hreflang: centralized generation from translation management data, automated verification in CI/CD pipelines, monitoring of Search Console reports, and periodic manual audits to catch drift.
The sites that struggle with hreflang are typically sites where the implementation evolved organically across teams without central coordination. Marketing added a French page; product added a Japanese page; SEO tried to retrofit hreflang afterward. The retrofit is harder than upfront design; the resulting implementation tends to have inconsistencies that slowly degrade as more pages get added.
The strategic principle: hreflang is infrastructure, not content. The pattern works when it’s generated systematically from the translation relationships; it breaks when it’s managed page by page.