Is the rel=canonical really mandatory on all AMP pages, even standalone ones?

Why does Google require a canonical on all AMP pages?

The rel=canonical directive plays a structural role in Google's AMP architecture. It allows the engine to clearly distinguish relationships between versions of the same resource. For paired AMP pages, the canonical indicates which version is the reference — typically the classic HTML page.

For standalone AMPs, the logic differs. There's no classic version, so there’s no external target to designate. The self-canonical (the page points to itself) avoids any ambiguity and explicitly signals to Google that this AMP page is the only version available. It’s a form of technical identity declaration.

Is the AMP canonical linked to hreflang configurations?

No. Mueller clarifies that the AMP canonical rule applies regardless of hreflang and multilingual configurations. Some SEOs thought hreflang could replace or circumvent the canonical on translated AMP pages — that's false.

Hreflang manages inter-language relationships, while canonical manages the inter-version relationships of the same language. The two mechanisms are orthogonal and must coexist on multilingual AMP pages. An AMP site in English, French, and German must implement both hreflang AND canonical on each page, irrespective of its configuration.

What happens if the canonical is missing or misconfigured?

Google may refuse to index the AMP page or index it as duplicate content if a classic version exists. The AMP cache may also fail to serve the page correctly, directly impacting the performance of the AMP carousel in mobile results.

Common symptoms include: AMP pages excluded in Search Console, AMP validation error messages, or worse — indexing of the AMP version when you intended to prioritize the classic version. A missing or erroneous canonical creates a signal ambiguity that Google does not always resolve in your favor.

• Mandatory canonical on all AMP pages, whether paired or standalone
• Self-canonical for standalone AMPs (the page points to itself)
• Independent of hreflang — both mechanisms must coexist on multilingual sites
• Indexing risks if canonical is missing or misconfigured
• Direct impact on AMP cache and visibility in mobile results

Is this statement consistent with observed practices in the field?

Yes, and it's one of the rare positions of Google that aligns perfectly with real-world observations. Sites that omit the canonical on standalone AMP pages frequently encounter crawl and indexing issues. Search Console also highlights explicit errors in the AMP validation tool when the canonical is missing.

Where it sometimes gets tricky: misconfigured CMS that automatically generate AMP pages without a self-canonical. WordPress with certain AMP plugins, for example, has historically had this flaw. Developers thought the canonical was only required for paired configurations — a classic mistake in practice.

What nuances should be added to this rule?

Mueller does not specify Google's behavior in the face of a contradictory canonical — for example, an AMP standalone page that points to a classic URL that no longer exists. In this case, does Google follow the canonical or index the AMP anyway? [To be verified] in real conditions, as the official documentation remains vague on this scenario.

Another gray area: dynamic AMP pages with URL parameters. Should we canonicalize to the version without parameters or accept a parameterized self-canonical? Google does not provide a clear directive, and feedback from the field is contradictory depending on sectors (e-commerce vs. media). The general rule applies, but its practical implementation remains open to interpretation in these edge cases.

In what cases could this rule cause issues?

On ephemeral content sites (news, events), migrating a classic page to a standalone AMP requires changing the canonical. If you forget this step, Google may continue to look for the old classic version and mark the AMP as orphaned. Symptoms experienced: pages disappearing from the index for 48-72 hours while Googlebot recrawls and understands the new architecture.

Another concrete case: A/B testing on AMP. If you test two AMP versions of the same page, which one should you canonicalize? Google recommends canonicalizing to the control version, but if both versions are served randomly, you risk an unstable canonical that disrupts indexing. Mueller's statement does not cover this scenario, which is frequent in CRO optimization.

What should you do concretely on an AMP site?

First step: audit all your AMP pages to check for the presence of the canonical. A simple crawl with Screaming Frog or Sitebulb will suffice — filter the AMP URLs and ensure that 100% of them have a declared canonical in the <head>. For standalone AMPs, ensure the canonical points to the page's own URL, not to a non-existent classic version.

Next, check the consistency of canonicals on translated versions. A French AMP page should canonicalize to itself (if standalone) or to the French classic version (if paired) — never to an English or German version. Hreflang manages inter-language relationships, canonical manages version identity. Both must be aligned but independent.

What errors should be absolutely avoided?

Classic mistake #1: using a relative canonical instead of an absolute one. Some CMS generate canonicals in /page-amp instead of https://example.com/page-amp. Google may interpret this correctly, but it’s a source of bugs in dev/staging environments. Always use absolute URLs with HTTPS protocol.

Error #2: forgetting the canonical during a migration from paired to standalone. You remove the classic version, transforming the AMP into a unique page, but the canonical continues to point to the old classic URL which now returns a 404. Google faces a contradictory signal and may deindex the page. Update the canonical BEFORE deleting the classic version.

How can I check if my site is compliant?

Use the Google AMP testing tool (or the official AMP validator) on a sample of pages. The tool explicitly highlights errors with missing or misconfigured canonicals. Complement this with a complete crawl to detect pages that may have escaped manual validation.

In Search Console, check the Coverage > AMP report. AMP pages without the correct canonical often appear in errors like “AMP page not indexed” or “Canonical issue detected.” If you see these messages, correct the canonical and request reindexing via the URL inspection tool.

• Crawl all AMP pages and check for a canonical in the <head>
• For standalone AMPs, ensure the canonical points to the page's own URL
• Use absolute URLs (https://...) in your canonicals, never relative paths
• Check the canonical/hreflang consistency on multilingual sites
• Test a sample with the official AMP validator to detect errors
• Monitor the AMP report in Search Console to identify problematic pages