AMP Canonical Points to a Canonicalized URL: How to Fix It
- February 6, 2018
- AMP, Canonical Issues

This check fires when an AMP page's rel="canonical" points at a URL that is itself canonicalized to a third URL. You've built a chain: AMP → page B → page C. Google is supposed to consolidate an AMP page with one clean canonical target, and a chain forces it to guess which link in the chain is the real destination. That guesswork is exactly what you don't want deciding which URL ranks.
What "points to a canonicalized URL" actually means
The AMP contract is a simple two-node pair: the AMP page canonicalizes to its non-AMP twin, and the non-AMP twin self-canonicalizes (its canonical points to itself, returning 200). The bug here is that the twin does not self-canonicalize — it hands off to yet another URL. So instead of a clean pair you get a canonical chain, and chains behave unpredictably: Google may honor the end of the chain, may pick the middle, or may distrust the whole signal and index something you didn't intend.
Real failing example
<!-- AMP page: /blog/amp-guide/amp/ -->
<link rel="canonical" href="https://example.com/blog/amp-guide/">
<!-- Non-AMP page /blog/amp-guide/ does NOT self-canonicalize: -->
<!-- it points somewhere else -->
<link rel="canonical" href="https://example.com/guides/amp/">
<!-- /guides/amp/ finally self-canonicalizes -->
<link rel="canonical" href="https://example.com/guides/amp/">The chain is AMP → /blog/amp-guide/ → /guides/amp/. The AMP page's declared canonical is a middle node, not the true destination. Google has to follow the hop to figure out where consolidation should land, and the rel="amphtml" back-reference from /guides/amp/ may be missing entirely.
The fix
<!-- Point the AMP canonical DIRECTLY at the final, self-canonical URL -->
<!-- On /blog/amp-guide/amp/ -->
<link rel="canonical" href="https://example.com/guides/amp/">
<!-- /guides/amp/ self-canonicalizes and points back at the AMP -->
<link rel="canonical" href="https://example.com/guides/amp/">
<link rel="amphtml" href="https://example.com/blog/amp-guide/amp/">Collapse the chain: the AMP page canonicalizes straight to the end node, and that end node self-canonicalizes and carries the rel="amphtml" pointer back. One hop, no ambiguity. If the middle URL should redirect users too, give it a 301 to the final URL — but the AMP canonical must name the destination directly, never the intermediate.
Chain shapes and what to do
| Shape | What Google sees | Correct action |
|---|---|---|
| AMP → B (B self-canonical) | Clean pair | Nothing — this is correct |
| AMP → B → C (canonical chain) | Ambiguous target | Repoint AMP canonical to C |
| AMP → B, B redirects (301) to C | Canonical to a redirecting URL | Repoint AMP canonical to C directly |
| AMP → B → AMP (loop) | Canonical loop — signal discarded | Break the loop; see canonical-loop check |
| AMP → A, A → B, B → A | Multi-hop loop | Rebuild so one node self-canonicalizes |
How to detect it
- Follow the chain by hand. Read the AMP page's canonical, open that URL, read its canonical. If they differ, you have a chain. Keep going until a URL points at itself.
curl -Iplus a canonical grep. Fetch each URL and inspect the<link rel="canonical">in the body:curl -s -A 'Mozilla/5.0' URL | grep -i 'rel="canonical"'. Chain them until self-reference.- AMP Test. Google's AMP Test flags canonical-target problems on the AMP document.
- Crawler. A site crawler (Screaming Frog and similar) reports canonical chains and loops across the whole site so you can catch every AMP variant at once.
How to fix it
- Trace the full chain from the AMP page to the final self-canonical URL.
- Repoint the AMP page's
rel="canonical"directly at that final URL. - Confirm the final URL self-canonicalizes (its canonical equals its own address) and returns 200.
- Add or fix
rel="amphtml"on the final URL so it points back at the AMP page. - If intermediate URLs still serve content, 301-redirect them to the final URL to keep humans and equity flowing one direction.
- Re-crawl to confirm zero remaining chains, then re-test in the AMP Test.
A word on AMP in 2026
Be honest with yourself about whether AMP still earns its keep. Google dropped the AMP requirement for Top Stories back in 2021 — eligibility now rides on speed and Core Web Vitals, not the AMP framework. Plenty of sites have retired AMP entirely. If you're untangling canonical chains across dozens of AMP variants, that's a strong signal to weigh sunsetting AMP and consolidating on a single fast HTML page per URL. While the AMP pages remain indexed, though, a chained canonical scatters your consolidation signals, so fix it or retire it — don't let it rot.
Frequently asked questions
Is a canonical chain the same as a canonical loop?
No. A chain ends at a distinct final URL (A → B → C); a loop circles back (A → B → A) and Google typically discards the signal outright. Chains cause guesswork; loops cause outright failure. For loops see Canonical Loop.
Why not just let Google follow the chain?
Google can follow one hop, but each hop dilutes confidence and every extra step is a chance for signals to leak to the wrong URL. Direct canonicals consolidate cleanly; chained ones gamble. The mechanics are laid out in the Canonical Tags: The Complete Reference.
Does the intermediate URL need a redirect?
If real users can still land on it, yes — 301 it to the final URL so people and link equity travel the same path the canonical declares. If nothing links to it, cleaning the canonical is enough.
What if the chain crosses http/https or www/non-www?
Same principle, and it's a common culprit — a canonical to the http or non-www version that then canonicalizes to the secure www version. Normalize everything to one host and protocol so the AMP canonical hits the final form directly.
How does this relate to the 403 canonical check?
Both break the AMP pairing, just differently: a 403 canonical is unreachable, a chained canonical is reachable but ambiguous. See the sibling check AMP Canonical Points to 403 Forbidden and AMP Canonical Points to Disallowed URL.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







