What does Google say about SEO? /
Quick SEO Quiz

Test your SEO knowledge in 3 questions

Less than 30 seconds. Find out how much you really know about Google search.

🕒 ~30s 🎯 3 questions 📚 SEO Google

Official statement

The Chrome User Experience Report takes into account what users actually see. If it's a valid AMP page served from the cache, Google uses this data. If it’s not a valid AMP and cannot be served from the cache, this data is not used.
257:21
🎥 Source video

Extracted from a Google Search Central video

⏱ 996h50 💬 EN 📅 12/03/2021 ✂ 43 statements
Watch on YouTube (257:21) →
Other statements from this video 42
  1. 42:49 Peut-on vraiment utiliser hreflang entre plusieurs domaines distincts ?
  2. 48:45 Peut-on vraiment utiliser hreflang entre plusieurs domaines distincts ?
  3. 58:47 Faut-il vraiment éviter de dupliquer son contenu sur deux sites distincts ?
  4. 58:47 Faut-il vraiment éviter de créer plusieurs sites pour le même contenu ?
  5. 91:16 Faut-il vraiment indexer les pages de recherche interne de votre site ?
  6. 91:16 Faut-il bloquer les pages de recherche interne pour éviter l'indexation d'un espace infini ?
  7. 125:44 Les Core Web Vitals influencent-ils vraiment le budget de crawl de Google ?
  8. 125:44 Réduire la taille de page améliore-t-il vraiment le budget crawl ?
  9. 152:31 Le rapport de liens internes dans Search Console reflète-t-il vraiment l'état de votre maillage ?
  10. 152:31 Pourquoi le rapport de liens internes de Search Console ne montre-t-il qu'un échantillon ?
  11. 172:13 Faut-il vraiment s'inquiéter des chaînes de redirections pour le crawl Google ?
  12. 172:13 Combien de redirections Google suit-il réellement avant de fractionner le crawl ?
  13. 201:37 Comment Google segmente-t-il réellement vos Core Web Vitals par groupes de pages ?
  14. 201:37 Comment Google segmente-t-il réellement vos Core Web Vitals par groupes de pages ?
  15. 248:11 AMP ou canonique : qui récolte vraiment les signaux SEO ?
  16. 272:10 Faut-il vraiment rediriger vos URLs AMP lors d'un changement ?
  17. 272:10 Faut-il vraiment rediriger vos anciennes URLs AMP vers les nouvelles ?
  18. 294:42 AMP est-il vraiment neutre pour le classement Google ou cache-t-il un levier de visibilité invisible ?
  19. 296:42 AMP est-il vraiment un facteur de classement Google ou juste un ticket d'entrée pour certaines features ?
  20. 342:21 Pourquoi le contenu copié surclasse-t-il parfois l'original malgré le DMCA ?
  21. 342:21 Le DMCA est-il vraiment efficace pour protéger votre contenu dupliqué sur Google ?
  22. 359:44 Pourquoi le contenu copié surclasse-t-il votre contenu original dans Google ?
  23. 409:35 Pourquoi vos featured snippets disparaissent-ils sans raison technique ?
  24. 409:35 Les featured snippets et résultats enrichis fluctuent-ils vraiment par hasard ?
  25. 455:08 Le contenu masqué en responsive mobile est-il vraiment indexé par Google ?
  26. 455:08 Le contenu caché en CSS responsive est-il vraiment indexé par Google ?
  27. 563:51 Les structured data peuvent-elles vraiment forcer l'affichage d'un knowledge panel ?
  28. 563:51 Existe-t-il un balisage structuré qui garantit l'apparition d'un Knowledge Panel ?
  29. 583:50 Pourquoi la plupart des sites n'obtiennent-ils jamais de sitelinks dans Google ?
  30. 583:50 Peut-on vraiment forcer l'affichage des sitelinks dans Google ?
  31. 649:39 Les redirections 301 transfèrent-elles vraiment 100 % du jus SEO sans perte ?
  32. 649:39 Les redirections 301 transfèrent-elles vraiment 100% du PageRank et des signaux SEO ?
  33. 722:53 Faut-il vraiment supprimer ou rediriger les contenus expirés plutôt que de les garder indexables ?
  34. 722:53 Faut-il vraiment supprimer les pages expirées ou peut-on les laisser avec un label 'expiré' ?
  35. 859:32 Les mots-clés dans l'URL : facteur de ranking ou simple béquille temporaire ?
  36. 859:32 Les mots dans l'URL influencent-ils vraiment le classement Google ?
  37. 908:40 Faut-il vraiment ajouter des structured data sur les vidéos YouTube embarquées ?
  38. 909:01 Faut-il vraiment ajouter des données structurées vidéo quand on embed déjà YouTube ?
  39. 932:46 Les Core Web Vitals impactent-ils vraiment le SEO desktop ?
  40. 932:46 Pourquoi Google ignore-t-il les Core Web Vitals desktop dans son algorithme de classement ?
  41. 952:49 L'API et l'interface Search Console affichent-elles vraiment les mêmes données ?
  42. 963:49 Peut-on utiliser des templates différents par version linguistique sans pénaliser son SEO international ?
