Why Your Hreflang Tags Aren't Working
A site adds hreflang tags to every localized page, checks back weeks later, and Google is still showing the wrong language version to the wrong country. The tags are there. Google is ignoring them anyway, and the site has no error message telling it why.
Brass-SEO sees this pattern often enough to trace it back to its source: Google's hreflang documentation states one requirement plainly, and it's the one almost every broken implementation skips. This post covers that rule, the language-tag format underneath it, and how rare correct hreflang actually is across the web.
Quick Navigation
- The Rule That Breaks Almost Every Setup
- Hreflang Values Follow a Real Spec
- The Over-Correction Nobody Catches
- Hreflang Is One Signal, Not the Whole Decision
- How Rare Correct Hreflang Actually Is
- A Working Hreflang Checklist
- Frequently Asked Questions
The Rule That Breaks Almost Every Setup
Google's own hreflang documentation states the requirement in one sentence: "If two pages don't both point to each other, the tags will be ignored." Every localized page has to link back to every other localized version of that page, including itself. Miss one direction on one pair, and Google doesn't partially honor the rest of the tag set — it drops the whole cluster.
This is the failure mode behind most "we added hreflang and nothing changed" reports. A site launches its French pages with tags pointing to the English version, but the English pages never got updated to point back. The French tags aren't wrong. They're just unpaired, and an unpaired tag is functionally the same as no tag at all. Brass-SEO's page audit checks both directions of every hreflang relationship for exactly this reason.
Google's documentation also lists three equally valid ways to implement the annotation — an HTML link tag in the page head, an HTTP header, or an entry in the XML sitemap — so a broken implementation isn't always about which method was chosen. It's almost always about the reciprocal link.
Hreflang Values Follow a Real Spec
The value inside an hreflang tag isn't a free-text field. It has to be a valid BCP 47 language tag, defined by RFC 5646, and the structure is fixed: language first, then an optional script subtag, then an optional region subtag, then any variants, always in that order.
That fixed order explains a specific, common mistake. A tag like en-UK fails for two reasons at once — the region subtag comes after the language, and "UK" isn't a valid ISO region code in the first place. The correct tag for English targeted at the United Kingdom is en-GB. Google's documentation calls out exactly this pattern by name, listing invalid region codes like "EU," "UN," and "UK" among the errors it sees most often.
The authoritative check for whether a given subtag is real is the IANA Language Subtag Registry, a continuously updated list maintained per RFC 5646 of every valid language, script, region, and variant code, including which ones have been deprecated and replaced. A tag can look perfectly formatted and still reference a code that's been retired.
The Over-Correction Nobody Catches
Some implementations fail in the opposite direction: too much precision instead of too little. A site targeting American English might write en-Latn-US, adding the script subtag on the assumption that more specificity is safer.
It isn't. The W3C's guidance on choosing language tags states that subtags should only be added when needed to distinguish the language in a given context, and that the script subtag specifically should be dropped when the IANA registry marks it "suppressed" for that language — which it is for English and the Latin script. The correct tag is en-US. Adding Latn back in isn't extra correctness. It's a tag that no longer matches the spec, built by someone trying to do the careful thing.
Hreflang Is One Signal, Not the Whole Decision
Google's documentation on managing multi-regional and multilingual sites makes a point that gets lost in most hreflang guides: hreflang is one input into a larger targeting decision, not the whole mechanism. Google states that webmasters "must explicitly tell Google about any locale or language variation," and names the signals it actually weighs: a country-code top-level domain as a "strong" standalone signal, hreflang annotations, the server's IP location, and secondary on-page cues such as local contact details and currency. URL parameters used for geotargeting are explicitly marked "not recommended."
A site built on a single .com domain with subdirectories for each language is leaning entirely on hreflang and secondary content signals to do work a ccTLD or a properly configured subdomain would help carry. Correct hreflang tags fix the annotation. They don't fix a URL architecture that's fighting the targeting decision underneath them.
How Rare Correct Hreflang Actually Is
The 2022 Web Almanac measured hreflang adoption directly: 9.6% of desktop home pages and 8.9% of mobile home pages carried a hreflang tag, both up slightly from 9.0% and 8.4% the year before. English was the single most common target, appearing on 5.4% of desktop home pages.
Fewer than one site in ten uses hreflang at all, correctly or not. Set against that, W3Techs' ongoing survey of declared content language finds English is the language of only about 49.5% of measured websites — meaning roughly half the web's content is already published in a language other than English, most of it without any hreflang signal pointing a search engine toward it. The demand-side case and the low adoption rate point the same direction: this is underused, not table stakes.
A Working Hreflang Checklist
Every localized page has to point to every other localized version and to itself, in both directions, with no pair left one-way. Every language tag has to follow the BCP 47 structure — language, then script only if not suppressed, then region using the correct ISO code — checked against the IANA registry rather than assumed. The URL structure carrying those pages should reinforce the targeting decision, not rely on hreflang alone to communicate it.
For the demand side of this decision — whether a language variant is even worth building before any of the above matters — see What 99 Languages Means for Your Content Reach and Why Most Small Sites Never Try Multilingual SEO.
Frequently Asked Questions
Why isn't my hreflang tag working even though I added it correctly?
The most common cause is a missing reciprocal link. Google's documentation states plainly that "if two pages don't both point to each other, the tags will be ignored" — every localized page has to link back to every other version, including itself, or the entire tag set is dropped.
Is en-UK a valid hreflang value?
No. Hreflang values must follow the BCP 47 tag structure defined in RFC 5646 — language, then script, then region, in that order, using ISO region codes rather than country abbreviations. The correct tag for English targeted at the United Kingdom is en-GB; Google's documentation specifically names "UK" among the invalid region codes it sees.
Should I write en-Latn-US to be more specific than en-US?
No. en-US is correct. The W3C's language-tag guidance states the script subtag should be omitted when the IANA registry marks it "suppressed" for that language, which it is for English and Latin script. Adding it back in produces a tag that's less correct, not more specific.
How many websites actually implement hreflang?
Under 10%. The 2022 Web Almanac measured hreflang tags on 9.6% of desktop home pages and 8.9% of mobile home pages. Meanwhile roughly half the web's content is already published in a language other than English, according to W3Techs' ongoing content-language survey — a gap between demand and implementation that most sites haven't closed.
Every source in this post — Google's hreflang documentation, RFC 5646, the IANA registry, and the Web Almanac data — is fact-checked and linked in the Hreflang & Multilingual SEO entry of the Brass-SEO Research Index.