Official statement
Other statements from this video 7 ▾
- 4:19 Pourquoi Google indexe-t-il vos images avec un système totalement séparé du reste de votre contenu ?
- 5:35 Pourquoi l'indexation vidéo est-elle si complexe pour Google (et que faire pour en profiter) ?
- 6:26 Google indexe-t-il vraiment les AMP canoniques comme du HTML classique ?
- 7:06 AMP améliore-t-il vraiment le positionnement dans Google ?
- 8:29 Les Web Stories sont-elles vraiment indexées comme des pages classiques par Google ?
- 13:43 Les Web Stories exigent-elles vraiment des pratiques SEO spécifiques ou juste du standard ?
- 21:58 Pourquoi Google modifie-t-il les résultats même pendant les périodes de gel des mises à jour ?
Google does not index AMP pages that are not defined as canonical. Only the main HTML version enters the index, with AMP serving solely as an alternative format displayed to mobile users in the results. Essentially, if you use AMP as a secondary version, your indexing strategy and canonical tags must point to the standard HTML — otherwise, you risk losing important SEO signals.
What you need to understand
What does "non-canonical AMP" really mean?
A non-canonical AMP page is an AMP version that points via its canonical tag to the main HTML page. It's the classic setup: you have example.com/article (HTML) and example.com/article/amp (AMP), and the latter declares the former as the reference version.
In this scenario, Google treats AMP as an alternative format, much like a printable or device-specific version. Google's index only stores the standard HTML page. AMP is kept as a presentation variant, used to serve mobile users in the SERPs when load speed is critical.
How does Google decide which version to index?
The logic strictly follows the canonical tag. If your AMP points to HTML via rel="canonical", Google considers the HTML to be the main version and only indexes that. The reverse can also exist: an AMP page can be self-canonical (pointing to itself), in which case that version enters the index.
This statement from Gary Illyes clarifies a commonly misunderstood point: having an AMP version does not automatically create two distinct entries in Google's index. The engine consolidates signals (backlinks, anchors, engagement) on the canonical version only.
What are the implications for crawling and crawl budget?
Technically, Googlebot crawls both versions — the HTML and the AMP — to validate consistency and detect the alternative format. But only the canonical version benefits from full indexing and internal PageRank calculations.
This means that if you spend time finely optimizing your non-canonical AMP (schema tags, advanced internal linking), those efforts do not directly impact your ranking. They may influence user experience once the visitor lands on the AMP from mobile SERPs, but the SEO signals are directed back to the HTML version.
- Canonical HTML version: only indexed, receives all SEO signals (links, authority, content).
- Alternative AMP version: crawled but not indexed separately, serves only for fast deployment on mobile.
- Signal consolidation: all backlinks, anchors, and engagement metrics are attributed to the canonical HTML page.
- Critical canonical tag: an error in its configuration can reverse the indexing scheme or create duplication conflicts.
SEO Expert opinion
Is this statement consistent with real-world observations?
Overall, yes. Tests conducted on sites using AMP as an alternative format show that backlinks pointing to the AMP appear in link analysis tools as associated with the canonical HTML version. Google indeed consolidates the signals.
However, one point deserves attention: some professionals have observed cases where Google displays the AMP URL in the SERPs even when it is not canonical, creating a perceived confusion. The visible URL may be the AMP (with the lightning logo), but the indexing remains strictly on the HTML. It's a subtle distinction between indexing and presentation.
What nuances should we consider regarding this rule?
Gary Illyes' statement applies to the AMP-as-alternative schema. If your strategy is to make AMP the canonical version (self-canonical), then it is indeed the AMP that gets indexed. This choice remains rare in practice, except for media that has fully committed to AMP from the start. [To be confirmed]: Google has never published numerical data on the distribution between these two approaches.
Another nuance: even if AMP is not indexed separately, it must remain technically valid according to AMP specs. A broken or invalid AMP can lead to a refusal to display in mobile SERPs, depriving you of the UX benefit you initially sought.
When could this rule cause issues?
The issue arises when a site misconfigures its canonicals, creating a bidirectional conflict: HTML points to AMP and vice-versa. In this case, Google must decide, and the algorithm usually chooses the version it considers the most relevant — which may not be the one you want indexed.
Another critical case: if you've built a distinct content strategy between HTML and AMP (for instance, a summary on AMP and the full content on HTML), the non-indexation of AMP means that this summary will never be discovered directly through organic search. Let's be honest, this differentiated content strategy is rarely wise in SEO.
Practical impact and recommendations
What should I check on my current AMP site?
First step: audit your canonical tags on all AMP pages. They must explicitly point to the main HTML version if you're using AMP as an alternative format. Use a crawler like Screaming Frog or Oncrawl to extract these tags at scale.
Next, ensure that your HTML pages indeed contain the rel="amphtml" tag pointing to the AMP equivalent. This bidirectional link allows Google to detect and associate the two versions. A missing or broken link prevents the lightning logo from showing in mobile SERPs.
How can I ensure that SEO signals are being properly consolidated?
Test the consolidation of backlinks: if an external link points to your AMP URL, it should appear in your link profile (Search Console, Ahrefs, Majestic) as associated with the canonical HTML URL. If not, that's a signal that Google has not correctly interpreted your canonical configuration.
Also monitor your Core Web Vitals on both versions. Even if AMP is not indexed, Google can evaluate its performance to decide whether or not to display it to mobile users. A slow or buggy AMP loses its appeal — and that's where things often hit a snag.
What mistakes should I absolutely avoid?
Never create unique content on your non-canonical AMP pages. Anything that exists only on the AMP will not be indexed, thus invisible to Google. The content must be strictly equivalent between HTML and AMP (subject to AMP technical constraints).
Also avoid duplicating your semantic optimization or schema markup efforts solely on the AMP. These efforts should primarily focus on the canonical HTML version. The AMP can then inherit or replicate these, but it must never be the only optimized version.
- Ensure every AMP page contains a canonical tag pointing to the main HTML page.
- Confirm that each HTML page includes a rel="amphtml" link to its AMP equivalent.
- Test AMP validity using Google's official AMP Test tool or Search Console.
- Audit external backlinks to ensure they are consolidated on the canonical HTML version.
- Compare HTML and AMP content to guarantee strict equivalence (titles, paragraphs, essential images).
- Monitor Core Web Vitals on both versions to avoid any performance degradation.
❓ Frequently Asked Questions
Si mon AMP non-canonique reçoit un backlink, ce lien profite-t-il quand même à mon SEO ?
Dois-je bloquer le crawl des pages AMP non-canoniques dans mon robots.txt ?
Peut-on avoir une page AMP indexée et une page HTML indexée simultanément pour le même contenu ?
Les Core Web Vitals de ma page AMP influencent-elles mon ranking si elle n'est pas indexée ?
Faut-il encore investir dans AMP en sachant qu'elle n'est pas indexée séparément ?
🎥 From the same video 7
Other SEO insights extracted from this same Google Search Central video · duration 28 min · published on 16/11/2020
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.