Hreflang Bidirectional Validation — en→es Must Have es→...

A multilingual site I audited last month had this in its English homepage:

<link rel="alternate" hreflang="en" href="https://example.com/">
<link rel="alternate" hreflang="es" href="https://example.com/es/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">

Looks fine. H1 checks out, meta description translated, schema localized. Every indexing tool said "hreflang: valid."

I fetched the Spanish page. Its hreflang block:

<link rel="alternate" hreflang="es" href="https://example.com/es/">
<link rel="alternate" hreflang="x-default" href="https://example.com/es/">

No English alternate. No link back to / as hreflang="en". The English page claimed a Spanish sibling; the Spanish page didn't acknowledge the English one existed.

Google's official hreflang documentation is unambiguous: if page A links to page B, page B must link back to page A, or Google ignores the entire cluster. The cluster doesn't just fail — it fails silently, with no error in GSC, no warning in any standard audit tool, and no obvious symptom except that the pages rank worse than they should.

Why one-way hreflang breaks the cluster

Hreflang is a declarative bidirectional graph. The semantics are "these URLs are equivalent content in different languages." Google validates the declaration by checking that both endpoints agree:

English page says "Spanish version is at /es/"
Spanish page says "English version is at /"
Both sides confirm; cluster is valid; Google serves the right locale to the right searcher

When only one side declares, the graph is asymmetric. Google can't confirm the Spanish page actually considers itself a Spanish version of the English page. The declaration could be a mistake. Google's conservative default: ignore both declarations. Now the English page is treated as a standalone page with no international variants, and the Spanish page is treated as a different standalone page. They compete for the same queries in different locales instead of being served intelligently.

The effect is a silent ranking demotion in regions where the "other" locale would have been the better match. Searcher in Mexico gets the English page. Searcher in the US sees a Spanish page in their results. Both confused; both bounce; both rank worse.

The common ways hreflang breaks one direction

Translator-first workflow. Someone builds /index.html first, adds hreflang="es" declaration to plan for the Spanish version. Months later, someone builds /es/index.html as a fresh file — they don't copy the hreflang block, just add new declarations from scratch, and miss the reverse link.

Static template drift. The English template has a full hreflang block. The Spanish template is a copy from three versions ago that hasn't been updated with the latest hreflang="zh" or hreflang="de" addition. Every language except the out-of-date one is fine; the out-of-date one silently breaks.

Auto-generated vs hand-written. English page uses a CMS that auto-generates the hreflang block from the site's translation config. Spanish page is a landing page hand-coded by the marketing team with minimal frontmatter. Hand-coded page has hreflang="es" self-referential only; no reverse link back to English.

Regional localization split. Page has hreflang="en-US" declared. Sibling page has hreflang="en" (no region). Google treats these as different locales; they aren't hreflang-equivalent from its perspective even though the intent was parity.

Trailing-slash inconsistency. English links to /es/. Spanish self-declares as /es (no trailing slash). Google sees these as different URLs; the bidirectional check fails.

What the audit does

The new Mega Analyzer's Indexing Hygiene tab now validates hreflang bidirectionality automatically. When you run the audit on a page:

Extract every <link rel="alternate" hreflang="..." href="..."> from the page (excluding x-default and self-reference).
For each alternate, fetch the target URL via the /.netlify/functions/fetch-page proxy.
Parse the target's HTML, extract its hreflang block, and check for a reverse link pointing back to the originating URL.
Flag every alternate that's missing a reverse link.

The check is bounded to six alternates per page (to keep fetch cost reasonable). That covers the vast majority of multilingual sites; the hyper-international cases with 20+ locales can run the tool on each locale separately.

The findings appear in the Indexing Hygiene tab:

2 hreflang alternate(s) missing reverse link back to this URL Google requires bidirectional hreflang. If en→es exists, es→en must exist too. Broken: es → https://example.com/es/ (no reverse link), zh → https://example.com/zh/ (no reverse link). Fix by adding a self-ref link cluster to every alternate.

The fix is mechanical: add the full hreflang block to every page in the cluster. The block should be identical across all pages, just rooted at each URL's own hreflang:

<!-- This block should appear identically on every page in the cluster -->
<link rel="alternate" hreflang="en" href="https://example.com/">
<link rel="alternate" hreflang="es" href="https://example.com/es/">
<link rel="alternate" hreflang="zh" href="https://example.com/zh/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">

Copy-paste it into _includes/head.njk (or equivalent base template) so every language's template renders the same block. Self-reference is fine — the English page can include its own hreflang="en" tag, the Spanish page can include its own hreflang="es", etc.

What else to check while you're there

Hreflang has a few other common misconfigurations worth verifying:

x-default missing. Add <link rel="alternate" hreflang="x-default" href="..."> as the fallback for searchers whose locale doesn't match any declared language. Typically points to the English version. Without x-default, Google guesses, and guesses badly.

ISO code wrong. hreflang="spanish" is invalid. The code must be ISO 639-1 (es) or language-country (es-MX, es-ES, es-US). Case doesn't matter but the structure does.

Protocol or subdomain mismatch. hreflang="en" href="http://example.com/" when the canonical is https://. Or hreflang="es" href="https://es.example.com/" when the site uses example.com/es/. Every URL in the block must resolve to the canonical domain + protocol.

Trailing slash inconsistency. hreflang="es" href="https://example.com/es" vs the canonical .../es/. Trailing slashes matter; match them.

Pointing at URLs that 404 or redirect. hreflang="fr" href="https://example.com/fr/" but /fr/ returns 404 or 301 to /en/. The hreflang declaration is false. Google eventually drops the alternate, but it takes weeks.

The fact Google won't tell you

Google Search Console used to surface hreflang errors explicitly. The "International Targeting" report under "Search Traffic" in the old Search Console UI listed per-URL hreflang errors. That report was deprecated in the 2020 GSC redesign and never fully replaced. The current UI has no dedicated hreflang error report.

GSC's URL Inspection tool can show hreflang tags Google detected for a URL, but it does not tell you which of those tags failed bidirectional validation. You have to discover failures by running an external audit or reading Google's server logs — which, for a typical SMB operator, means never discovering them.

This is why a browser-based audit is high-leverage. You run it once after deploying a new language, and you catch the asymmetry before it costs you weeks of demotion.

Fact-check notes and sources

Google hreflang bidirectional requirement: Google Search Central — Tell Google about localized versions of your page
hreflang ISO code reference: ISO 639-1 codes for languages, ISO 3166-1 alpha-2 for country variants
x-default usage: Google Search Central — Advanced hreflang tag reference
Deprecation of the International Targeting report in Google Search Console: SEO community discussion, Aug 2022

Run the Mega Analyzer on a multilingual page. Check the Indexing Hygiene tab. If the hreflang bidirectional check fires, you've got a cluster Google is currently ignoring.

Hreflang Must Be Bidirectional — Why Google Demotes Multilingual Sites With One-Way Links