Why an hreflang target is reported as dead

By Matt Kerr·Published 18 September 2026

An audit says your hreflang tags point at URLs that do not work. Before you edit a single tag, it is worth knowing that "does not work" covers four quite different situations — and on the two most common ones the honest answer is that the tool learned nothing.

The four causes, and who each one is about

• The target returns an error. A 404 or a server error on a URL your hreflang names is real and worth fixing: you are telling search engines that the Spanish version of this page lives somewhere that is not there.
• The target is set to noindex. Also real, and quieter. An hreflang cluster pointing at a page you have asked search engines to ignore is a contradiction you wrote yourself.
• The target refused the crawler. This is a fact about the audit, not about your site. A 403 to one tool says nothing about what a search engine is served, and it is not evidence that anything in the cluster is broken.
• The target sent nothing at all. A status of zero is not a response — it is a refused connection, a DNS hiccup, a timeout, a dropped packet. The tool has no information whatever about that URL.

The last two used to be reported like the first two. The zero case sat inside the error branch and produced a medium-severity finding saying the reader's hreflang tags pointed at "unusable URLs" that returned "no response" — from a blip on one machine.

The refusal that deliberately says nothing

Worth its own paragraph, because the fix here was to report less.

When a target refuses the crawler, the check could add an "unverified" note of its own. It does not — because if the site is refusing the audit at all, the site-level check already says so, clearly, once. Two findings describing one fact are not twice as informative; they are the same news twice, and the reader has to work out they are the same thing.

For what a refusal does and does not tell you, see "could not be reached" is not a diagnosis →.

The redirect test that could only fire on correct sites

This is the half worth the page. The remaining cause — an hreflang target that redirects somewhere else instead of resolving directly — is genuinely worth reporting, because a cluster resolves better when every URL in it is a destination rather than a stop on the way.

The old test read the wrong end of the data. A crawler records, for each page it fetched, the chain of URLs that led to that page. That chain is non-empty exactly when the crawler arrived by being redirected — which makes the page it is attached to the final destination, the thing hreflang is supposed to point at.

So the check fired when the target was already right. On one site with thousands of distinct hreflang targets it produced exactly one finding: a URL that returns 200 and does not redirect anywhere, which the crawler had simply reached from a different address. The advice attached was point each hreflang at the final destination URL — given to a site that already was.

A test that fires only on correct input is worse than a test that never fires, because it produces confident work for people who had nothing to fix, and it is invisible in aggregate: the finding count looks plausible, the affected sites look unlucky, and nobody investigates a rule that is quiet on the sites where the fault is real.

The repair was to collect the URLs that were redirected away from — the first entries of those chains — and test membership of that set instead.

Reading this on your own report

• Look at the reason beside each target, not the headline. "Returns 404", "is set to noindex", "redirects instead of resolving" and "returned no response" are four different jobs, and one of them is not a job at all.
• Open a target that was called unreachable. If it loads in a browser, the finding was about the crawl.
• Check whether the whole site refused the audit. If there is a site-level refusal finding, treat every target-level one as unverified rather than false.
• For a redirecting target, follow it once. Point the tag at where you land, and check the page you land on carries the return tag back.

When this matters

An hreflang cluster is a set of mutual claims, and one bad member weakens the set rather than just itself — which is why a dead target is worth more attention than its severity suggests. But that is true only of the causes that are about your site. A target reported as unreachable by a tool that could not connect is not a defect in your markup, and rewriting tags to chase it makes a correct cluster wrong.

The fixes that make it worse

• Removing an hreflang entry because its target was unreachable during one crawl. You have broken a mutual set to satisfy a transient network condition.
• Repointing tags at URLs that were already destinations. The unfollowable advice above, and the reason the test was rewritten.
• Adding a redirect so the target "resolves". The target was fine; the tag should name it directly and usually already does.

How to clear this without improving anything

Delete the hreflang annotations. Every target-health finding disappears, along with any chance of the right language version being served — which is the general shape of these pages: the fastest way to a clean report is always to remove the thing being measured.

Where this sits in an audit

The registered check is intl.hreflang_targets, which covers hreflang target health. Its siblings cover the other halves of the subject: return tags and the four ways a set breaks →, and invalid language and region codes →.

Common questions

My hreflang targets load fine but the audit calls them unreachable. Why?

Because the crawler got no response — a refused connection, a DNS hiccup or a timeout. A status of zero is not something your server sent, so nothing has been learned about that URL.

Is a 403 on an hreflang target a problem?

Not necessarily. A refusal is a fact about the tool that asked, not about what a search engine is served. If the whole site refused the audit, treat target-level findings as unverified.

Should hreflang point at a URL that redirects?

No — point it at where the redirect lands, and make sure that page carries the return tag back. A cluster resolves better when every member is a destination.

Can an hreflang target be noindex?

It should not be. Naming a page in a language cluster while telling search engines to ignore that page is a contradiction, and the cluster is the easier half to correct.

One bad target — does it matter?

More than its severity suggests. An hreflang set is a group of mutual claims, so a member that does not resolve weakens the set rather than only itself.