Fixing Hreflang That Points at 404s or Redirects

What counts as a broken target

A hreflang target is the address in the href of an alternate link, or in the href of an xhtml:link entry in a sitemap. For Google to use it, the request for that exact address should return status 200 with the page itself. Anything else is a problem of some kind:

Redirects deserve a closer look because they seem harmless. A visitor who follows a redirect still arrives somewhere useful, so the page appears to work. But hreflang is a statement about specific addresses. If the British page names /de/zubehoer/ and that address redirects to /de/zubehor/, the German page's own annotations will name the new address, not the old one, so the pair no longer matches. A redirected target very often creates a return tag error as a side effect.

Where broken targets come from

• Deleted content in one locale only. A seasonal product is removed from the French store but kept elsewhere. The other locales still list the French address, which now returns 404.
• Slug changes after publishing. An editor improves a translated slug. The CMS adds a redirect for visitors, but annotations stored as text, or cached pages, keep the old address.
• Site migrations. Moving from example.fr to example.com/fr/, or changing the folder pattern from /fr/ to /fr-fr/, turns every old address into a redirect. Annotations generated before the move keep pointing at them.
• Markets closed or paused. A country store is switched off and its domain redirected to the main site, but the remaining locales still list it.
• Protocol and host changes. Moving to https, or between www and the bare domain, adds a redirect in front of every hard-coded address.
• Geo or language redirects. A server that sends visitors to a country version by IP address or browser language gives crawlers a redirect instead of the page. Because Google mostly crawls from the United States, it may never see the non-US versions.
• Relative addresses. An href such as /fr/page/ or fr/page/ is not a fully qualified address. Google's documentation asks for absolute URLs including the protocol, and relative ones are easy to resolve incorrectly.

Testing every target

The Hreflang Checker probes each target in the clusters it follows and reports the ones that are not reachable, which is the quickest way to see the scale of the problem. For a full-site inventory, extract the targets and request them yourself. The key is to request each address without following redirects, so you see the first response rather than the final destination.

For a single address:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "https://example.com/de/zubehoer/"

For a list of addresses in a file, one per line, a short loop reports everything that is not a plain 200:

while read -r url; do
  out=$(curl -s -o /dev/null --max-time 10 -w "%{http_code} %{redirect_url}" "$url")
  code=${out%% *}
  [ "$code" != "200" ] && echo "$code $url -> ${out#* }"
done < hreflang_targets.txt

If your annotations are in a sitemap, you can build that list from the sitemap itself:

curl -s https://example.com/sitemap.xml \
  | grep -o 'xhtml:link[^>]*href="[^"]*"' \
  | sed 's/.*href="\([^"]*\)"/\1/' \
  | sort -u > hreflang_targets.txt

For sites with a sitemap index, repeat for each child sitemap. For HTML annotations, export the targets from a crawler instead, because parsing HTML with grep is unreliable.

Spotting soft 404s

A status check will not catch pages that return 200 with "product not found" or an empty template. Two quick signals help: pages whose size is far smaller than others of the same type, and pages whose title contains words such as "not found" or "no longer available" in any of your languages. Check those by hand.

Choosing the right repair

Group the failures by cause before editing anything. The same fix usually applies to hundreds of addresses at once.

Redirected targets

Replace each redirecting address with the address it finally lands on, but only after checking that the final page is the correct equivalent. After a migration, the redirect map you used for the move is the best source: it already pairs every old address with its new one. Apply it to the annotations, not just to the server.

Missing or gone targets

Ask whether an equivalent page should exist. If the product or article was translated and the page was removed by mistake, restore it. If it was moved, use the new address. If the locale no longer has that content, remove the locale from the cluster on every page, not just one, otherwise you trade a broken target for a return tag error. Never replace a missing translation with the locale's home page or a category page; that is not an equivalent.

Temporary redirects

A 302 or 307 on a hreflang target is usually a redirect based on location, language or cookies. Turn it off for the addresses in your clusters and offer a visible country or language switcher instead. If the redirect exists because the target needs a login, that page should not be in a hreflang cluster.

Server errors

Retest 5xx responses a few times. An intermittent fault points at load, timeouts or a bad deployment, and needs fixing on the server; the annotation itself is fine. A permanent error on one locale's template usually means a missing translation string or a broken query for that language.

Address format problems that behave like redirects

Many "redirecting" targets are not old pages at all. They are the right pages written in a slightly different form, and the site redirects to its preferred form. The fix is to standardise the form the annotations use.

Build annotations from the same canonical address field the page uses for its own link rel="canonical". Then the target, the canonical and the page's own self-referencing annotation will always match, and a change of protocol or host is picked up everywhere at once.

The fix, step by step

Hreflang during a site migration

Migrations are the single biggest source of broken targets, because every address in every cluster can change at once. A sequence that avoids a long period of broken annotations:

1. Before the move, export the current clusters so you have a record of every group of locale pages.
2. Build the redirect map from old to new addresses, including every locale, not just the main language.
3. Generate the new annotations from the new addresses, so that on launch day the pages already list their new siblings.
4. After launch, probe every target on the new site. Any redirect in the results means an annotation still uses an old address.
5. Keep the old addresses redirecting for the long term; they still matter for visitors and links, even though annotations should no longer use them.

If some locales move on a different date from others, update the annotations on the unmoved locales at the same time as each move, so no cluster points at redirects for weeks.