Hreflang

Hreflang is a link annotation telling search engines which language and regional version of a page to serve to users in different languages or regions. The annotation connects alternate versions of the same content into a cluster, allowing search engines to substitute the most fitting URL in their results based on the searcher's language. Hreflang is delivered through the HTTP Link header, HTML <link> elements, or XML sitemaps.

Table of Contents

Usage
HTTP Link header
Language tags
x-default
Self-referencing
Reciprocal references
Content-Language vs hreflang
Search engine support
Common mistakes
Best practices
Example
Takeaway
See also

Usage

Websites serving content in multiple languages face a deduplication problem. When the English and German versions of a page share the same structure, images, and navigation, search engines see near-duplicate content and fold the pages together, picking one canonical URL and suppressing the others. Hreflang annotations solve this by declaring the relationship between language variants explicitly, preventing canonical folding and ensuring each variant appears in search results for the right audience.

Hreflang is about language, not geography. The annotation signals a page exists in a specific language, optionally refined by region. Setting hreflang="de" means "this page is in German." Adding a region code like hreflang="de-CH" means "this page is in German as used in Switzerland." Treating hreflang as a geotargeting tool is the most common implementation mistake.

Signal, not directive

Hreflang annotations are signals, not directives. Search engines treat them as hints and combine them with on-page language detection, ccTLD, local links, and other signals to determine targeting. Hreflang does not directly improve rankings. The effect is showing the correct language variant in search results, which improves click-through rates and conversions.

HTTP Link header

The HTTP Link header delivers hreflang annotations as comma-separated link values, each with rel="alternate" and a hreflang attribute.

Link: <https://example.re/page>; rel="alternate"; hreflang="en", <https://example.re/de/page>; rel="alternate"; hreflang="de", <https://example.re/fr/page>; rel="alternate"; hreflang="fr", <https://example.re/page>; rel="alternate"; hreflang="x-default"

Every language variant must return the identical set of Link entries. The English page, the German page, and the French page all return the same Link header listing all three versions plus the x-default fallback.

The HTTP Link header is the preferred delivery method for non-HTML resources (PDFs, images, API responses, and other files) where HTML <link> elements are not available. Server configuration (Nginx add_header, Apache Header set) or edge-level injection through a CDN adds hreflang without modifying document content.

SEO

The HTTP Link header is processed before the HTML body arrives. For HTML pages, the practical effect is the same as HTML <link> elements. Google considers all three methods equivalent. Choose one method per page to avoid conflicting signals.

Language tags

Hreflang values use BCP 47 language tags. The most common forms are a language code alone or a language-region pair.

Tag	Meaning
`en`	English
`de`	German
`pt-BR`	Portuguese (Brazil)
`zh-Hans`	Chinese (Simplified script)
`de-CH`	German (Switzerland)
`zh-Hant`	Chinese (Traditional script)
`sr-Latn`	Serbian (Latin script)
`x-default`	Fallback for unmatched languages

The full BCP 47 specification supports language, extlang, script, region, and variant subtags (lang-extlang-script-region-variant). In practice, lang and lang-region cover the vast majority of use cases.

Google's supported formats

Google processes these hreflang tag formats: language alone (de), language-region (de-CH), language-script (zh-Hans), and language-script-region (zh-Hans-US). Language codes follow ISO 639-1, region codes follow ISO 3166-1 alpha-2, and script codes follow ISO 15924. UN M.49 numeric region codes (es-419) are not supported.

Language codes

Language codes follow ISO 639-1 (two-letter codes). Common codes: en, de, fr, es, pt, ja, zh, ko, ar, ru, nl, it, pl.

Region codes

Region codes follow ISO 3166-1 alpha-2 (two-letter country codes): US, GB, DE, BR, MX, CH, AT. UN M.49 numeric codes (419 for Latin America, 150 for Europe) are valid BCP 47 but Google does not support them.

Script codes

Script codes follow ISO 15924 (four-letter codes) and distinguish writing systems: Hans (Simplified Chinese), Hant (Traditional Chinese), Latn (Latin), Cyrl (Cyrillic). Google supports script subtags, making zh-Hans and zh-Hant valid alternatives to the region-based zh-CN and zh-TW.

Language matching

A tag like de matches de-DE, de-AT, de-CH, and all other German variants. A more specific tag like de-CH matches only Swiss German variants. Use the broadest tag accurately describing the content. de is sufficient when the German content is not regionalized.

x-default

The x-default value designates a fallback page for users whose language or region does not match any other hreflang annotation in the cluster. A language selector page or the primary language version typically serves as x-default.

Link: <https://example.re/>; rel="alternate"; hreflang="x-default"

Only one x-default entry exists per URL cluster. While technically optional, including x-default is a best practice. The x-default value provides a catch-all for the global audience and improves conversion rates for languages not explicitly covered.

Self-referencing

Every page in a hreflang cluster must include a self-referencing entry pointing back to its own URL with its own language tag. The English page lists itself as hreflang="en", the German page lists itself as hreflang="de", and both pages list all other variants.

Missing self-references risk the entire annotation cluster being ignored. The self-reference also acts as a confirmation: search engines verify each page in the cluster acknowledges its own membership.

Reciprocal references

Hreflang annotations require bidirectional confirmation. If page A references page B as an alternate, page B must reference page A in return. Unmatched references are ignored. This reciprocal requirement authenticates the cluster. A third party linking to a page with hreflang does not create a valid annotation.

When any page in the cluster fails to reference the others, or references a URL returning a non-200 status, a redirect, or a non-canonical URL, the entire cluster risks being discarded.

Content-Language vs hreflang

