What IETF Language Tags and Hreflang Annotations Actually Require — and What They Don't

Google's hreflang specification is defined by three hard requirements. Get any one wrong and the entire annotation set is silently dropped — no error in Search Console, no crawl warning, just Google reverting to its own judgment about which page to serve in which market.

Rule 1: Valid IETF BCP 47 Language Codes

Language values must follow IETF BCP 47, not ISO 639-1 alone. For most languages, a two-letter code is sufficient (en, fr, de). For region-specific variants, append a region subtag: en-GB, fr-CA, pt-BR. For script variants — particularly Chinese — use script subtags: zh-Hant (Traditional) and zh-Hans (Simplified). Using zh-TW as a script signal is technically a region code, not a script code, and can produce ambiguous results.

Rule 2: Self-Referencing Tags

Every page in a hreflang set must include a tag pointing to itself. A page targeting en-US must carry both the self-reference and annotations for every other locale in the set. Omitting the self-reference is one of the most common errors in hreflang implementations, and it causes that page's signals to be treated as incomplete.

Rule 3: Full Reciprocity

If Page A references Page B, Page B must reference Page A. This applies across every URL in the set. A four-locale implementation means each page carries four hreflang tags — one per locale plus its own. When a site adds a new locale but only updates one page, the broken reciprocity invalidates hreflang signals across the entire set.

A minimal valid HTML implementation looks like this:

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/page/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

Each of those three URLs must carry all three tags. That is the minimum structure for a compliant two-locale set with an x-default fallback.

x-default is not a catch-all for unmatched languages. It is a signal to Google identifying which URL to serve when no explicit locale match exists in your hreflang set. That distinction matters in implementation.

When x-default Is Appropriate

• A language-selector or region-picker landing page that routes users to the correct locale
• A global homepage in English that serves markets not covered by other hreflang annotations
• An e-commerce site where the default shopping experience is in one language/currency, with regional variants for specific markets

When x-default Creates Problems

If x-default points to a page that immediately redirects based on browser language detection, you introduce a redirect chain that Google may or may not follow correctly. The x-default URL should be a stable, crawlable destination — not an intermediate redirect.

Similarly, pointing x-default to a page that is itself canonicalized to another URL creates an immediate conflict. Google receives a hreflang annotation pointing to URL A, then a canonical saying URL A defers to URL B. The annotation is discarded.

x-default Is Optional

Many sites omit x-default entirely when every served language is explicitly covered. This is a valid approach. The tag only adds value when you have a meaningful fallback experience. Adding it to every page regardless of whether a true fallback page exists does not improve performance and can introduce confusion if it points to inconsistent destinations across page types.

As a practical rule: if your site has a language-selector homepage that covers all unmatched users, use x-default there. If every page exists in every supported language and there is no fallback state, omit it.

Canonical tags and hreflang annotations interact in ways that most CMS platforms do not handle correctly by default. The conflict pattern is predictable and widespread across multilingual WordPress, Shopify, and headless implementations.

The Core Conflict Pattern

Hreflang requires that the URL referenced in the annotation be the canonical URL for that page. If your en-GB page has a hreflang self-reference pointing to https://example.com/en-gb/service/ but its canonical tag points to https://example.com/service/, Google sees a contradiction. The canonical says: this URL is not the authoritative version. The hreflang says: use this URL for English/UK users. Google resolves this by trusting the canonical and dropping the hreflang signal.

Common CMS Causes

• Yoast SEO on WordPress: If a translated page's canonical is set to the original language URL by default (a plugin misconfiguration), all hreflang annotations on translated pages are invalidated
• Shopify markets: URL structure changes between the default and secondary markets can produce canonical mismatches if not explicitly configured
• Pagination: Paginated alternate pages sometimes carry a canonical pointing to page 1, which conflicts with hreflang annotations on pages 2 and beyond

How to Audit for This

For each URL in your hreflang set, confirm that the canonical tag value exactly matches the href value in that page's self-referencing hreflang annotation. They must be identical — including trailing slash, protocol, and subdomain. A mismatch at any point in the set can cascade, because the broken reciprocity it creates affects every other page in the group.

This is one of the diagnostic checks we run first in any multilingual site audit, because it is the conflict type most likely to explain why hreflang appears correctly implemented but produces no observable effect in search targeting.

Google accepts hreflang signals through three channels: HTML <head> tags, HTTP response headers, and XML sitemaps. Each has legitimate use cases. Mixing methods across the same site without a clear architecture rationale tends to produce conflicts.

HTML Head Tags

