Hreflang Tags Explained: Why 75% of Sites Get Them Wrong

A site runs an English and a Spanish version of the same page, adds hreflang tags to tell Google which is which, and keeps showing the English version to Spanish searchers anyway. The tags are there. They're just wrong in a way that makes Google ignore them completely rather than throw an error — which is exactly why hreflang problems are so common and so rarely caught.

A study cited by international SEO agency LinkGraph found that roughly 75% of websites using hreflang tags have at least one technical error in their implementation. That's not a niche mistake — it's closer to the norm, because hreflang is one of the few technical SEO signals where a single broken link in a large set silently breaks the whole set, with no visible symptom beyond "the wrong language keeps showing up."

What hreflang tags actually do

Hreflang tags explained simply: they tell Google which language and region a specific page is meant for, and which URLs are the equivalent pages in other languages. If you run /en/pricing and /es/pricing, hreflang tags on each page tell Google "these are the same content, in different languages — show the right one to the right searcher" instead of treating them as duplicate or unrelated content.

Without hreflang, Google has to guess which version to rank for a Spanish-language query, and it might pick the English page, split ranking signals between both versions, or flag them as near-duplicate content competing against each other instead of complementing each other.

Why hreflang tags must be reciprocal

This is the single most common failure point, and it's structural, not a typo. Google's own hreflang documentation is explicit: hreflang annotations must be bidirectional. If /en/pricing declares /es/pricing as its Spanish equivalent, /es/pricing must also declare /en/pricing back. If either direction is missing or mismatched, Google ignores the entire annotation set for that page — not just the broken link, the whole cluster.

That reciprocal requirement scales badly with more languages. A site with 10 language versions of one page needs 10 hreflang tags per page (including a self-referencing one), across all 10 pages — 100 total annotations that all have to stay synchronized. One page added, removed, or renamed without updating every other page's hreflang list breaks the entire group silently.

The specific mistakes that break hreflang

Missing the self-referencing tag. Every page in a hreflang set needs to include a tag pointing to itself, not just to the other language variants. Without it, Google can't reliably process the cluster at all.

Wrong language or region codes. This is where hreflang gets deceptively technical: codes are case-sensitive by convention (language lowercase, region uppercase — en-US, not EN-us), three-letter codes aren't supported, and some codes are commonly confused — "uk" is the ISO code for Ukrainian, not the United Kingdom (that's "gb"). A single wrong code silently invalidates that language's entry.

Missing x-default. This tag tells Google which page to show when no other hreflang variant matches a visitor's language or region — typically the homepage or a language-selector page. Without it, Google decides on its own, which may not be the page you'd choose.

Hreflang and canonical tags contradicting each other. Each language version should have a canonical tag pointing to itself, not to one "master" version. If the Spanish page's canonical points to the English page, that directly contradicts the hreflang tag claiming the Spanish page is a distinct, intentional version — Google gets two conflicting signals about the same URL. See how canonical tags work for the full mechanic if this is new territory.

Pointing to broken or redirected URLs. Every URL referenced in a hreflang set needs to return a clean 200 status. A URL that's been moved, deleted, or redirected without updating every hreflang reference to it breaks the same way a dead link does anywhere else on a site.

Reading a hreflang tag

A correctly formed hreflang tag in a page's <head> looks like this:

<link rel="alternate" hreflang="es" href="https://example.com/es/pricing" />
<link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

Each line names a language (or x-default) and the exact URL of that version. Ahrefs' hreflang guide notes that hreflang can also be declared in an XML sitemap instead of in each page's <head> — often the more manageable option for large sites, since it centralizes all the annotations in one file instead of scattering them across every page template.

How to check your hreflang implementation

Because the failure mode is silent — no error message, just the wrong page showing to the wrong audience — hreflang needs to be actively checked, not assumed correct because it was set up once. A hreflang checker verifies that tags are present, correctly formatted, and reciprocal, catching the specific mismatch that breaks a whole cluster before it costs international traffic.

Search Engine Journal's technical audit guidance on hreflang recommends re-checking hreflang any time a page in the set is renamed, moved, or removed — since that's exactly the moment the reciprocal chain most commonly breaks without anyone noticing.

Common mistakes when implementing hreflang

Assuming a language switcher UI element is enough. A dropdown that lets users manually pick a language is a UX feature, not an SEO signal — it does nothing to tell Google which page to rank for which searchers without the actual hreflang tags underneath it.

Only checking hreflang once, at launch. As covered above, the reciprocal structure breaks the moment any single page in the set changes without every other page updating in sync. Treat it as an ongoing check, not a one-time setup task.

Using hreflang for pages that aren't actually translations. Hreflang is for the same content in different languages/regions, not for topically similar but different content. Using it for unrelated pages sends Google a false equivalence signal.

Confusing hreflang with a redirect. Hreflang tells search engines which version to rank; it doesn't automatically redirect a visitor. If you also want to redirect users based on browser language, that's a separate, deliberate implementation — and per Google's own guidance on redirects, auto-redirecting by IP or browser language should never override a user's ability to manually pick a version.

FAQ

What are hreflang tags used for? Hreflang tags tell Google which language and region a page targets and point to the equivalent pages in other languages, preventing Google from treating translated versions of the same content as duplicate or unrelated pages.

Why does Google ignore my hreflang tags? The most common cause is a missing or mismatched reciprocal link — every page in a hreflang set must reference every other page, and every one of those pages must reference it back. A single broken link in the chain causes Google to ignore the entire cluster's annotations.

Do I need an x-default hreflang tag? It's not strictly required, but without one Google decides on its own which page to show visitors whose language doesn't match any of your specified variants — usually not what you'd choose deliberately.

Can hreflang tags go in a sitemap instead of the page head? Yes. Declaring hreflang relationships in an XML sitemap is a valid alternative to per-page <link> tags, and it's often easier to manage and audit for large multilingual sites since everything lives in one file.

Check whether your hreflang tags are actually working

Given how common silent hreflang errors are — an estimated three in four implementations have at least one — it's worth verifying rather than assuming. Run your international pages through the free hreflang checker to confirm your tags are present, correctly formatted, and reciprocal.