AMP Page URL Is Disallowed in robots.txt: How to Fix It

Your standard page advertises an AMP companion with an amphtml link, but the AMP URL that link points to is blocked in robots.txt. You are pointing crawlers at a fast mobile version and slamming the door on it in the same breath. The AMP page can never be fetched, so it never validates, never caches, and never serves.

This is the inverse of the canonical-disallowed check. There, the AMP page's canonical target was blocked. Here, the AMP URL itself is the blocked address, which kills AMP serving at the source.

What this check actually flags

A page declares its AMP variant like this:

<link rel="amphtml" href="https://example.com/guide/amp/">

and the robots file forbids exactly that path:

User-agent: *
Disallow: /*/amp/

That wildcard rule — a common one, because people try to keep AMP URLs out of "duplicate" reports — catches every /amp/ URL on the site. So the moment a crawler reads the amphtml link and goes to fetch it, robots.txt tells it to stop. In Search Console the AMP URL shows up as "Blocked by robots.txt." You are simultaneously announcing the AMP page and forbidding access to it.

Why blocking the AMP URL kills AMP entirely

AMP does not serve straight off your origin the way a normal page does. The chain is: a search engine fetches your AMP HTML, runs it through the validator, and stores a pre-validated copy in an AMP cache (Google's lives at cdn.ampproject.org). That cached copy is what mobile users actually get. Every link in that chain depends on the first step — fetching your AMP URL. Disallow it and nothing downstream can happen.

The takeaway: a robots block on the AMP URL is not a soft signal. It is a hard stop that voids AMP before validation even begins. And because robots.txt is evaluated per host and per protocol, a rule on https://www.example.com/robots.txt may not match the file on a bare-domain or subdomain variant — so an AMP URL can be blocked on one host and reachable on another, which is exactly how these slip through unnoticed until a crawl surfaces them.

How to detect it

1. View the source of a standard page and copy the href from its <link rel="amphtml"> tag. That AMP URL is what you are testing.
2. Run that AMP URL through a robots.txt tester against your live file. A "Blocked" result confirms the flag; note which rule matched, since wildcard /amp/ disallows are the usual culprit.
3. Fetch it directly: curl -s https://example.com/robots.txt and scan for any Disallow line whose pattern covers your AMP path.
4. Crawl with Screaming Frog storing AMP; the crawler reports AMP URLs blocked by robots.txt alongside the pages that reference them.
5. In the legacy Search Console AMP report (if present), affected URLs list "Blocked by robots.txt" as the error reason.

How to fix it

If you want AMP to work: allow the AMP URLs. Remove or narrow the Disallow rule so crawlers can reach the AMP path. You do not need to block AMP URLs to prevent duplicate-content problems — the rel="canonical" on each AMP page already tells Google which version is primary, and the amphtml/canonical pairing handles consolidation. Blocking them just breaks the feature. If you are unsure how a wildcard rule is matching, the complete robots.txt reference walks through precedence and pattern matching.

If you are done with AMP: retire it properly instead of leaving it blocked. Remove the amphtml links from your standard pages, 301 the AMP URLs to their non-AMP equivalents, and drop any AMP sitemap entries. A blocked-but-still-advertised AMP URL keeps generating this flag indefinitely.

Common mistakes

The big one is blocking AMP URLs on purpose to "avoid duplicate content," which misunderstands how AMP consolidation works — the canonical tag already solves duplication, and the block only disables serving. Another is unblocking the AMP path but forgetting that a broad Disallow: /*/amp/ can also catch legitimate non-AMP URLs that happen to contain amp, so test the exact patterns after editing. This is the same "block stops discovery, not indexing" confusion behind a disallowed image.

FAQ

How is this different from my AMP canonical pointing at a blocked URL?

Different URL is blocked. Here the AMP page itself is disallowed, so it can never be fetched or cached. If instead the AMP page's canonical target is blocked, that is AMP canonical points to a disallowed URL, a separate problem with a separate fix.

Won't allowing AMP URLs create duplicate content?

No. Each AMP page canonicalizes to its standard version, which is exactly the signal Google uses to consolidate the two. That is the intended setup — the canonical does the deduplication, not a robots block.

The AMP URL returns fine when I open it in a browser — why is it flagged?

Robots.txt controls crawler access, not your browser. The URL can load perfectly for you while Googlebot is forbidden from fetching it. Test with a robots.txt tester or check the file directly, not by opening the page yourself.

If a WAF returns a 403 on the AMP URL instead, is that the same issue?

No — a 403 is a server refusal, not a robots directive, and it is handled separately in AMP page URL returns 403 Forbidden. Both stop the fetch, but the diagnosis and fix differ.