Could a double canonical AMP/desktop actually hinder your page visibility?

What is a chained canonical and how does it block AMP?

The canonical tag tells Google which URL to consider as the preferred version. In a typical AMP setup, the AMP page points to the desktop via canonical, and the desktop redirects back to the AMP through the amphtml tag.

The issue arises when the desktop version has its own canonical pointing elsewhere—typically to a parameterized URL or another variant. Google faces an open circuit: AMP says, 'my reference is A,' but A says, 'my reference is B.' The result is that the algorithm no longer knows which page to serve in mobile.

What is the real impact on SERP display?

When Google detects this inconsistency, it may simply ignore the AMP version. You then lose out on the benefits of the format: loading speed, lightning badge, Top Stories carousel in certain verticals.

Worse: Google might index a URL that you don't really control. If your desktop canonical points to a version with tracking parameters, it is that polluted URL that might appear in the index, not your clean page.

Does Google track the entire canonical chain or does it stop somewhere?

Müller does not provide an explicit limit in this statement. Field observation shows that Google usually follows a maximum of 2 to 3 hops before giving up. Beyond that, it treats the pages as distinct entities.

The real danger is not so much the length of the chain but the ambiguity of the signal. An AMP ↔ desktop configuration must be bidirectional and closed. Any third element in the loop breaks it.

• An AMP page can point to a desktop via canonical
• This desktop must redirect to the AMP via amphtml tag—and nowhere else via canonical
• Any canonical chain beyond this pair causes a loss of control over mobile display
• Google always prioritizes consistency of signals over the length of the chain

Does this rule still apply now that AMP has lost its weight?

AMP is no longer an official ranking factor since the widespread adoption of Core Web Vitals. However, the format is still used in certain verticals—news, fast e-commerce, product sheets. If you still maintain AMP versions, this rule fully applies.

Let's be honest: many sites removed AMP between 2021 and 2023. But if you retained the format for reasons of pure performance or Google News integration, a poorly configured canonical directly penalizes your mobile visibility.

Does Google systematically detect these chains or do we have to wait for a recrawl?

Müller's statement does not specify the detection frequency. In practice, we observe that Google recalibrates canonical relationships during each deep crawl, not necessarily during every Googlebot visit. [To be verified]: no official figure on the average delay before detecting an inconsistency.

This is where it gets tricky. You can correct a canonical and wait three weeks for Google to update its mapping. In the meantime, your AMP remains invisible or degraded in mobile SERPs.

Does an AMP → desktop configuration without reciprocal amphtml still function?

No. Google has always required a symmetrical relationship to validate an AMP/desktop pair. If the desktop does not redirect to the AMP via amphtml tag, Google treats the two pages as independent entities.

In practical terms, you lose all benefits: no AMP badge, no mobile prioritization, just two competing URLs that cannibalize each other. Some sites think a simple canonical is sufficient—this is false, and Müller implicitly confirms it here.

How to audit your AMP/desktop canonical chains?

Your first instinct: crawl your site with Screaming Frog or Oncrawl in mobile + desktop mode. Extract the canonical and amphtml tags, then cross-reference the data in a spreadsheet. Look for AMP pages whose desktop canonical has its own third-party canonical.

Your second check: manually test your pairs with the URL Inspection tool in Search Console. Google indicates which URL it considers canonical and whether the AMP relationship is recognized. If the status shows 'Alternative page with correct canonical tag' but without AMP mention, your chain is broken.

What corrections should you prioritize?

Remove any extraneous canonical on the desktop version. If your desktop page absolutely needs to point to a variant (e.g., HTTPS vs. HTTP), make a 301 server-side redirect instead of a canonical. The redirect fixes the issue upstream before Google crawls.

Then, ensure that each desktop page with an AMP version contains the <link rel="amphtml" href="..."> tag. This is the essential reciprocal signal. Without it, Google ignores the relationship even if the AMP canonical is correct.

Should you still maintain AMP versions or migrate everything to pure responsive?

It depends on your vertical. If you are in news or fast editorial content, AMP still retains an advantage in Top Stories carousels and Google News on mobile. For e-commerce or corporate sites, it may no longer be worth the effort.

Maintaining a double AMP/desktop template is resource-intensive. If your Core Web Vitals are excellent in pure responsive, abandon AMP. Otherwise, keep it clean: a strict bidirectional canonical, no third-party chains.

• Crawl all your AMP pages and extract their canonical tags
• Ensure that each targeted desktop has a reciprocal amphtml tag
• Remove any third-party canonical on desktop pages linked to AMP
• Test URL inspection in Search Console to validate AMP recognition
• Automate monitoring with a monthly script detecting broken chains