Hreflang Mistakes That Make Google Ignore Your Tags

Hreflang mistakes don't throw an error. Your tag just gets quietly dropped, and Google serves whichever language version it feels like instead. That silence is why hreflang trips up so many site owners: everything looks fine in the CMS, the plugin says "done," and three weeks later a French shopper is still landing on the English homepage.

Search Console used to have an International Targeting report that listed hreflang errors by name. Google removed it in September 2022 and nothing replaced it, so if you're wondering why Search Console isn't flagging anything, it can't. Checking hreflang is now a job for third-party tools, view-source, and a methodical eye.

This article catalogs the mistakes that make a tag die silently, grouped by the reason it dies. For the full rule set (what hreflang is for, how to declare it, what a complete set looks like), the hreflang tags explainer is the place to start. Here, we go straight to what breaks.

How Google Decides to Ignore an Hreflang Tag

Hreflang is a link between pages, not a command. Google reads the annotation, checks it against a handful of conditions, and either honors it or throws it away. Every mistake in this article falls into one of four buckets, and knowing which bucket you're in tells you where to look first.

• The code is invalid or wrong. The language or region value doesn't parse, or it parses into something you didn't mean.
• The target can't be indexed. The URL you pointed at redirects, errors out, or is blocked from indexing.
• Something else contradicts the tag. A canonical tag, a duplicate declaration, or a mismatch between the HTML and the sitemap sends a competing signal.
• The set is incomplete. Pages in the cluster don't all point back at each other, so Google can't confirm the relationship is mutual.

There's also a fifth case that isn't a mistake at all: Google sometimes treats two very similar pages as one, and folds the hreflang cluster along with them. John Mueller said as much on Bluesky in May 2025, noting that "hreflang doesn't guarantee indexing, so it can also just be that not all variations are indexed." If your en-GB and en-US pages are close to identical, Google may have picked a canonical between them, which has nothing to do with a broken tag.

Group 1: invalid or misleading language codes

Google's own guidance names incorrect language and region codes as one of exactly three "common mistakes" in its localized-versions documentation. The ways to get a code wrong are far more numerous.

