← Back to Blog

Hreflang Audit — Fetches Every Page in the Cluster and Builds the Backlink Matrix

Hreflang Audit — Fetches Every Page in the Cluster and Builds the Backlink Matrix

Hreflang is the only common SEO directive where the declaration on one page is invalidated by what's missing on another page. If your English page declares a Spanish alternate, and the Spanish page fails to declare the English original in return, Google silently drops the whole cluster. Both pages lose their locale-specific ranking and start competing with each other instead of serving the right language to the right searcher.

Single-URL hreflang validators miss this by definition. They check the page you give them, find a syntactically valid hreflang block, and tell you "looks fine." The failure lives two fetches away.

The Hreflang Audit tool exists to do what a single-URL validator cannot: fetch every alternate in the cluster, parse their hreflang blocks, and produce a matrix of who-declares-whom. Missing cells are Google's reason to discard the whole cluster.

What it checks

The audit runs nine checks per cluster:

  1. Self-reference, every page must include a <link rel="alternate" hreflang="<self-tag>" href="<self-url>"> pointing at itself. Without self-reference, Google disregards the entire cluster. This is the most common hreflang failure.

  2. x-default present, Google recommends (not requires) an x-default fallback. Without it, users whose locale matches nothing in your cluster get a coin-flip instead of your preferred landing page.

  3. ISO code validity, the language part must be a valid ISO 639-1 code (en, de, pt). The region part, if present, must be either ISO 3166-1 alpha-2 (en-US, pt-BR) or a UN M.49 three-digit region. Common mistakes: en_US (underscore not allowed), en-UK (the region is GB, not UK), pt-BRZ (3-letter region invalid).

  4. Duplicate hreflang values, two <link> tags with the same hreflang value cannot both be right. Google picks one and ignores the other.

  5. HTTPS consistency, mixed http/https alternates confuse Google's cluster matching.

  6. Absolute URLs only, Google silently ignores relative hreflang hrefs. /es/ is wrong; https://example.com/es/ is right.

  7. Canonical matches self, on a localized page, <link rel="canonical"> should point at that same page. Pointing canonical at a "master" locale tells Google the master is the real page and this one is a duplicate, the exact opposite of what hreflang is trying to communicate.

  8. Bidirectional cluster, the headline check. Every alternate page must declare a hreflang link back to the target. The tool fetches each alternate and builds a complete backlink matrix. Any missing cell invalidates the cluster.

  9. <html lang> matches self hreflang, not Google-critical, but screen readers and locale-detection libraries pay attention. If the page declares hreflang="de-de" for itself but ships <html lang="en">, something's out of sync.

The backlink matrix

The most important output is the matrix. Rows are pages in the cluster, columns are hreflang targets, and cells indicate whether that row's page declares that column's target in its hreflang block. Self-references are golden-yellow, declared backlinks are green, and missing cells are red.

A healthy four-locale cluster shows a fully-populated matrix with self-references on the diagonal and green cells everywhere else. A broken cluster has red cells, and the red cells tell you exactly which page needs a specific <link> tag added.

Why this is worth the fetch cost

Each hreflang audit fetches up to 12 pages (one target + up to 11 alternates). On a four-locale cluster that's four HTTP requests through the Netlify proxy. That's more than a single-URL validator, but it's the only way to catch bidirectional failures.

The alternative, waiting for Google to silently demote your cluster and then debugging why your /es/ page isn't ranking in Spain, is far more expensive.

Typical failures you'll find

From the sites I've audited:

  • Template-applied English hreflang block on every locale, so the Spanish page declares hreflang="en" pointing at the English page but no hreflang="es" self-reference. Fix: move the hreflang block into the locale-specific layout, not the global header.
  • Canonical pointing to the English master on every localized page. This is a classic "we consolidated duplicate content" pattern that breaks hreflang. Fix: canonical is self, hreflang handles cross-locale relationships.
  • Relative hreflang hrefs (/es/product/) that work in-browser but Google ignores. Fix: absolute URLs.
  • en-UK instead of en-GB. Fix: UK is not an ISO region code.
  • hreflang="de" on a page that only serves German-speaking Germany and Austria. Fix: if the content is region-specific, use de-DE and de-AT explicitly; de matches German globally including Swiss-German audiences that may not want the same variant.

After the audit: the Hreflang Generator

The audit tells you what's wrong. The Hreflang Generator emits the corrected block. Paste your locale-to-URL map, choose whether you want the HTML <link> form, the sitemap.xml <xhtml:link> form (cleaner for 10+ locales), the HTTP Link header form (for PDFs and non-HTML), or the Next.js/Astro array form, and ship.

Then run the audit again to confirm the backlinks landed.

The cost of not auditing

Hreflang failure is silent. GSC doesn't flag it. Screaming Frog reports "hreflang found" and moves on. Bing Webmaster Tools has no hreflang report at all. The only symptoms are:

  • Your Spanish page ranks in en-US results instead of es-ES
  • Your German page stops appearing in google.de
  • Your international traffic plateaus even though you shipped localized content

Those symptoms can take months to notice. A bidirectional audit takes 30 seconds.

Related reading

If you run a multi-locale site and want the full internationalization + indexing playbook I use on client sites, the $20 Dollar Agency walks through the SOP: The $20 Dollar Agency.

Fact-check notes and sources

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026