Why hreflang errors quietly wreck international SEO

Hreflang is the most error-prone tag in the SEO toolkit, and it is the single biggest reason international sites underperform in markets they should dominate. Tell Google that example.com slash fr is the French version of example.com slash en, and Google serves the right page to French speakers in France. When implementations break, Google falls back to its own guess, which is usually your English homepage regardless of where the searcher lives or what language they typed their query in.

The frustrating part is that broken hreflang does not throw a visible error. Your French page still ranks, just not for French queries from France. Conversion rates in non-English markets stay stubbornly low while you blame the translation, the pricing, or the market itself. A hreflang validator surfaces the technical reasons your international pages are not reaching their intended audiences, so you stop guessing and start fixing the actual cause.

Most teams learn about problems through Search Console's International Targeting report, which flags return-tag errors at a domain level but does not tell you which URL pairs are misconfigured. A proper hreflang checker walks the cluster, fetches each alternate, and compares the declared relationships against what each URL actually returns, so you get a specific list of broken pairs instead of a vague domain-wide warning.

What a hreflang validator actually inspects

A real hreflang testing tool does more than parse tags off a single page. It crawls the cluster of alternates, fetches each one, and verifies the relationship goes both directions. The four checks that matter are return tags, asking whether page B references page A in return, language and region codes, asking whether each is a valid ISO 639-1 language and ISO 3166-1 alpha-2 region, HTTP status codes, asking whether each alternate URL returns a clean 200, and canonical alignment, asking whether each version self-canonicalizes rather than pointing somewhere else.

Tags can live in three places: the HTML head, the HTTP Link header, or an XML sitemap. At scale, sitemap-based hreflang is cleaner because you maintain the relationships in one file rather than across thousands of pages. A thorough multilingual SEO check should pull from all three sources and flag conflicts. You can absolutely have hreflang in the head and in the sitemap pointing at different things, and when you do, the contradiction breaks the cluster in a way that is nearly impossible to spot by reading either source alone.

The validator should also confirm you have included an x-default tag for users whose language or region does not match any of your declared alternates. Without it, Google picks a fallback on its own, and its choice is rarely the one you would have made. Surfacing the missing x-default early saves you from leaking a chunk of global traffic to whatever page the algorithm happens to favor.

The number one bug: missing return tags

Hreflang is reciprocal. If page A says page B is its French alternate, page B must say page A is its English alternate. If the return tag is missing on B, Google ignores the relationship entirely and treats both as standalone pages. This is the most common hreflang error in the wild, and it costs the most traffic because it silently dissolves the very connection you built the cluster to create.

Why does it happen so often? Partial deployments. Someone adds the French version, updates the English page's hreflang to point at it, but forgets to update the French page to reference back. Multiply this across ten languages and a CMS that handles each translation as a separate object, and broken clusters become the default state rather than the exception. Nobody intends it, and nobody notices until a market quietly stalls.

A hreflang checker walks the whole cluster from any starting URL, fetches every declared alternate, and verifies each one references back to every other alternate, including itself. One missing return tag in a cluster of twelve languages is enough to invalidate the whole set, which is why a cluster-wide crawl beats spot-checking a page or two by hand.

Invalid language and region codes

Hreflang uses ISO 639-1 for language, such as en, fr, and de, and ISO 3166-1 alpha-2 for region, such as US, FR, and DE, separated by a hyphen, never an underscore. The number of sites running en_US instead of en-US is genuinely embarrassing. Google silently drops invalid codes, and the underscore is the single most common reason a hreflang tag does nothing at all, because it turns a valid value into one the parser cannot recognize.

Made-up regions are the next tier of mistake. en-UK is wrong, because the ISO code for the United Kingdom is GB, so the correct value is en-GB. en-EU does not exist, because the European Union is not a country and has no country code. es-LA is not valid either; for Latin America you use es-419, the United Nations M.49 region code that Google accepts as a special case. These look plausible to a human, which is exactly why they slip through review and survive in production for years.

Deprecated codes also bite. The code iw for Hebrew was replaced by he, and in for Indonesian was replaced by id. Google generally still accepts the deprecated forms, but mixed clusters, where some pages use the old codes and others use the new ones, break the relationship because Google reads them as two different identities. A validator catches both outright invalid codes and the subtler inconsistent usage spread across a cluster.

