Your Hreflang Is Correct. Google Still Ignores It

Recently I worked on a site using a language code that doesn't exist. Not a typo in one template. One market's code, invented, sitting in the head of every page on the site.

One version stopped being an alternate and became a competitor. It got indexed alongside the others. Rankings flipped between them week to week.

The client thought they had a content problem. They had a two-letter problem.

An invalid code fails silently

Google hits a code that isn't in the standard, ignores that part of the annotation, moves on. No warning. No flag.

The rest of the cluster keeps working. That's what makes it easy to miss. The broken code sits in the head of every page, because every page lists every alternate, but only one locale actually drops out.

That version is now orphaned. Not an alternate of anything. Just another near-identical page on the same domain, with nothing explaining how it relates to the rest.

So it competes. Against the versions it should have been paired with. Broken hreflang isn't neutral, and that's the part clients don't expect.

I see this problem often. en-uk instead of en-gb. cz for Czech, which is cs. eu for "Europe", which isn't a region at all. A bare country code where a language code belongs. Somebody invents something that reads fine to a human and means nothing to a parser.

You'll read that Google corrects some of this for you. That advice is old. The current docs list UK, UN and EU among the reserved codes, and say plainly that using them in hreflang has no effect on Search. Regions were never supported anyway. Google's infrastructure understands countries, not regions.

This type of issue can easily kill any website selling across multiple markets.

Hreflang was never a command

Google's own documentation calls it a way to understand that pages are localised variations. Not an instruction it has to follow. And Google has said it plainly: hreflang doesn't guarantee indexing, and if two versions are the same, one gets picked as canonical.

It works that way on purpose.

Hreflang is one input among many, and canonicalization is the one that decides. If your canonical points somewhere outside your hreflang set, the markup gets ignored. If your pages look like duplicates, they get merged.

The harder problem starts when your codes are right

Broken hreflang is the easy case. Find it, fix it, done.

The difficult one is the European eshop with clean, valid, reciprocal hreflang that still surfaces the wrong market.

Look at those pages. Same currency, everything in euros. Same language across markets – Dutch for NL and BE, French for FR, BE and LU, German for DE and AT. Same product names. Same manufacturer descriptions. Same prices.

What actually distinguishes them? A country code in the URL and a line of markup.

Google collapses duplicates. It does this across the whole web, constantly, and it's good at it. Asking it to keep near-identical pages apart on the strength of a hint is asking it to work against itself.

So it picks the wrong one sometimes. It isn't random. There's an algorithm behind it, weighing signals you can't see. But when two pages differ by almost nothing, the deciding factors are tiny. From where you sit it looks like a coin flip.

Markup can't create a difference that isn't there

If two country pages are functionally identical, you have two options. Make them genuinely different, or stop pretending they're separate.

Genuinely different means signals Google can see. Local pricing. Local delivery times and shipping cost. Local address and phone. Local stock. Local reviews. Content written for that market, not run through the same translation memory as the last one.

None of that is hreflang. Hreflang describes the relationship between pages. It doesn't create the difference that justifies it.

The alternative is consolidation. One strong page per language, country handled on the page instead of in the URL. Fewer URLs, concentrated signals, less to break. For a lot of sites that's the better decision, and nobody says it out loud because the multi-country setup already exists and somebody defended the budget for it.

Different languages are a different situation. Translated content is genuinely different, and Google treats it that way. The danger zone is same-language variants across markets.

Put it in the HTML where you can see it

The HTML head wins on debuggability. Open view-source and it's there. Catch it in a crawl. Check a live page in ten seconds.

Sitemap hreflang is a black box. It drifts out of sync with the pages and looks correct on both sides while doing nothing. You end up trusting the file instead of checking the page.

Pick one method. Mixing them with conflicting data is worse than picking the weaker one – when signals disagree, Google drops the pair.

One more. Inline scripts can break the head and push your tags into the body, where they do nothing. Google's own docs tell you to validate the rendered page for exactly this reason.

JS-injected hreflang does work, by the way. Google reads the rendered HTML. But rendering happens less often than crawling, and less often still on pages Google doesn't care much about. So your changes land eventually rather than soon. Server-render it and skip the wait.

Nobody will tell you it's broken

Google removed the International Targeting report from Search Console years ago. Whatever you thought of it, it was the one place hreflang errors surfaced on their own.

There's nothing central now. Invalid codes fail silently. Missing return links fail silently. Targets that turned into redirects fail silently. The pages still load fine.

Detection is your problem. Crawl for it on a schedule. Check after every release that touches templates or routing. Treat it like Core Web Vitals. Something you keep watching after launch.

That client had the invented code live for a long time before anyone connected it to the ranking chaos. Nothing was going to tell them.

Clean hreflang is the minimum. Get the codes right, keep the signals consistent, then be honest about whether your country pages deserve to exist separately at all.