Hreflang Points to Broken URLs: How to Fix It

What this check flags

SEO ProCheck found hreflang annotations aimed at URLs that don't return a healthy 200 — they answer with a 4xx, a 5xx, or a redirect chain that ends somewhere unexpected. An hreflang target has to be a live, indexable page; when it 404s or errors, Google can't confirm the return relationship, so the whole language cluster around that node collapses and the market it served drops back to a default result.

Why a dead target poisons the set

Hreflang confirmation is reciprocal. Page A points at page B, and Google will only trust the link if it can fetch B and read a matching return tag pointing back at A. If B answers 404, there is nothing to fetch and no return tag to confirm — the edge is void. Worse, because the set is interconnected, a single broken member can leave several return tags dangling, and Google may distrust the neighbouring, perfectly healthy annotations too. Redirects are their own trap: an hreflang that points at a URL which 301s to another address makes Google resolve the hop before it can match a return tag, and if the final URL doesn't carry the expected annotation, the confirmation still fails.

A real failing example

Two of these targets are broken — one 404s after a site restructure, one redirects to a non-annotated URL:

<link rel="alternate" hreflang="en-us" href="https://brand.com/en-us/boots/" />        <!-- 200, fine -->
<link rel="alternate" hreflang="fr-fr" href="https://brand.com/fr-fr/bottes/" />        <!-- 404, page deleted -->
<link rel="alternate" hreflang="de-de" href="https://brand.com/de/stiefel/" />          <!-- 301 -> /de-de/stiefel/ (no hreflang there) -->
<link rel="alternate" hreflang="x-default" href="https://brand.com/en-us/boots/" />

Point every annotation at the final, live 200 URL and make sure that URL carries the full return set:

<link rel="alternate" hreflang="en-us" href="https://brand.com/en-us/boots/" />
<link rel="alternate" hreflang="fr-fr" href="https://brand.com/fr-fr/bottes-cuir/" />   <!-- new live URL after the restructure -->
<link rel="alternate" hreflang="de-de" href="https://brand.com/de-de/stiefel/" />      <!-- the redirect TARGET, direct -->
<link rel="alternate" hreflang="x-default" href="https://brand.com/en-us/boots/" />

Then confirm /fr-fr/bottes-cuir/ and /de-de/stiefel/ both return 200 and echo the complete set back.

Status codes and what they mean for the cluster

How to detect it

1. Screaming Frog — Hreflang tab. Crawl with hreflang extraction on, then use the Non-200 Hreflang URLs filter for the direct hit. Pair it with the Unlinked Hreflang URLs and Missing Confirmation Links filters to catch targets that resolve but don't return the tag.
2. Bulk status check. Export all hreflang destinations and run them through Frog's list mode or a curl -sI -o /dev/null -w "%{http_code} %{url_effective}n" -L loop to log the final status and any redirect hop for each URL.
3. Google Search Console. URL Inspection on a target shows whether Google fetched it and whether coverage is "Crawled — currently not indexed" or an error; the legacy International Targeting report lists "no return tags," which broken targets trigger.
4. An hreflang validator. The Hreflang Validator fetches each destination and reports non-200 responses and missing return links in one pass.

How to fix it

1. Export every hreflang target and record its final status code after following redirects.
2. For 404/410 targets, find the live equivalent and repoint the annotation there; if no equivalent exists, remove that language from the set rather than leaving a dead row.
3. For redirected targets, update the annotation to the redirect's destination so Google never has to resolve a hop — and verify that destination carries the full return set.
4. For 5xx targets, fix the underlying server or CDN error first; an unstable target confirms and un-confirms on every crawl.
5. Re-crawl and confirm the Non-200 Hreflang URLs filter is empty, then spot-check a few pairs for reciprocal return tags.

Broken hreflang targets often ride along with wider crawl issues, so it pays to sweep them with your general broken-link workflow and the hreflang implementation guide for how return tags are meant to resolve. If redirects are the recurring culprit, the canonical and status-code reference helps you keep targets pointing at final URLs. Use one delivery method for the whole set so a stale sitemap can't reintroduce dead targets.

FAQ

Is pointing hreflang at a redirect really a problem if it eventually resolves?

Yes. Google has to follow the hop and then find a matching return tag at the end; every extra step is a chance for the confirmation to fail. Always annotate the final 200 URL directly.

One page 404s but the rest are fine — can I ignore it?

No, because the dead node leaves several return tags unconfirmed, and Google may distrust the healthy neighbours in the set. Fix or remove the broken row.

What about targets behind geo-redirects that serve different content by IP?

Those are dangerous: Googlebot crawls from a fixed region and may hit a redirect a user wouldn't, producing a phantom broken target. Use hreflang for targeting instead of IP redirects on the annotated URLs.

How often should I re-check target status?

After any site migration, URL restructure, or bulk redirect. Those events are exactly what turns a healthy hreflang set into a field of 404s overnight.