Hreflang: The Complete Implementation Guide for 2026

Hreflang tells Google which language and regional version of a page to serve to users in different countries. Done correctly, it prevents duplicate-content confusion between near-identical pages and ensures the right market sees the right page. Done incorrectly — which is common, since hreflang is one of the more error-prone tags in technical SEO — it can cause the wrong-language page to rank in the wrong market, or cause Google to ignore the signal entirely.

The core rules

A handful of rules cover most real-world hreflang implementations:

• Every page must link to all of its alternates, including itself. If your English page links to French and German alternates, the English page’s own hreflang block also needs a self-referencing entry for English.
• Always include an x-default tag. This tells Google (and browsers that support it) which version to show visitors whose language/region doesn’t match any of your specific alternates — typically your primary or international version.
• Use absolute URLs only. Relative paths are a common cause of silent hreflang failures, since the tag’s meaning depends entirely on an unambiguous full URL.
• Hreflang entries must match your sitemap’s hreflang entries exactly. If you implement hreflang via both HTML tags and an XML sitemap, any mismatch between the two is treated as a conflicting signal.
• Use the correct format. Language codes are ISO 639-1 (en, de, fr), and when a region is included it’s ISO 3166-1 Alpha 2, joined with a hyphen — en-US, not en_US and not US-en.

Common mistakes, in order of how often we see them

Missing return links. This is the single most common hreflang error. If page A declares an alternate pointing to page B, page B must declare an alternate pointing back to page A. One-directional hreflang links are effectively ignored by Google, because the reciprocity is what confirms the relationship is intentional rather than accidental.

Pointing hreflang at a redirect. If the URL in an hreflang tag 301-redirects somewhere else, that signal is wasted — hreflang tags should always point directly at the final destination URL, not an intermediate redirect.

Underscore instead of hyphen. en_US is a common but invalid format; browsers and crawlers expect the hyphenated en-US.

No x-default tag present. Without it, there’s no defined fallback for visitors who don’t match any declared alternate, which is a particularly common gap on sites that only recently expanded into a second market.

A worked three-market example

For a page available in a default/international English version, a US-specific version, and a German version, the hreflang block on every one of those three pages should be identical, listing all three (plus x-default):

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

The one difference between the three pages’ hreflang blocks would be which URL each treats as canonical — but the set of alternates listed stays the same across all three, which is what satisfies the reciprocal-link requirement.

When you only have one version

Sites with a single language/region don’t need a complex hreflang cluster at all — in fact, adding one prematurely (declaring alternates for markets that don’t have real localized pages yet) is a common self-inflicted hreflang error. Google’s own recommendation for single-version sites is a minimal, self-referencing hreflang setup: an x-default tag and one language tag, both pointing at the same URL. It’s not required, but it’s a safe, zero-risk baseline that avoids the reciprocity problem entirely, since the only “alternate” a page has is itself.