The en-UK trap (why "UK" isn't a real code)

Here's the one that catches almost everyone at least once. You want to target British visitors, so you write en-UK. It looks correct, and it's wrong.

Hreflang codes follow two separate standards stitched together: a language from ISO 639-1, optionally followed by a region from ISO 3166-1 alpha-2. The United Kingdom's region code in that standard is GB, not UK. "UK" is a reserved code in ISO 3166 and Google explicitly says it's ignored. So en-UK fails region validation and gets dropped.

It gets stranger if you drop the region entirely. uk by itself is a valid ISO 639-1 language code, and it means Ukrainian, according to the Library of Congress's ISO 639 registry. Put hreflang="uk" on a British page and, as far as Google can tell, you've written a valid tag that declares Ukrainian on purpose.

A few other codes carry the same trap. Here's the short list of near-misses hreflang.tools flags as suspect_code, meaning the value is technically real but almost never what the person meant:

Two more: cz and jp aren't language codes at all (Czech is cs, Japanese is ja), so tags built from them fail outright. hreflang.tools labels those bad_code.

A region code alone doesn't work

The reverse mistake shows up too: writing hreflang="GB" or hreflang="US" with no language at all. Google's documentation is direct about this: you can't specify the country code by itself. Every value needs a language first.

Case, underscores and other near-misses

Google treats hreflang values as case-insensitive, so en-gb and en-GB validate the same way. hreflang.tools still flags mismatched casing as code_case, but that's a tidiness warning, not something that gets your tag dropped. What Google won't tolerate is the underscore some plugins and locale libraries default to, like en_US instead of en-US. That's an invalid value, not a style choice.

The fix

Check every code against the actual ISO 639-1 language list and ISO 3166-1 region list rather than trusting what sounds right. If you're running your pages through hreflang.tools, near-miss codes like the ones in the table above come back with a suggested correction attached.

Group 2: targets Google can't index

A hreflang tag links to a URL. If Google can't index that URL, there's nothing to pair the tag with, and the annotation gets treated as noise. This group catches people whose tags are written correctly; the problem lives one layer down, in what the server does when the URL is requested.

The target redirects

This is the most common reachability failure. A tag points to http://example.com/fr/, but the server redirects everything to https://. Or it points to a URL without a trailing slash, and the server adds one.

Or the www and non-www versions don't match. Every one of these sends Googlebot somewhere other than the URL the tag declared.

hreflang.tools flags this as target_redirects, and the fix is blunt: tags must name the final URL, the one that actually returns a 200 status. Geo-redirects are a sneaky variant; a server that bounces a US-based crawler away from the French version can quietly break the whole cluster.

The target returns an error or isn't HTML

A 404, a 500, or a URL that resolves to a PDF or an image instead of a web page all fail the same way: there's no indexable content for the hreflang relationship to attach to. hreflang.tools calls these target_error and target_unreachable.

The target is noindex or blocked

Hreflang connects indexed pages to each other. If the target carries a noindex tag or is blocked by robots.txt, it was never going to enter the index, so there's nothing for the pair to attach to. Screaming Frog's own issue documentation puts it plainly, warning that a noindex return URL "may result in the hreflang relationship being ignored." Screaming Frog's noindex-return-links guidance covers the mechanics.

If you're not sure whether a target actually made it into Google's index, run it through indexcheck.tools before you spend time re-declaring tags that were never going to work.

The URL is relative, not absolute

Alternate URLs in a hreflang tag must be fully qualified, scheme included, per Google's specification. A tag written as href="/fr/" instead of href="https://example.com/fr/" is invalid on its face. hreflang.tools marks this relative_hreflang, and it's easy to miss because the link works fine for a human clicking around the site.

Group 3: signals that contradict each other

Hreflang sits next to canonical tags, sitemap entries, and HTTP headers, and when two of those signals disagree, Google usually believes neither.

The canonical points somewhere else

If a page declares hreflang alternates but its own canonical tag points to a different URL, Google reads that as the page telling it "don't index me here, index this other one instead." That instruction wins, and the hreflang annotation gets canceled along with it. hreflang.tools labels this canonical_cancels_hreflang, and it's common on sites where canonical tags were set up before hreflang was added. The fix and the full mechanics live in a separate piece on hreflang and canonical conflicts.

One language, two URLs

Declaring the same language-region value twice on one page, pointing at two different URLs, is a straightforward contradiction: which one is the real French version? hreflang.tools flags this duplicate_lang. The reverse is fine: an en-GB, en-IE and x-default tag can all point at the same page without conflict, per Mueller's comments going back to 2016. The mistake is one code splitting across two destinations, not several codes converging on one.

HTML, sitemap and header disagree

You can declare hreflang in the page's HTML head, in an XML sitemap, or in an HTTP response header, and Google treats all three as equally valid. Mueller confirmed this on a Search Central livestream in November 2020. The catch is when two sources disagree, say the sitemap points a language at one URL while the HTML points it elsewhere. Mueller's answer, from that same livestream: "we would probably drop that pair."

This is the mistake behind the "I added it to the sitemap too, just in case" instinct on sites migrating between plugins. Mixing methods isn't the problem; two generators drifting out of sync is. hreflang.tools flags mismatches here as html_header_conflict.

Tags added by JavaScript or sitting outside <head>

Google can render JavaScript, so a hreflang tag injected client-side isn't ignored, just processed on a delay. The bigger problem is that most crawling tools, hreflang.tools included, read the raw HTML only, so a JS-injected tag is invisible to anything checking your work before Google gets to it. Put the declaration in the server-rendered head.

Related and more mechanical: link rel="alternate" tags are only valid inside <head>. An unclosed tag earlier in the document, or a plugin injecting markup at the wrong point, can push everything after it into what the browser treats as body content. This shows up on WordPress sites most, usually after a theme or plugin update.

Group 4: sets that aren't complete

Hreflang works as a set, not as individual tags. Every page in the cluster needs to list every other page, including itself. Miss a piece and the whole relationship can fall apart.

Missing return links

If your English page links to the French version but the French page doesn't link back, Google drops the pair entirely. This is Google's first-listed "common mistake," and the reasoning is defensive: without a return link, anyone could point a hreflang tag at your page and falsely claim it as their alternate. It's also the mistake the retired Search Console report used to flag. The mechanics of reciprocity are covered in the self-referencing hreflang guide.

Missing self-reference

Each page in a cluster needs to list itself among the alternates, not just the other language versions. Skip it and the set reads as incomplete.

Missing or partial x-default

x-default tells Google which version to show a visitor whose language doesn't match any declared alternate. It's not strictly required, but leaving it off entirely, or adding it to some pages in a cluster and not others, creates an inconsistent set.

Three things that look like mistakes but aren't

Not every audit warning is a real problem. A few patterns get "fixed" when they were already working.

• Several hreflang values on one URL. An en-GB, en-IE, and x-default tag can all legitimately point at the same page. That's a real setup, not a duplicate to be trimmed.
• x-default pointing at the main language page. Using your primary market's page as the x-default fallback is a normal, common pattern, not a sign that x-default is missing.
• Hreflang on only some pages of the site. It's a per-page signal, so a partial rollout (product pages done, blog posts not yet) isn't broken.

How to test hreflang tags after you fix them

Since Search Console stopped reporting hreflang problems in September 2022, per Google's own deprecation notice, there's no dashboard that tells you when something's wrong, so testing has to be deliberate.

1. View source, not the CMS setting. Settings panels show intent; the rendered HTML shows what shipped.
2. Run the cluster through a checker. Paste the URLs (or the sitemap) into hreflang.tools and read code validity, reachability, canonical conflicts, and cluster completeness as separate sections.
3. Fetch each target yourself. Confirm every alternate returns a 200 status with no redirect and no noindex directive.
4. Confirm with URL Inspection after fixing. Google doesn't report hreflang status directly, but you can check whether the alternates are indexed after a recrawl.

hreflang.tools, like most third-party checkers, doesn't execute JavaScript, doesn't crawl past the alternates you've declared, and can't see what Google has actually indexed. A study by SALT.agency and NerdyData, covering nearly 19,000 sites and reported by Search Engine Land in April 2023, found 8.91% of sites with invalid language codes and another 22.46% using irregular or unusual language-region combinations. Those numbers are why a syntax check is worth running even on a site you're fairly confident about.

Frequently Asked Questions

What are the most common hreflang errors?

Google's own documentation names three: missing return links, incorrect language codes, and incorrect region codes. In practice, the catalog is wider. Reachability failures (redirected, noindex, or broken targets), conflicting canonical tags, duplicate language declarations, and mismatches between HTML and sitemap sources all show up regularly in audits. The April 2023 SALT.agency study found invalid codes on 8.91% of sites checked and unusual language-region combinations on 22.46%.

Why does Google ignore my hreflang tags?

Google drops a hreflang tag for one of four reasons: the code doesn't validate, the target URL can't be indexed (it redirects, errors, or carries a noindex directive), a competing signal like a canonical tag contradicts it, or the set is incomplete because a return link or self-reference is missing. There's also a non-error case: if two variants are close to identical, Google may fold them into one indexed version regardless of the tags, since hreflang doesn't guarantee indexing.

Is en-UK a valid hreflang code?

No. "UK" is a reserved code in the ISO 3166-1 region standard and Google explicitly ignores it, so en-UK fails validation. The correct region code for the United Kingdom is GB, which makes the valid tag en-GB. Be careful with the shorter form too: uk by itself is a real ISO 639-1 language code, but it means Ukrainian, not "British."

How do I test hreflang tags?

View the rendered page source rather than trusting a CMS setting, run the full cluster through a checker that validates codes, reachability, and canonical alignment together, fetch each target directly to confirm it returns a 200 status with no redirect or noindex, and use URL Inspection in Search Console afterward to confirm the pages got indexed. Since Search Console no longer reports hreflang errors, this manual routine is the only reliable way to catch problems.