Why hreflang errors quietly wreck international SEO

Hreflang is the most error-prone tag in the SEO toolkit, and it's the single biggest reason international sites underperform in markets they should dominate. Tell Google that example.com/fr/ is the French version of example.com/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.

The frustrating part is that broken hreflang doesn't 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. A hreflang validator surfaces the technical reasons your international pages aren't reaching their audiences.

Most teams learn about problems through Search Console's International Targeting report, which flags return tag errors at a domain level but not which URL pairs are misconfigured. A proper hreflang checker walks the cluster, fetches each alternate, and compares declared relationships against what each URL actually returns.

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: return tags (does B reference A in return?), language and region codes (valid ISO 639-1 and ISO 3166-1 alpha-2?), HTTP status codes (does each alternate URL return 200?), and canonical alignment (does each version self-canonicalize?).

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. A multilingual SEO check should pull from all three sources and flag conflicts (yes, you can have hreflang in the head and in the sitemap pointing at different things, and yes, that breaks the cluster).

The validator should also confirm you've included an x-defaulttag for users whose language or region doesn't match any alternates. Without it, Google picks on its own.

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.

Why so often? Partial deployments. Someone adds the French version, updates the English page's hreflang, but forgets to update the French page to reference back. Multiply this across ten languages and a CMS that handles each translation separately, and broken clusters become the default state.

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.

Invalid language and region codes

Hreflang uses ISO 639-1 for language (en, fr, de) and ISO 3166-1 alpha-2 for region (US, FR, DE), separated by a hyphen. Not an underscore. The number of sites running en_US instead of en-US is genuinely embarrassing. Google silently drops invalid codes, and underscores are the most common reason a hreflang tag does nothing at all.

Made-up regions are the next tier of mistake. en-UK is wrong; the ISO code for the United Kingdom is GB, so it's en-GB. en-EU doesn't exist because the EU isn't a country code. es-LA isn't valid either; for Latin America you use es-419, the UN M.49 code Google accepts as a special case.

Deprecated codes also bite. iw for Hebrew was replaced by he, in for Indonesian by id. Google generally accepts the deprecated forms, but mixed clusters where some pages use old codes and others use new ones break the relationship. A validator catches both invalid codes and inconsistent usage across the 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 rel=canonical points to the English version, Google ignores the hreflang entirely. The canonical wins. Google reads it as "this page is a duplicate of the English one," and the hreflang relationships become irrelevant because the page itself isn't treated as canonical.

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, killing international targeting for every alternate. A validator should flag any page where the canonical points to a different URL than the page itself.

The fix: each language version self-canonicalizes. The French page's canonical points to the French URL, the German to German, and hreflang handles the relationship. Canonical for duplicate consolidation, hreflang for language and region targeting; they do different jobs and shouldn't cross wires.

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, not a soft 404. If your English page lists /de/page as its German alternate, and /de/page redirects to /de-DE/page, Google has to resolve the redirect to find the actual page, and during that resolution the 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. A multilingual SEO check should fetch every alternate and verify it returns 200, not just check that the tag exists.

Redirects are slower poison. They might work, but they signal inconsistent URLs. Fix the source, update the hreflang to point at the final URL, and remove the redirect. Same for protocol mismatches; if your hreflang points at http:// but you serve https://, every alternate fetch is a redirect.

When tags look fine but Google ignores them

Sometimes the validator reports a clean implementation and Google still serves the wrong page in international SERPs. 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; rejected clusters usually have an issue the static validator can't see, like inconsistent geolocation signals or content too similar across language versions.

Geolocation signals matter. If your German page is served from a US-hosted CDN with no localization headers, thin content, and an English-speaking author byline, Google may decide the page isn't German and override your hreflang. The tag is a hint about intended audience; the rest of the page has to match.

The other failure mode is content overlap. If your en-US and en-GB pages are 95% identical, Google may pick one and ignore the hreflang. Region variants of the same language require real differentiation: local currency, region-specific examples, or editorial differences.

A clean process for fixing what the validator flags

When an international SEO audit returns a long list of errors, the order matters. Bidirectional return tags first; nothing else works until the cluster is reciprocal. Every other improvement is invisible to Google as long as the cluster is broken.

Code accuracy second. Replace underscores with hyphens, fix invalid regions, normalize deprecated codes. A good validator generates a corrected hreflang block you paste back into your templates or sitemap.

Canonical conflicts third. Walk every page and confirm each one self-canonicalizes; this is usually a template fix. Then resolve HTTP status issues (kill redirects, restore 404s, fix protocol mismatches). Re-run the validator and confirm every cluster is clean before submitting a sitemap or requesting recrawls. Hreflang work is iterative; the validator is your feedback loop.