Canonical conflicts: the silent killer

This catches even experienced teams. If your French page declares hreflang to its English, German, and Spanish alternates, but its canonical points to the English version, Google ignores the hreflang entirely. The canonical wins. Google reads it as a statement that this page is a duplicate of the English one, so the hreflang relationships become irrelevant because the page itself is no longer treated as a canonical destination worth ranking.

This happens constantly when teams use a single template for all language versions and forget to make the canonical dynamic. Every translated page ends up canonicalizing back to the source language, quietly killing international targeting for every alternate at once. Because the hreflang tags are all present and correct, the cause is invisible to anyone who is only looking at the hreflang block, which is what makes this bug so durable.

The fix is straightforward once you see it: each language version self-canonicalizes. The French page's canonical points to the French URL, the German page's points to the German URL, and hreflang handles the relationship between them. Canonical is for consolidating duplicates, hreflang is for language and region targeting; they do different jobs and should never cross wires. A validator should flag any page where the canonical points to a different URL than the page itself.

HTTP status codes across the cluster

Every URL in a hreflang cluster needs to return a 200. Not a 301, not a 302, not a 404, and not a soft 404 that returns 200 with a not-found message. If your English page lists slash de slash page as its German alternate, and that URL redirects to slash de-DE slash page, Google has to resolve the redirect to find the actual page, and during that resolution the declared relationship can break.

404s are common because pages get deleted or restructured without anyone updating the alternates that reference them. Google fetches the URL, gets a 404, drops the relationship, and the cluster degrades one missing page at a time. A multilingual SEO check should fetch every alternate and verify it returns 200, not merely check that the tag exists in the markup, because a tag pointing at a dead URL is worse than no tag at all.

Redirects are slower poison. They might work, but they signal inconsistent URLs and waste crawl resolution on every fetch. Fix the source, update the hreflang to point at the final URL, and remove the redirect. The same applies to protocol mismatches: if your hreflang points at http but you serve https, every alternate fetch becomes a redirect, and a cluster full of redirects is a cluster Google has to work to trust.

When tags look fine but Google ignores them

Sometimes the validator reports a clean implementation and Google still serves the wrong page in international results. At that point you need Search Console diagnosis on a case-by-case basis. The International Targeting report shows which clusters Google has accepted and which it has rejected, and rejected clusters usually have an issue a static validator cannot see, such as inconsistent geolocation signals or content that is too similar across language versions to be treated as distinct.

Geolocation signals matter. If your German page is served from a US-hosted server with no localization headers, thin or machine-translated content, and an English-speaking author byline, Google may decide the page is not really German and override your hreflang. The tag is a hint about intended audience; the rest of the page has to back up that hint, or the algorithm trusts the evidence on the page over the declaration in the head.

The other failure mode is content overlap. If your en-US and en-GB pages are ninety-five percent identical, Google may pick one and ignore the hreflang between them. Region variants of the same language require real differentiation: local currency, region-specific examples, distinct shipping and returns information, or genuine editorial differences. Without that, you are asking Google to maintain a distinction your own pages do not actually make.

A clean process for fixing what the validator flags

When an international SEO audit returns a long list of errors, the order you fix them in matters. Start with bidirectional return tags, because nothing else works until the cluster is reciprocal. Every other improvement is invisible to Google as long as the cluster is broken, so fixing codes or canonicals first is effort spent on a structure that Google is still ignoring.

Code accuracy comes second. Replace underscores with hyphens, fix invalid and made-up regions, and normalize deprecated codes so the whole cluster speaks one consistent dialect. A good validator generates a corrected hreflang block you can paste straight back into your templates or sitemap, which removes the retyping step where new errors usually creep in.

Canonical conflicts come third. Walk every page and confirm each one self-canonicalizes; this is almost always a single template fix rather than a per-page edit. Then resolve the HTTP status issues by killing redirects, restoring deleted pages or removing their alternates, and fixing protocol mismatches. Re-run the validator and confirm every cluster is clean before you submit a sitemap or request recrawls. Hreflang work is iterative, and the validator is your feedback loop: change something, re-run, and watch the error count fall until the international targeting finally holds.