📅
Official statement from (5 years ago)
TL;DR

Google confirms that the Chrome UX Report (CrUX) uses data from AMP pages served from the Google AMP cache, provided they are valid. If your AMP page has errors and cannot be cached, these metrics do not appear in CrUX. Specifically, an invalid AMP deprives you of actionable Core Web Vitals data for ranking, which can impact your mobile visibility.

What you need to understand

Why does Google collect data from the AMP cache? <\/h3>

The Chrome UX Report <\/strong> measures real user experience (RUM) on Chrome. When a user accesses your content via an AMP page served from cdn.ampproject.org <\/strong>, it is this cached version that is measured — not your original page.<\/p>

This distinction has a direct impact on your Core Web Vitals <\/strong>. If your AMP is valid and cached, you benefit from the optimized performance of Google's cache. If it's invalid, Google cannot serve it from the cache, the user sees your canonical version, and the CrUX metrics reflect this version (often slower).

What constitutes a 'valid' AMP page according to Google? <\/h3>

A valid AMP page meets all AMP technical specifications <\/strong>: allowed tags, JavaScript disallowed except for official AMP components, inline CSS limited to 75 KB, etc. Google validates each crawled AMP page before caching it.<\/p>

As soon as a validation error appears — an unauthorized tag, an external script, a syntax error — the page cannot be served from the cache. The user lands on your canonical version, and this is the version CrUX measures <\/strong>.

How does this impact my Core Web Vitals data? <\/h3>

If your AMP is valid and cached, your CrUX metrics reflect the exceptional performance of Google's cache <\/strong>: ultra-fast LCP, minimal CLS, negligible FID. These scores artificially inflate your Core Web Vitals for AMP URLs.

But if your AMP is invalid, CrUX measures your canonical page — likely heavier and slower. You lose the AMP cache performance benefit, and your Core Web Vitals deteriorate <\/strong>. Worse: you may not even know that your AMP is broken.

  • CrUX uses data from the version actually served <\/strong>: cached AMP if valid, canonical otherwise.<\/li>
  • An invalid AMP robs you of the performance boost <\/strong> of Google's cache in CrUX.
  • The Core Web Vitals measured can differ drastically <\/strong> between valid AMP and broken AMP.
  • Google does not always alert you <\/strong> if your AMP becomes invalid after publication.
  • Regularly check AMP validity <\/strong> with the official tool or Search Console.

SEO Expert opinion

Does this statement align with field observations? <\/h3>

Yes, and it is consistent with practitioners’ reports. Many have noticed massive discrepancies in Core Web Vitals <\/strong> between their AMP and canonical URLs. When the AMP is valid and cached, the CrUX metrics are green; as soon as a validation error appears, the scores plunge.

The problem? Google does not always immediately notify that an AMP has become invalid. You could serve a slow canonical version for weeks, thinking your AMP is working, and see your Core Web Vitals decline without understanding why <\/strong>. [To verify] <\/strong>: no public data specifies the CrUX update delay after AMP invalidation.

What nuances should be added to this statement? <\/h3>

Mueller simplifies slightly. In reality, CrUX aggregates data on 28 rolling days <\/strong>. If your AMP becomes invalid mid-month, your CrUX metrics will continue to mix cached AMP data (old) and canonical data (recent) for several weeks.

Another nuance: not all users go through the AMP cache. Those who access your canonical URL directly (via desktop search, link sharing, etc.) generate CrUX data based on that version, even if your AMP is valid <\/strong>. CrUX aggregates both, but Google does not precisely document the ratio.

In what cases does this rule not apply? <\/h3>

If you do not have an AMP version, this statement is obviously irrelevant. But let’s be honest: many sites have abandoned AMP since Google removed the AMP badge from mobile SERPs and broadened Top Stories eligibility to non-AMP pages.

If your site has removed its AMPs without proper 301 redirection <\/strong>, you may still have indexed AMP URLs generating 404s or errors. These broken pages do not appear in CrUX, but they clutter your index and create confusion. [To verify] <\/strong>: the exact impact of orphaned AMPs on crawl budget remains unclear.

Warning: <\/strong> If you maintain AMPs, audit them monthly. A CMS update, a third-party plugin, or a template change can break validation without you noticing. And this is where it gets tricky: your Core Web Vitals sink, your mobile ranking suffers, and you look for errors elsewhere.<\/div>