The most common method and the most straightforward for HTML pages. Tags are placed in the <head> of each page. The disadvantage: on large sites with many locales, this adds significant markup volume to every page — a minor but real rendering overhead. It also requires that every page's template be updated when a new locale is added, which on complex CMS environments creates deployment risk.

HTTP Headers

The only valid method for non-HTML resources: PDFs, images, or other files that cannot carry markup. For HTML pages, HTTP header implementation is technically valid but rarely used because it requires server configuration rather than template changes — more reliable on some stacks, more complex to audit.

XML Sitemaps

The preferred method for large sites (typically above a few hundred localized URLs). Hreflang is declared in a dedicated sitemap using the xhtml:link element within each <url> block. The full reciprocal set must still be declared — the sitemap approach does not relax any syntax requirements. The advantage is centralized management: when a new locale is added, only the sitemap file needs updating, not every page template.

Do not use multiple methods simultaneously for the same pages. If HTML tags and sitemap annotations conflict — for example, if a new locale was added to the sitemap but not yet to templates — Google receives contradictory signals. The safest architecture is a single implementation method per site, applied consistently across all localized pages.

For most new multilingual builds, XML sitemaps are the recommended default unless the site is small and the development team has strong template control.

Google Search Console's International Targeting report is the primary diagnostic tool for hreflang errors. Understanding what it does — and does not — surface is important for accurate interpretation.

What the Report Shows

• Language targeting errors: Pages where hreflang annotations reference invalid language codes (e.g., en_US instead of en-US)
• Return tag errors: Cases where a referenced URL does not include a reciprocal annotation pointing back
• No return tag: Specific URLs in your set that are missing the reciprocal link

What the Report Does Not Show

GSC does not report canonical conflicts with hreflang. It does not flag x-default pointing to a redirect. It does not alert you when hreflang annotations exist but are being ignored due to canonical issues. Many of the most impactful hreflang problems are invisible in GSC and require crawl-level diagnosis using tools like Screaming Frog, Sitebulb, or a custom crawl script that cross-references canonical and hreflang values simultaneously.

Validation Workflow

1. Check the International Targeting report for explicit errors and resolve all flagged issues first
2. Run a full crawl of your localized URLs and export both the canonical URL and all hreflang annotations per page
3. Cross-reference: for each URL, confirm the hreflang self-reference matches the canonical exactly
4. Verify reciprocity: for every hreflang annotation on every page, confirm the referenced URL carries a return annotation
5. Confirm x-default (if used) points to a non-redirecting, indexable URL

After resolving errors, allow two to four weeks for Google to recrawl and reprocess the annotations before assessing whether targeting has improved. Hreflang processing is not instantaneous — changes take effect as pages are recrawled, not at the moment of deployment.

This content covers general technical standards. Verify current Google documentation for any specification changes, as hreflang guidance has evolved over time and may continue to.

Several common site architectures and development patterns create predictable hreflang failures. Understanding the risk pattern helps prioritize where to focus an audit.

Migration Without Hreflang Redirect Mapping

When a multilingual site migrates to a new URL structure — for example, from subdomain-based localization (fr.example.com) to subdirectory-based (example.com/fr/) — the hreflang set must be fully rebuilt with the new URLs. Redirect chains between old and new locale URLs do not transfer hreflang signals. In our experience working with multilingual sites post-migration, this is the scenario that most reliably causes a complete loss of locale targeting, often undetected for months.

Partial Localization

Sites that translate high-priority pages but leave the rest in the default language face a structural problem: the hreflang set for a translated page must include every supported locale. If the fr-FR version of the homepage exists but the fr-FR version of product pages does not, the homepage hreflang set can still be valid — but only if the product pages do not incorrectly carry hreflang tags pointing to non-existent French URLs. A common error is generating hreflang tags automatically for all pages regardless of whether translated versions exist, creating annotations that reference 404 or redirect-destination URLs.

CDN and Caching Layers

Some CDN configurations strip or modify HTTP headers, which affects header-based hreflang implementations. Separately, aggressive caching can serve stale HTML containing outdated hreflang sets to Googlebot after a locale is added or removed. After any hreflang change, confirm that Googlebot is receiving the current version of each affected page by using the URL Inspection tool in GSC to fetch a live version.

JavaScript-Rendered Hreflang

Hreflang tags injected by client-side JavaScript are not reliably processed by Google. Google does render JavaScript, but hreflang annotations need to be present in the initial HTML response to be treated as authoritative. If your CMS or framework relies on JavaScript to inject <link rel="alternate"> tags, verify via the URL Inspection tool that those tags appear in the rendered HTML Google actually sees.