Hreflang to Blocked

What "hreflang to blocked" means

Hreflang is how you tell Google that two or more pages are the same content in different languages or regions, so it can show the right version to the right searcher. For that to work, every URL you name in an hreflang cluster has to be a page Google is allowed to crawl and index. This check fires when one of those named alternates is blocked: disallowed in robots.txt, tagged noindex, sitting behind an authentication wall, or returning a non 200 status.

Here is the trap. Google treats hreflang as a set of mutual claims. If your English page says "my German alternate is /de/" but /de/ is blocked, that claim points at a dead end. Google cannot verify the relationship, so it does not just drop the German page from the cluster. It can discard the entire annotation set as unreliable. One blocked target can poison the targeting for every language you carefully set up.

Why this is worse than it looks

Most hreflang mistakes degrade quietly. This one degrades quietly and completely. You will not get a 404. You will not see a red error in a browser. What you get is Google reverting to its own judgement about which page to rank in each country, which is exactly the decision hreflang exists to take out of its hands. Symptoms usually show up as the wrong language version ranking in a market, cannibalisation between your own regional pages, or a German user landing on your English page and bouncing.

Search Console's International Targeting and the hreflang portions of the Coverage data will often show the alternate as "no return tags" or simply omit it, because from Google's side the page it was told to pair with is unreachable. So you get a symptom that looks like a return tag problem when the root cause is a block.

The three ways a target gets blocked

How to detect it

• Screaming Frog SEO Spider. Crawl with hreflang extraction on, then use the Hreflang tab and its filters. It cross references each alternate against the crawl, so a target that is noindex, disallowed, or non 200 shows up directly. The "Non 200 Hreflang URLs" and noindex filters are the ones to sort by.
• robots.txt tester and live fetch. For each flagged alternate, fetch it as Googlebot in Search Console's URL Inspection. It tells you plainly whether the URL is allowed, indexable, or blocked, and why.
• Sitebulb. Reports hreflang targets that are noindexed or blocked as dedicated hints with the source pages attached.
• Server logs. If you suspect an auth or IP wall, check what status Googlebot actually receives for the alternate. A 200 for you in a browser can be a 403 for the crawler.

How to fix it, step by step

1. Export the flagged alternates and, next to each, record why it is blocked: robots.txt, noindex, auth, or bad status. The fix depends entirely on the cause.
2. If robots.txt is the culprit, remove the Disallow rule that covers that path. Blocking a page you want indexed and paired is almost always a mistake left over from a staging config.
3. If a noindex tag or X-Robots-Tag header is present, strip it. A page cannot be both a valid hreflang alternate and noindexed. Pick one.
4. If the page sits behind login or an IP allowlist, expose the public version. Often the indexable public page exists at a different URL, so point hreflang at that URL instead.
5. If the target 404s or redirects, update the hreflang value to the final live 200 URL and confirm the return tag exists on that page.
6. Re-crawl and re-inspect. Confirm every alternate in the cluster returns 200, is indexable, and carries the reciprocal return tag back to the others.

What good looks like

Every URL named in an hreflang set is a 200, indexable, crawlable page that returns the tag back to its partners. No alternate is disallowed, none is noindexed, none needs a login. When that holds across the cluster, Google trusts the annotations and serves the right language version in the right market. That is the entire point, and it only works if the whole set is clean.

FAQ