Google processes hreflang as a cluster-level agreement, not a set of independent per-page hints. Every URL you annotate as part of a language/region set has to reciprocally confirm every other URL in that set through return tags, meaning URL A must reference URL B, and URL B must reference URL A back, for every pair in the group. If that reciprocity is broken anywhere, if even one URL in the cluster hasn’t been crawled yet, carries a conflicting canonical tag, or simply fails to return-tag the others, Google’s documented behavior is to be able to discard the hreflang signals for that entire set rather than partially honor the URLs that are configured correctly. This is why markup that passes every validator can still produce zero visible hreflang effect: validation checks syntax, not the live crawl-and-index state of every other URL the cluster depends on.
The mechanism: why hreflang needs the whole cluster, not just one page
Google’s hreflang documentation is explicit that annotations must be reciprocal: if page A links to page B via hreflang, page B must link back to page A, and this holds across every URL pair in the set, not just adjacent ones. The reasoning is straightforward from Google’s side: hreflang is a claim about a set of URLs being alternate versions of each other, and a one-directional link doesn’t establish that a mutual relationship actually exists. Anyone could add an hreflang annotation pointing at someone else’s URL; only a matching return annotation confirms both sides agree on the relationship. Without that mutual confirmation, Google has no reliable way to trust the claimed relationship, so it treats the annotation as unconfirmed and, per its own guidance, can ignore hreflang for the URLs involved.
This has a crawl-and-indexing dependency that’s easy to miss during implementation review. Confirming a return tag isn’t a markup-parsing exercise; it requires Google to have actually crawled and processed the other URL to see its hreflang block. If a new URL in the cluster hasn’t been crawled yet (common right after launching a new locale, or on a large site where crawl budget doesn’t reach every URL promptly), Google literally cannot verify the return tag yet, regardless of what’s correctly sitting in that URL’s HTML. The annotation is technically correct and sits unconfirmed until the crawl catches up, and during that window the cluster’s hreflang signals may not be honored at all, which looks from the outside like hreflang “not working” even though every tag is syntactically valid.
Conflicting canonical tags compound this in a specific way. If a URL inside an hreflang cluster carries a canonical tag pointing to a different URL (inside or outside the cluster), Google has two competing instructions about that URL’s identity: the hreflang cluster says it’s a distinct language/region alternate deserving its own presence in results, while the canonical tag says it’s a duplicate that should be consolidated elsewhere. Google’s documentation notes that canonicalized URLs are not reliable candidates for hreflang clustering, since a non-canonical URL isn’t necessarily the version Google will choose to index and serve. When this conflict exists, the safer assumption for diagnostics is that the canonicalization signal takes precedence over the hreflang claim for that URL, which can pull it, and the confirmations it was supposed to provide to the rest of the cluster, out of the equation.
Where the annotations live also affects processing timing. hreflang can be implemented in the HTML head, in HTTP headers (for non-HTML resources), or in an XML sitemap. Sitemap-based hreflang depends on Google recrawling the sitemap itself to pick up changes; if the sitemap isn’t fetched and reprocessed promptly (which depends on how often Google recrawls that sitemap, itself a function of the site’s overall crawl patterns), updates to hreflang relationships declared there can lag well behind updates made directly in HTML head tags, which get picked up whenever Google next crawls the page itself.
Diagnosing “correct implementation” that still isn’t processed
Code-level review, checking that tags are well-formed, language-region codes are valid, and self-referencing annotations exist, verifies syntax only. It cannot tell you whether Google has actually confirmed the return-tag relationship across the live cluster, because that requires knowing the current crawl and index status of every URL involved, not just the one you’re looking at.
The practical diagnostic tool is Search Console’s International Targeting report, which surfaces hreflang-specific errors including missing return tags, and which URLs Google has flagged as having confirmation issues. When investigating a cluster that seems to have “correct” markup but isn’t producing the expected results, cross-reference three things for every URL in the set: whether it’s actually indexed (via URL Inspection), whether its canonical tag matches its own URL or points elsewhere, and whether its hreflang block includes accurate return references to every other member of the cluster. A single unindexed or wrongly-canonicalized URL anywhere in a large cluster is often enough to explain signals not being honored for URLs that, viewed individually, look perfectly implemented.
The operational lesson is that hreflang audits need to be run at the cluster level and cross-referenced against live crawl/index state, not evaluated page by page against a markup checklist. A pattern that’s syntactically flawless but depends on a URL Google hasn’t recrawled recently, or one carrying a stray canonical tag, will behave exactly as if the implementation were broken, because from Google’s processing standpoint, the confirmation the whole cluster depends on is genuinely missing.
