How Does hreflang Actually Work?

Hreflang tells Google which URL to serve for a specific language or region when a site publishes near-duplicate content across several country or language versions of the same page. It doesn't work like most other SEO signals: a single broken link in the set, a missing return tag, an invalid region code, can cause Google to silently ignore the entire annotation for that cluster, with no warning in Search Console since the tool that used to flag these errors was deprecated in 2022.

The Three Ways to Implement hreflang

Google's current documentation on localized versions of pages, last updated September 21, 2026, lists three equivalent implementation methods, and a site only needs to pick one:

• HTML <link> tags in the <head> of the page: <link rel="alternate" hreflang="[lang_code]" href="url_of_page" />. Google's documentation specifically warns not to combine this tag with other attributes like media.
• HTTP headers, used for non-HTML files like PDFs, in the format Link: <url1>; rel="alternate"; hreflang="[lang_code_1]", <url2>; rel="alternate"; hreflang="[lang_code_2]".
• XML sitemaps, using <xhtml:link> child elements under each URL entry, which requires declaring the xmlns:xhtml="http://www.w3.org/1999/xhtml" namespace. Every URL in the sitemap needs the identical set of child elements listing all the other language and region variants, not just its own.

None of the three methods is more authoritative than the others in Google's eyes; the sitemap approach is often preferred on large sites specifically because it keeps the annotation out of the page's own HTML and easier to generate programmatically at scale. A site with a few dozen regional pages can usually manage HTML tags by hand without much trouble, but a catalog running into the thousands of URLs across a dozen locales tends to move to sitemap-based hreflang precisely because updating a sitemap generation script in one place is far less error-prone than editing the <head> of every affected template.

The Return-Tag Rule: Why hreflang Fails Silently

The single requirement that causes the most real-world hreflang problems is reciprocity. Google's documentation states the rule plainly: each language version must list itself as well as all other language versions, and critically, "if two pages don't both point to each other, the tags will be ignored." This is often called the return-tag requirement, and it means hreflang isn't a one-way declaration a page makes about itself. It's a mutual agreement every page in a set has to make about every other page.

In practice, this is exactly the kind of setup that degrades quietly over time. A site launches a new regional page and forgets to add the corresponding link back on the existing versions; a page gets removed or redirected without updating the other versions that still reference it; a templating bug drops one language from the loop on a subset of pages during a migration. None of these produce an error message a site owner would necessarily see. The annotation simply stops working for the affected cluster, and Google falls back to its own signals for deciding which version to show, which may not be the one the site intended.

Language and Region Codes: What's Actually Valid

Hreflang codes follow a specific, checkable format. The first code is required and must be an ISO 639-1 language code. A second, optional code specifies a region using ISO 3166-1 Alpha 2, for example en-US, de, zh-Hant, or de-CH. Google's documentation is explicit that a region code can't be used on its own without a language code first, since the format assumes language as the primary axis and region as a refinement of it, not a substitute for it.

A recurring, entirely avoidable error is using a code that looks plausible but isn't valid under either standard. Google's documentation specifically calls out EU, UN, and UK as examples that have no effect, since none of them is a real ISO 3166-1 Alpha 2 country code (the correct code for the United Kingdom is GB). A markup that looks completely reasonable to a human reader, hreflang="uk" for a UK-targeted page, silently does nothing, because Google's validation is checking against the actual ISO standard, not against what a reasonable person would assume the code should be.

There's also a reserved value, x-default, meant for a fallback page, typically a language selector or a generic version, shown when none of the declared language or region codes match a visitor's browser settings. Google's own example is straightforward: <link rel="alternate" href="https://example.com/" hreflang="x-default" />.

How hreflang Interacts With Canonical Tags

Hreflang and canonical tags solve different problems, but they have to agree with each other or one signal quietly overrides the other. Every page in a hreflang set should carry a self-referencing canonical tag, pointing at itself, not at whichever version happens to be considered the "main" one. Pointing a French page's canonical at an English original, for instance, tells Google to treat the French page as a duplicate to consolidate away, which removes it from independent ranking eligibility in French-language results regardless of what the hreflang annotation says. See canonical tags and canonicalization explained for the specific exception Google's own documentation allows: genuinely regional variants sharing the same language, where canonical and hreflang can point at the same preferred URL together, since those pages actually are near-duplicates in Google's eyes.

Why Search Console Stopped Flagging hreflang Errors

Until 2022, Search Console's International Targeting report gave site owners a direct view into hreflang problems: a dedicated Language section that flagged errors like missing return tags, alongside a separate Country section for setting a site-wide country target. Google's own Search Console help documentation now states plainly that "the International Targeting report has been deprecated." The country-targeting half of the tool was retired because, in Google's words, it "was determined to have little value for the ecosystem, and is no longer supported." Reporting at the time from Search Engine Land and Search Engine Roundtable dated the removal to a September 22, 2022 rollout, following an announcement about a month earlier.

Critically, Google's current documentation is explicit that hreflang itself didn't go anywhere: "Google will continue to support and use hreflang tags on your pages." What disappeared is the built-in error monitor, not the underlying signal. That leaves a real gap for anyone who relied on Search Console to catch a broken return tag before it caused a problem, since the URL Inspection tool only shows what Google sees for one URL you check manually, and doesn't proactively surface hreflang errors across an entire site the way the old report did.

How to Actually Audit hreflang Today

Without a built-in Search Console report, auditing hreflang now depends on tools that can crawl a full site and check every declared relationship, not just individual pages in isolation:

1. Run a full-site crawl with a tool that validates hreflang clusters, such as Screaming Frog, Sitebulb, or Ahrefs Site Audit. These can catch missing return tags and invalid codes across hundreds or thousands of pages at once, which is the only practical way to check reciprocity at scale.
2. Spot-check individual pages with the URL Inspection tool in Search Console, which shows what Google's own rendering of the page currently contains, useful for confirming a specific fix actually took effect.
3. Confirm every hreflang target returns a 200 status, not a redirect or a 404. A hreflang tag pointing at a broken or redirected URL is treated by Google's crawlers as pointing at a non-canonical or unreachable page, which can invalidate the relationship the same way a missing return tag does.
4. Check that hreflang URLs match the canonical URL exactly, including protocol and trailing slash. A mismatch here is one of the more common causes of hreflang silently not working even when every code and return tag looks correct on paper.

Common Mistakes

A handful of patterns account for most real hreflang failures:

• Missing or broken return tags, the single most common cause, especially after a page is added, removed, or restructured without updating every other page in its set.
• Using a region code without a language code, or using an invalid code like UK instead of GB, both of which Google's own documentation explicitly says won't work.
• Pointing hreflang at a non-canonical URL, which conflicts with the canonicalization signal and can cause Google to disregard the hreflang annotation entirely.
• Assuming Search Console will catch problems automatically, a reasonable assumption before 2022 that no longer holds now that the International Targeting report is gone.
• Mixing implementation methods inconsistently across a site, for example annotating some templates with HTML tags and others through the sitemap, then letting the two fall out of sync during a redesign. Google treats all three methods as equally valid, but only if whichever one a page actually uses is complete and reciprocal; a half-migrated setup where one template still has old tags and another has none is functionally the same as having no hreflang at all on the pages caught in between.

An audit that turns up a handful of these issues isn't a sign the whole approach failed. Given how easily a single missing return tag or one invalid region code can quietly disable an entire cluster, finding several small, fixable errors on a first pass is the normal, expected outcome, not a red flag about the site's broader setup.

Related: canonical tags and canonicalization explained, crawling vs. indexing, sitemap priority, changefreq, and lastmod explained.