The Content-Language header and hreflang serve different purposes. Content-Language describes the intended audience language of the current document. Hreflang points to alternate versions of the same content in other languages. A German-language page sets Content-Language: de to describe itself and uses hreflang annotations to point to the English, French, and Spanish versions.

Google does not use Content-Language or the HTML lang attribute as primary language signals. Google detects content language algorithmically. Hreflang communicates intent about alternate versions, not the page's own language.

Alignment

While Google relies on algorithmic language detection, aligning all language signals (hreflang annotations, HTML lang attribute, Content-Language header, and on-page content language) avoids conflicting signals across search engines. Bing and Baidu rely on the Content-Language meta tag and HTTP header rather than hreflang.

Search engine support

Google fully supports hreflang through all three delivery methods: HTTP Link header, HTML <link> elements, and XML sitemaps. Google treats all three methods as equivalent.

Yandex supports hreflang through HTML <link> elements and XML sitemaps. Yandex has deprecated sitemap-based hreflang in favor of HTML markup. HTTP Link header support is undocumented.

Bing does not support hreflang. Bing processes hreflang as a weak signal at best and primarily relies on the Content-Language meta tag, HTML lang attribute, and on-page language signals.

Baidu and Naver do not support hreflang and rely on meta tag language annotations.

Common mistakes

Using hreflang as geotargeting. Hreflang is a language signal. Setting hreflang="en-US" alone does not geotarget the United States. The tag specifies English as used in the US. The annotation works together with other signals (ccTLD, local links, business profiles) for geographic targeting.

Missing self-reference. Each page must reference itself. Omitting the self-reference is technically allowed but frequently causes the cluster to be ignored.

Missing reciprocal references. If page A lists page B but page B does not list page A, the pair is ignored. Every page must list every other page in the cluster.

Invalid language codes. Using uk (Ukrainian language code) when meaning United Kingdom (GB is the correct region code), or regional codes like eu, la, or me. The deprecated code iw (Hebrew) is replaced by he.

Region code without language code. A tag like US alone is invalid. The language code always comes first: en-US, not US.

Relative URLs. Hreflang URLs must be fully-qualified absolute URLs. Protocol-relative URLs (//example.re/page) and path-only URLs (/page) break annotations.

Pointing to non-200 pages. Alternate URLs returning redirects, 404 errors, or non-canonical URLs invalidate the annotation.

Conflicting canonical and hreflang URLs. When rel="canonical" points to a different URL than what hreflang references, signals conflict and search engines lose trust in the cluster.

Mixing languages on one URL. Serving two different languages on the same URL (e.g., /es/ for both Spanish and Italian) or using side-by-side translations confuses language detection.

Auto-translated content. Allowing automatically translated pages to be crawled and indexed risks being classified as auto-generated content, which harms overall content quality trust signals. Content quality policies have shifted on this topic. Review current search engine guidelines before relying on machine translation.

SEO

Errors anywhere in a hreflang cluster affect the entire cluster. When one page has broken reciprocal references or points to a redirecting URL, search engines risk ignoring all annotations in the cluster. Audit hreflang clusters regularly using Google Search Console's URL Inspection tool to check for canonical folding.

Best practices

Simplify. Not every page needs hreflang for every language on the site. Focus on languages and regions where content competes, similar languages receiving traffic from the wrong country. Check Google Search Console and analytics to identify mismatch patterns before adding annotations.

Use language-only tags when possible. A single hreflang="de" covers all German-speaking regions. Add region codes (de-DE, de-AT, de-CH) only when the content is genuinely regionalized with different products, pricing, or terminology.

Start with homepages. Brand names are often not localized, making homepages the most common source of canonical folding across languages. Adding hreflang to language homepages provides immediate value with minimal complexity.

Deep cross-link between variants. Hreflang annotations are invisible to users and do not pass link signals. Include visible links between language versions in the page body (language selectors pointing to the equivalent page, not the homepage) to pass link equity and provide navigation.

Avoid IP-based redirects. Redirecting users based on IP address or the Accept-Language header blocks search engine crawlers from accessing all variants. Offer a subtle language banner instead.

Always include x-default. The fallback entry catches all unmatched language and region combinations, ensuring every visitor reaches an appropriate page.

Example

A website with English, German, and French versions of a page. Each language variant returns the same set of Link headers.

English page response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en
Link: <https://example.re/about>; rel="alternate"; hreflang="en", <https://example.re/de/about>; rel="alternate"; hreflang="de", <https://example.re/fr/about>; rel="alternate"; hreflang="fr", <https://example.re/about>; rel="alternate"; hreflang="x-default"

German page response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: de
Link: <https://example.re/about>; rel="alternate"; hreflang="en", <https://example.re/de/about>; rel="alternate"; hreflang="de", <https://example.re/fr/about>; rel="alternate"; hreflang="fr", <https://example.re/about>; rel="alternate"; hreflang="x-default"

Both pages return the identical Link header. The self-reference (hreflang="en" pointing to the English page, hreflang="de" pointing to the German page) and the x-default fallback are present in each response. Google, encountering both responses, confirms the bidirectional references and registers the cluster.

A PDF served with hreflang via HTTP headers, the only delivery method available for non-HTML resources.

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Language: en
Link: <https://example.re/report.pdf>; rel="alternate"; hreflang="en", <https://example.re/de/report.pdf>; rel="alternate"; hreflang="de"

Takeaway

Hreflang annotations connect language and regional variants of a page into a cluster, allowing search engines to serve the most appropriate version in their results. The HTTP Link header delivers hreflang for non-HTML resources and server-configured deployments. Hreflang is a language signal, not a geotargeting tool. Focus on language-only tags where possible, ensure bidirectional references across all variants, and include x-default as a global fallback.

Note

For international SEO and hreflang assistance, contact ex-Google SEO consultants Search Brothers.