AMP Canonical Points to a Disallowed URL: How to Fix It

Your AMP page names a canonical, and that canonical target sits behind a Disallow line in robots.txt. Google can read the AMP file but cannot fetch the page it claims to be a copy of, so the pairing never gets confirmed and the AMP version drifts into limbo.

This is a narrow, specific failure. It is not the AMP URL being blocked, and it is not a noindex problem. It is the destination of the AMP page's rel="canonical" that a crawler is forbidden to touch.

What this check actually flags

Every valid AMP document carries exactly one canonical link, and that link is supposed to resolve to the standard, non-AMP page it mirrors. This check fires when the URL inside that canonical tag matches a path your robots.txt tells crawlers to leave alone. Picture an AMP file at /news/story/amp/ with this inside its head:

<link rel="canonical" href="https://example.com/private/story/">

and a robots file that says:

User-agent: *
Disallow: /private/

The AMP page is pointing at /private/story/ as its master copy, and the same server is telling Googlebot it may not request anything under /private/. The signal and the permission contradict each other. Google's crawler tries to fetch the canonical, gets stopped at the robots gate, and cannot verify that the two URLs are a matched set.

Why a blocked canonical target sinks the pairing

AMP consolidation relies on a round trip: the crawler fetches the AMP page, reads the canonical, fetches the canonical, and reads the amphtml link that (should) point back. Break any leg of that trip and consolidation collapses. A robots disallow breaks it at the fetch step. Google never confirms the relationship, so it treats the AMP URL as an orphan rather than a variant of a known page.

Worse, robots.txt does not stop indexing on its own. A blocked URL that picks up links can still surface as a bare, description-less result. So the canonical target can end up half-indexed while the AMP copy of it goes nowhere. You get the messy middle: two versions, neither one clean.

How to detect it

1. Open the AMP URL's source and copy the exact href from its <link rel="canonical"> tag. That value is the URL you are testing.
2. Run that canonical URL through a robots.txt tester (Search Console's robots report, or any standalone tester) against your live robots file. A "Blocked" verdict confirms the flag.
3. From the command line, fetch the robots file directly and read the rules yourself: curl -s https://example.com/robots.txt, then check the canonical path against every Disallow line for the relevant user-agent.
4. Crawl the site with Screaming Frog, tick "Crawl" and "Store" for AMP, then filter AMP → Non-Indexable Canonical to see every AMP page whose canonical is blocked in one list.
5. If you still run AMP in Search Console, cross-reference the canonical target in the URL Inspection tool — a "Blocked by robots.txt" note on that page corroborates it.

How to fix it

The right fix depends on whether that canonical target is a page you actually want in the index.

If the canonical is your real, wanted page: unblock it. Remove or narrow the Disallow rule so crawlers can reach the canonical URL. Confirm the page returns 200, carries a self-referencing canonical, and links forward to the AMP variant with rel="amphtml". That closes the handshake.

If the canonical was pointed at the wrong URL: correct the tag. The AMP page should canonicalize to the crawlable non-AMP version of the same content, not to some blocked staging or member path. Regenerate the AMP template so the canonical value is right at the source.

If you no longer need AMP at all: retire it cleanly. Strip the amphtml link from the standard pages, 301 the AMP URLs to their non-AMP equivalents, and let the old AMP entries fall out. Leaving a broken canonical in place because "AMP is dying anyway" just keeps the flag alive. For context on why robots rules behave the way they do here, the complete robots.txt reference covers precedence and wildcard gotchas that trip people up.

Common mistakes

People fix the wrong end. They unblock the AMP URL, or add a noindex, or slap a canonical on the AMP page pointing at itself — none of which addresses a canonical target that a robots rule is hiding. A Disallow is not a "don't index" instruction; it is a "don't fetch" instruction, and fetching is exactly what the pairing needs. This is the same trap that catches people with a disallowed image: the block stops discovery, not indexing, so removing it is the move, not adding more directives on top.

FAQ

Is this the same as my AMP URL being blocked in robots.txt?

No. This check is about the canonical target — the non-AMP page the AMP file points at — being blocked. If the AMP URL itself were the blocked one, that is the separate AMP page URL is disallowed issue, and the fix is different.

Will Google just ignore the robots block and index the canonical anyway?

Sometimes it indexes the URL as a bare listing off external links, but it will not fetch the content or confirm the AMP relationship. For pairing purposes, a blocked canonical is a dead end regardless of whether the URL ever appears in results.

Does AMP even matter enough to bother fixing this in 2026?

AMP lost its ranking edge when Google dropped it as a Top Stories requirement in 2021, and most sites have moved on. If you are keeping AMP, fix the pairing. If you are not, retiring it removes this whole class of check and lets you focus on Core Web Vitals on your standard pages instead.

What if the canonical is blocked only for a specific bot?

Robots.txt is evaluated per user-agent. If Googlebot has its own group that disallows the canonical path, that is what breaks the pairing even if User-agent: * looks fine. Test the exact agent that fetches AMP, not just the wildcard group.