AMP Page URL Returns 403 Forbidden: How to Fix It

The AMP version of one of your pages responds with HTTP 403 Forbidden. The server got the request, understood it, and refused to hand over the content. Because the Google AMP Cache and the validator both have to fetch that URL before AMP can serve, a 403 means the AMP copy never loads for anyone — while your standard HTML page may be perfectly healthy.

This is not a robots.txt block and not a markup problem. The URL is reachable at the network level; something on the server actively rejects the request. That distinction shapes the entire fix.

What this check actually flags

Your standard page declares an AMP variant with <link rel="amphtml">. When a crawler or the AMP Cache follows that link, the AMP URL returns:

$ curl -sI https://example.com/article/amp/
HTTP/1.1 403 Forbidden
server: cloudflare

A 403 means "I know who you are and I am refusing." It is a deliberate rejection, not a missing page (that would be 404) or an outage (5xx). The check is flagging the separate AMP URL, not your canonical page — the HTML version can return a clean 200 while its AMP twin is walled off.

Why a 403 AMP URL means AMP never serves

When someone taps an AMP result, Google does not route them to your origin — it serves a copy stored in the AMP Cache. To build that copy, the cache must first fetch your AMP URL. A 403 gives it nothing to store and nothing to serve, and the validator hits the identical wall. You keep publishing the amphtml link that promises an AMP version, but that version can never render. All cost, no payoff.

How to detect it

1. Fetch the AMP URL headers with a normal browser agent: curl -sI -A 'Mozilla/5.0' https://example.com/article/amp/. A 403 here means everyone is blocked.
2. Re-fetch it as a crawler: curl -sI -A 'Googlebot' https://example.com/article/amp/. A 200 for browsers but 403 for Googlebot points straight at a WAF or bot rule that keys off user-agent.
3. Test with and without a referer header to expose hotlink protection, and from a different IP or network to expose geo/IP blocking.
4. Crawl with Screaming Frog storing AMP; AMP URLs returning 403 appear under the response-code report against the pages that reference them.
5. Check server, WAF, and CDN logs for the blocked request — the log line usually names the exact rule that fired, which is the fastest route to the fix. Verify Googlebot by reverse-DNS so you allowlist the real crawler, not a spoof; the rundown of bot user-agents covers how to tell them apart.

How to fix it

If you want AMP to work: find the rule returning the 403 and exempt the legitimate fetchers. For a WAF or bot manager, allowlist verified Googlebot (and the AMP Cache fetcher) rather than loosening the rule for everyone. For hotlink protection, exempt requests from crawlers. For an auth or geo gate, make the AMP URLs publicly reachable to search engines. After each change, re-fetch as Googlebot and confirm a 200.

If you are done with AMP: stop advertising it. Remove the amphtml links from your standard pages and 301 the AMP URLs to their non-AMP equivalents. Since AMP no longer carries any ranking benefit, retiring it is often simpler than chasing a WAF exception forever. For the full picture on what each status code signals to crawlers, see the HTTP status codes reference.

Common mistakes

Testing only in a browser and declaring the page fine — the 403 frequently targets crawler user-agents specifically, so a browser sees 200 while Googlebot sees 403. Disabling the entire WAF to "fix" it, which trades a crawl bug for a security hole; allowlist the verified crawler instead. And confusing a 403 with a robots block — robots.txt never returns a status code on the page itself, so if a tester reports the URL as fetchable but the server hands back 403, this is the check that applies, not a disallow.

FAQ

My HTML page is 200 and only the AMP URL is 403 — is that normal?

It is common when a WAF rule matches a URL pattern (like /amp/) or a user-agent that only the AMP fetch triggers. The standard page and the AMP page are separate URLs, and a rule can catch one without touching the other.

How do I know if it is a WAF versus a login gate?

Compare responses across user-agents and cookies. A 403 that flips to 200 when you send a browser agent points at bot filtering; a 403 (or 401) that only clears with a session cookie points at an auth gate. The header and log detail usually name the rule.

Is a 403 on the AMP URL the same as a 403 on the canonical?

No. This check is the AMP URL refusing to serve. If your AMP page's canonical target returns 403 instead, that is the separate AMP canonical points to 403 Forbidden issue. A 403 also shows up in sitemaps, covered in 403 Forbidden URL in XML sitemaps.

Should I bother fixing this or just drop AMP?

If nothing depends on AMP, dropping it removes the 403 flag permanently and one whole maintenance surface with it. AMP stopped being a Top Stories requirement in 2021, so unless a specific channel still needs it, retiring is the pragmatic call.