The page named as the main one is blocked by robots.txt
In the reportCanonical target blocked by robots.txt
canonical_target_blocked · Issue
This appears when pages name an address on your site's checked HTTP origin as their canonical, and a rule applying to Googlebot in that origin's robots.txt disallows the address's path. The pages point search engines to a page Googlebot may not read. Point the canonicals at a crawlable page, or allow crawling of the named one. A canonical on another protocol, host or port, including a www. or non-www. twin, is not judged by this origin's robots.txt.
Severity: High. Fix this conflict soon: your site's rule blocks the named path for Googlebot, though other crawlers and a twin host may follow different rules.
Why it matters
A canonical is a strong signal for which address should be shown. Google cannot read the content of a page robots.txt disallows, and it advises against using robots.txt for canonicalization; it does not describe a blocked canonical as an error, but the two signals conflict.
What to do
- Look at the finding: it shows the named address, the robots.txt line that blocks it and the pages that name it.
- If the named page should be in search, remove or narrow that line, or add an
Allowrule for it. - Otherwise change the canonicals on the listed pages to an address crawlers may read.
What we read
We read the canonical of each crawled page and group pages by the one other address on your site they name. We match that address's path against your robots.txt with the rules for Googlebot, or for * when there is no Googlebot group; the longest matching rule wins, and an allow rule wins a tie.
The named address is reported when robots.txt answered 200 and its rules forbid it; this robots verdict does not need a response from the address. Other audit work may also capture the target response and report a separate HTTP or noindex condition. A robots.txt that answers a 4xx other than 429 counts as having no rules, and a 429, a network failure or a server error leaves the check inconclusive. We apply this file only to canonical targets on the same protocol, host and port as the checked robots.txt; targets on another origin remain unconfirmed.
Example & evidence
Illustrative example — one page, the address it names and robots.txt, not a live audit.
https://bakery.example/cakes/chocolate-cake/ declares:
<link rel="canonical" href="https://bakery.example/shop/chocolate-cake/">and https://bakery.example/robots.txt answers 200 with:
User-agent: *
Disallow: /shop/The named address's path starts with /shop/, so line 2 blocks it, and it is reported with that line and the page that names it.
A possible correction: add Allow: /shop/chocolate-cake/ to the same group, a longer rule that wins, or change the canonical to a crawlable address.
Confirm & check again
Check for yourself: take the address from the page's rel="canonical" and compare its path with the rules in your robots.txt.
Check again: Full audit — Run a new audit of the site. A sufficiently complete recheck of the same target can close this finding when the checked origin’s current robots.txt rules no longer block that target for Googlebot. An unavailable robots policy or a target on another origin cannot establish that direct clean result. It can also close when complete, readable canonical inventories from every previously associated source page prove that none still names this address as its one canonical target. A complete inventory with multiple distinct canonicals may establish that; an unread or incomplete inventory cannot. A replacement target is judged separately: its health or robots policy is not part of proving that the old single-target group has disappeared. A missing, partial or non-HTML source response, or a redirect by itself, does not prove removal.
Limits & sources
This rule matches paths against robots.txt; it does not establish the named page's status or content. The audit may separately fetch that address for other target checks. Only Googlebot's rules from the checked HTTP origin are applied. A target on another protocol, host or port needs its own robots.txt; this audit does not use the checked origin's file to decide whether that target is blocked.
Confidence: Medium because Google does not document a blocked canonical as an error; the rule and the blocking line themselves are read directly.
Sources
- Google, How to specify a canonical URL with rel="canonical" and other methods — calls rel="canonical" a strong signal, and advises against using robots.txt for canonicalization. Checked 25 September 2026.
- Google, How Google interprets the robots.txt specification — explains how Google chooses the group and rule that apply, and that the rules cover only their own host, protocol and port. Checked 25 September 2026.
Editorial review: 2 November 2026