Practical impact and recommendations

What should you concretely check on your AMP pages? <\/h3>

Start by auditing the validity of each AMP page <\/strong> with the official AMP Validator tool or via Search Console (page experience report). A single error is enough to block caching. Inspect especially dynamic templates: a third-party component added in production can break all your AMPs at once.

Next, ensure your AMP URLs appear in CrUX. Check the Core Web Vitals report on Search Console and compare AMP vs canonical metrics <\/strong>. If AMPs do not appear or show identical scores to the canonical, they are likely not being served from the cache.

What configuration errors most often break AMPs? <\/h3>

Classic culprits include: third-party JavaScript scripts <\/strong> mistakenly embedded (non-AMP analytics, custom ads), <style> <\/code> tags out of norms, outdated non-updated AMP components, inline CSS exceeding 75 KB, non-AMP iframes, or disallowed HTML5 tags (e.g., <video> <\/code> without amp-video <\/code> component).

Another frequent pitfall: badly configured internal redirects <\/strong>. If your AMP redirects to the canonical (configuration error), Google cannot serve it from the cache, and CrUX measures the canonical instead. Result: you lose performance benefits without even realizing it.

How to continuously monitor AMP validity? <\/h3>

Set up Search Console alerts <\/strong> on the AMP report to be notified of validation errors. Integrate the AMP Validator test into your CI/CD pipeline: each deployment should automatically validate AMP templates before going live.

Also monitor your CrUX metrics via BigQuery (free CrUX export). If you notice a sudden drop in performance on your AMP URLs <\/strong>, it's often a sign of recent invalidation. And this is where it gets complex: diagnosing why an AMP has become invalid requires sharp technical expertise.

  • Audit AMP validity with the official tool or Search Console monthly.<\/li>
  • Compare AMP vs canonical Core Web Vitals in Search Console.<\/li>
  • Remove all non-AMP third-party JavaScript scripts from your templates.<\/li>
  • Ensure your inline CSS stays under 75 KB after every update.<\/li>
  • Set up Search Console alerts on the AMP report.<\/li>
  • Test each deployment with AMP Validator in pre-production.<\/li>
Maintaining valid and high-performing AMP pages requires a constant technical vigilance <\/strong>. Between strict AMP specifications, component updates, CSS constraints, and configuration pitfalls, it’s easy to break validation without noticing — and to see your Core Web Vitals plummet. If this complexity exceeds your internal resources, working with a specialized SEO agency can help you avoid avoidable ranking losses and sustainably optimize your CrUX performance.<\/div>

❓ Frequently Asked Questions

Le CrUX mesure-t-il toujours les pages AMP depuis le cache Google ?
Oui, mais seulement si la page AMP est valide selon les spécifications AMP. Si elle contient des erreurs de validation, elle ne peut être servie depuis le cache, et CrUX mesure alors la version canonique.
Comment savoir si mes pages AMP sont bien servies depuis le cache ?
Vérifiez le rapport AMP de Search Console et inspectez l'URL mise en cache via ampproject.org/c/. Si elle s'affiche correctement, elle est en cache. Comparez aussi vos Core Web Vitals AMP vs canoniques : des scores identiques suggèrent que l'AMP n'est pas mise en cache.
Une AMP invalide impacte-t-elle mon ranking Google ?
Indirectement oui. Si votre AMP est invalide, elle ne bénéficie pas du cache Google, vos Core Web Vitals se dégradent, et cela peut affecter votre ranking mobile puisque les Core Web Vitals sont un facteur de classement depuis la Page Experience Update.
Dois-je encore utiliser AMP en SEO ?
Depuis que Google a retiré le badge AMP des SERP et ouvert Top Stories aux non-AMP, l'intérêt s'est réduit. Beaucoup de sites ont abandonné AMP. Cela dit, si vous servez déjà des AMP valides, elles peuvent booster vos Core Web Vitals mobile.
Combien de temps faut-il pour que CrUX reflète une AMP devenue invalide ?
CrUX agrège les données sur 28 jours glissants. Si votre AMP devient invalide, les anciennes métriques cache AMP continueront d'influencer CrUX pendant plusieurs semaines avant que les nouvelles données canoniques dominent. Le délai exact dépend du volume de trafic.

🎥 From the same video 42

Other SEO insights extracted from this same Google Search Central video · duration 996h50 · published on 12/03/2021

🎥 Watch the full video on YouTube →

💬 Comments (0)

Be the first to comment.

2000 characters remaining
🔔

Get real-time analysis of the latest Google SEO declarations

Be the first to know every time a new official Google statement drops — with full expert analysis.

No spam. Unsubscribe in one click.