AMP Canonical Points to 403 Forbidden: How to Fix It

This check fires when an AMP page's <link rel="canonical"> points at a URL that returns 403 Forbidden. An AMP document is supposed to be the accelerated twin of a real, canonical HTML page — and that canonical must answer with 200 OK. When it throws a 403, you have wired your AMP variant to a door that is locked. Google can't resolve the pair, consolidation of signals breaks, and the AMP page floats without a home.

How the AMP/canonical relationship is supposed to work

In a correct setup there are two documents:

• The non-AMP HTML page at, say, /article/ — this is canonical, returns 200, and self-canonicalizes (its own canonical points to itself).
• The AMP page at /article/amp/ — it does not self-canonicalize. It points rel="canonical" at the non-AMP /article/, and the non-AMP page points back at the AMP with <link rel="amphtml">.

That reciprocal pair is the whole contract. Break either side and Google can't tell which URL is the source of truth. A 403 on the canonical target breaks it hard: the destination isn't just wrong, it's actively refusing the crawler.

Why a canonical 403s

Common causes: the canonical URL sits behind auth or a paywall the crawler can't pass; a WAF or bot-mitigation rule (Cloudflare, ModSecurity) blocks Googlebot's user-agent or IP range; hotlink protection; a stale canonical pointing at a URL that was moved behind login; or a plugin generating the canonical from an outdated permalink.

Real failing example

<!-- On the AMP page /article/amp/ -->
<link rel="canonical" href="https://example.com/members/article/">

$ curl -I -A 'Googlebot' https://example.com/members/article/
HTTP/2 403
server: cloudflare
cf-mitigated: challenge
content-type: text/html; charset=UTF-8

The AMP page names /members/article/ as canonical, but that URL sits behind a member gate and returns 403 to the crawler. The AMP variant is orphaned.

The fix

<!-- Point the AMP canonical at the public, 200-OK non-AMP page -->
<link rel="canonical" href="https://example.com/article/">

$ curl -I -A 'Googlebot' https://example.com/article/
HTTP/2 200
content-type: text/html; charset=UTF-8
link: <https://example.com/article/amp/>; rel="amphtml"

The canonical now resolves 200 for the crawler and points back at the AMP via rel="amphtml". If the content genuinely lives behind auth, the real fix is to stop serving an AMP variant of gated content at all — AMP requires a publicly crawlable canonical.

Diagnosing the 403 by cause

How to detect it

1. curl -I the canonical. Run curl -I -A 'Mozilla/5.0' https://example.com/canonical-url/ and again with -A 'Googlebot'. If the bot UA gets 403 and a browser UA gets 200, you have a bot-blocking rule.
2. AMP Test. Google's AMP Test (search.google.com/test/amp) validates the AMP doc and flags when the linked canonical is unreachable.
3. URL Inspection in Search Console. Inspect the AMP URL; the AMP section reports canonical resolution problems.
4. Server log check. Grep your access logs for the canonical path and Googlebot — a run of 403s confirms the crawler is being turned away.

How to fix it

1. Read the exact canonical URL out of the AMP page's <link rel="canonical">.
2. curl -I it as both a browser and Googlebot; confirm the 403 and identify the cause from the table above.
3. If the target is the wrong URL, repoint the canonical at the correct public non-AMP page that returns 200.
4. If the target is correct but blocked, fix the block — allowlist verified Googlebot, exempt the path from the WAF rule, or remove the auth gate.
5. Confirm the non-AMP page returns rel="amphtml" pointing back at the AMP URL.
6. Re-test in the AMP Test and request re-indexing.

A word on AMP in 2026

Worth saying plainly: AMP matters far less than it did. Google removed the AMP requirement for the Top Stories carousel in 2021 — any fast, good-Core-Web-Vitals page is now eligible. Many publishers have retired their AMP variants entirely. If you're carrying AMP debt like this 403, the strategic question is whether to fix it or sunset AMP and serve a single fast canonical HTML page. Either way, while the AMP pages exist and are indexed, a broken canonical actively leaks equity, so don't leave it half-dead.

Frequently asked questions

Should the AMP page ever be its own canonical?

No. The AMP page canonicalizes to the non-AMP page; the non-AMP page self-canonicalizes. If the AMP page points its canonical at itself, you break the pairing. Background in the Canonical Tags: The Complete Reference.

Googlebot gets 403 but my browser loads it fine — why?

Classic bot-mitigation. A WAF or CDN rule is challenging or blocking the crawler's user-agent or IP. Verify Googlebot via reverse DNS and allowlist it, rather than trusting the UA string blindly.

Can I just remove the AMP page instead of fixing the canonical?

Often the cleaner call in 2026. Retire the AMP variant, drop the rel="amphtml" link, and let the fast HTML page stand alone. Just do it deliberately with proper handling — don't leave dangling AMP URLs.

Is a 403 canonical worse than a 404 canonical?

Both are broken, but a 403 is sneakier because the URL often exists and works for humans — the crawler is simply refused, so the problem hides from casual testing. Always test with the bot user-agent.

What's the difference between this and the disallowed-URL check?

A 403 is the server refusing the request; a robots.txt disallow tells the crawler not to request it at all. Different mechanisms, same orphaning effect. See AMP Canonical Points to Disallowed URL and the related AMP Canonical Points to a Canonicalized URL.