Canonical Points to Disallowed URL: How to Fix It

This check fires when a page's rel="canonical" points at a URL that is blocked by robots.txt. The target might return a perfectly healthy 200 — but Google is not allowed to fetch it, so it can never verify the canonical relationship, and an unverifiable canonical is a canonical Google is free to overrule.

What this check flags and why it bites

Every other failure in this cluster is "Google fetched the target and it was broken." This one is different: Google never gets to look. A robots.txt Disallow stops the crawl before the canonical can be confirmed, so Google treats your declared canonical as a weak, unverified hint and often canonicalizes onto a different URL it can crawl — frequently the page you were trying to point away from.

A real failing example

Filtered category page /shop/shoes/?color=red tries to consolidate onto the clean canonical:

<link rel="canonical" href="https://example.com/shop/shoes/" />

Sensible — except the site's robots.txt blocks the entire /shop/ tree to save crawl budget:

$ curl -s -A 'Mozilla/5.0' https://example.com/robots.txt

User-agent: *
Disallow: /shop/

The canonical target itself is fine when you fetch it directly:

$ curl -sI -A 'Mozilla/5.0' https://example.com/shop/shoes/

HTTP/2 200
content-type: text/html; charset=utf-8

But Googlebot obeys the Disallow and never requests it. It sees a canonical pointing into a black box, cannot confirm the two pages are duplicates, and picks its own canonical — possibly the parameterized URL you never wanted indexed.

The fix is to unblock the canonical target so Google can crawl and verify it:

User-agent: *
Disallow: /shop/*?color=
Allow: /shop/shoes/

Blocked target vs. other canonical failures

The distinction that matters: robots.txt controls crawling, not indexing. Blocking the target does not remove it from the index — it just blinds Google to the signal you were trying to send.

This failure is especially insidious on large e-commerce and faceted-navigation sites, where a broad Disallow is added to protect crawl budget from parameter explosion. The rule does its job on the junk URLs, but if the clean canonical master happens to live under the same path prefix, it gets caught in the same net. Nobody notices because the pages still render for humans and still resolve for direct curl — the only symptom is Google quietly choosing its own canonicals and the "clean" URLs never accumulating the authority you routed to them. The bigger the site, the longer this hides in plain sight.

How to detect it

1. Screaming Frog: configure it to respect robots.txt, crawl, then open Response Codes > Blocked by Robots.txt and cross-reference the Canonicals tab. Any canonical target sitting in the blocked list is this error. The Canonicals > Canonical Links to Non-Indexable URL filter also surfaces it.
2. GSC robots.txt Tester & URL Inspection: inspect the affected page — if the declared canonical is blocked, Inspection shows "Crawl allowed? No: blocked by robots.txt" for the target. The URL Inspection tool confirms crawlability per URL.
3. curl the robots.txt directly: fetch /robots.txt and grep for the path prefix of your canonical target. If a Disallow rule matches it, Googlebot will not crawl it.

How to fix it

1. Identify the canonical target and confirm which robots.txt rule blocks it (watch for wildcard and precedence quirks).
2. Decide the intent: if that URL is the true master, it must be crawlable — remove or narrow the Disallow so Google can reach it.
3. Prefer surgical rules: block only the parameter variants (Disallow: /shop/*?color=) rather than the whole directory that contains your canonical.
4. If you genuinely need the target out of the index, do not block it — let it stay crawlable and add a noindex instead (but never as a canonical target — that is a different error).
5. Re-fetch /robots.txt, confirm the target is now allowed, and validate in GSC.

FAQ

The blocked target returns 200 — why is this even a problem?

Because Google never fetches it. A canonical it cannot crawl is a canonical it cannot verify, so it downgrades your hint and may consolidate onto a crawlable URL you did not choose.

Does robots.txt-blocking the target remove it from Google's index?

No. Blocking controls crawling, not indexing — a blocked URL can still be indexed from links. To keep a page out of the index you need noindex on a crawlable page, not a Disallow.

Should I just remove the canonical instead of unblocking the target?

Only if the current page should stand on its own — then self-canonicalize. If the two pages really are duplicates, the master has to be crawlable; unblock it.

My robots.txt has wildcards — how do I know which rule is matching?

Precedence and wildcard behavior trip people up constantly. Test the exact target URL against your rules; the Complete robots.txt Reference covers precedence, wildcards, and real-world edge cases.

Related canonical checks

This is the "cannot verify" case; the rest of the cluster are "verified and broken": Canonical Points to a 404, Canonical Points to a 5xx Error URL, Canonical Points to a Noindex URL, and the AMP-specific variant AMP Canonical Points to Disallowed URL. Also worth a look: Disallowed Image for the same robots.txt trap on assets.