Google teste-t-il vraiment la version AMP pour les Core Web Vitals même si la version mobile est indexée ?

Quelle version Google teste-t-il réellement pour les Core Web Vitals ?

La déclaration de Mueller tranche une ambiguïté que beaucoup de SEO rencontrent : l'indexation et l'évaluation de la performance ne se font pas nécessairement sur la même version. Google indexe le contenu de la version mobile classique (dans le cadre du mobile-first indexing), mais teste les Core Web Vitals sur la version que l'utilisateur voit effectivement.

Concrètement ? Si votre site propose une version AMP et que vos utilisateurs sont redirigés vers cette version depuis les SERP, c'est la version AMP qui sera évaluée pour le LCP, FID, CLS et le page experience score global. Même si le contenu indexé provient de la version mobile standard. Cette dissociation entre indexation et évaluation de la performance crée une complexité technique que beaucoup sous-estiment.

Pourquoi cette distinction entre contenu indexé et version testée ?

Google cherche à évaluer l'expérience utilisateur réelle, pas une version théorique que personne ne voit. Si vous servez AMP aux utilisateurs mobiles, c'est cette expérience qui compte pour le classement basé sur la performance. L'indexation du contenu, elle, reste sur la version mobile classique car c'est généralement là que se trouve le contenu le plus complet et le plus à jour.

Cette logique reflète la philosophie de Google : le ranking doit refléter ce que l'utilisateur vivra réellement. Si vous cachez une version lente derrière une version AMP rapide, c'est AMP qui sera jugé. Inversement, négliger AMP alors que c'est la version servie peut torpiller vos Core Web Vitals, même si votre version mobile classique est optimisée aux petits oignons.

Comment Google identifie-t-il la version à tester ?

Google suit le parcours utilisateur depuis les SERP. Si un lien AMP est présenté (avec l'icône éclair) et que l'utilisateur clique dessus, c'est la version AMP qui sera considérée comme la version vue. Les données Chrome User Experience Report (CrUX) reflètent également cette réalité : elles agrègent les métriques des utilisateurs réels, quelle que soit la version qu'ils consultent.

Pour les sites qui proposent à la fois une version mobile et AMP, cela signifie que les deux versions peuvent théoriquement être testées, selon le point d'entrée de l'utilisateur. Mais si AMP domine dans vos points d'entrée depuis Google, c'est principalement cette version qui alimentera vos scores de performance dans Search Console et influencera votre ranking.

• La version testée pour les Core Web Vitals est celle que l'utilisateur voit réellement, pas nécessairement celle indexée pour le contenu.
• Si AMP est servi aux utilisateurs, c'est cette version qui impacte le page experience score, même si l'indexation se fait sur la version mobile classique.
• Les données CrUX reflètent l'expérience utilisateur réelle, donc la version effectivement consultée (AMP ou mobile).
• Maintenir deux versions (mobile et AMP) signifie surveiller et optimiser les deux pour les Core Web Vitals si les deux sont servies aux utilisateurs.
• Désactiver AMP sans stratégie de migration peut impacter négativement vos métriques de performance si AMP était la version dominante vue par les utilisateurs.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et elle confirme ce que beaucoup de SEO ont constaté en analysant les données Search Console et PageSpeed Insights. Les sites avec AMP voient souvent des écarts importants entre les performances de leur version mobile et AMP dans les rapports Core Web Vitals. Cette déclaration explique pourquoi : Google teste la version servie, pas la version indexée.

Cela dit, la nuance réside dans la proportion d'utilisateurs qui atterrissent réellement sur AMP versus la version mobile classique. Si AMP n'est servi qu'à une minorité d'utilisateurs (par exemple, via Google Discover uniquement), l'impact sur le ranking global sera limité. Mais si AMP est la version dominante depuis les SERP mobiles, négliger sa performance est une erreur stratégique majeure. [À vérifier] : Google n'a jamais précisé explicitement comment il pondère les données CrUX quand un site sert deux versions à des proportions variables.

Quelles ambiguïtés subsistent dans cette déclaration ?

Mueller ne précise pas comment Google gère les cas où un même site sert AMP à certains utilisateurs et la version mobile classique à d'autres. Les données CrUX sont-elles agrégées ? Séparées par version ? Pondérées selon le volume de trafic ? On ne sait pas. Cette zone grise crée une incertitude pour les sites en transition entre AMP et versions mobiles optimisées.

Autre point flou : que se passe-t-il si la version AMP est techniquement servie mais peu consultée (par exemple, si les utilisateurs préfèrent cliquer sur le lien canonique non-AMP quand les deux sont proposés) ? Google teste-t-il uniquement la version vue, ou applique-t-il une heuristique basée sur la disponibilité technique d'AMP ? La déclaration suggère le premier cas, mais sans données officielles, impossible d'en être certain. [À vérifier]

Dans quels cas cette règle peut-elle poser problème ?

Le principal piège concerne les sites qui ont déployé AMP il y a quelques années et l'ont laissé en friche. Si cette version est techniquement toujours servie mais n'a pas suivi les évolutions techniques (nouveaux formats d'annonces, optimisations CLS récentes, lazy loading amélioré), elle peut devenir un boulet pour vos Core Web Vitals, même si votre version mobile est au top.

Inversement, certains sites ont abandonné AMP sans le supprimer complètement, créant des situations où Google continue de tester une version obsolète parce qu'elle reste techniquement accessible. Résultat : des scores de performance catastrophiques qui ne reflètent pas la réalité de la version mobile optimisée. Soyons honnêtes : maintenir deux versions synchronisées est chronophage et source d'erreurs. Si AMP ne vous apporte pas de bénéfice mesurable en termes de trafic ou de conversion, le jeu n'en vaut peut-être plus la chandelle.

Que faut-il auditer en priorité sur votre site ?

Première étape : identifiez quelle version est effectivement servie aux utilisateurs depuis les SERP mobiles. Faites des recherches représentatives de vos requêtes cibles sur mobile et vérifiez si Google présente l'icône AMP. Consultez Search Console pour voir si des pages AMP apparaissent dans vos rapports Core Web Vitals. Si AMP est présent, vous devez le traiter comme une version stratégique, pas comme un legacy technique.

Ensuite, comparez les performances des deux versions (mobile et AMP) dans PageSpeed Insights et le rapport Core Web Vitals de Search Console. Si AMP est servi mais affiche des scores inférieurs à la version mobile, vous avez un problème. L'inverse est également vrai : une version mobile lente ne vous pénalisera pas si c'est AMP que Google teste, mais cela révèle une dette technique qu'il faudra régler si vous désactivez AMP un jour.

Comment optimiser la version réellement testée ?

Si AMP est la version dominante, concentrez vos efforts d'optimisation sur cette version : réduisez le poids des composants AMP, optimisez le chargement des polices et des images, surveillez le CLS causé par les publicités AMP. Beaucoup de sites négligent ces optimisations en pensant qu'AMP est « rapide par défaut », mais les composants publicitaires et le contenu tiers peuvent ruiner vos scores.

Si vous décidez d'abandonner AMP, prévoyez une phase de migration progressive : désactivez AMP sur un segment de pages test, surveillez l'impact sur les Core Web Vitals dans Search Console, puis généralisez si les résultats sont positifs. Ne supprimez pas AMP brutalement sans vérifier que la version mobile peut assumer la charge de performance. Et surtout, assurez-vous que les redirections sont propres pour éviter que Google continue de tester une version AMP fantôme.

Quelles erreurs éviter absolument ?

Erreur classique : optimiser uniquement la version mobile en ignorant AMP, alors que c'est AMP qui est servi et testé. Résultat : vos efforts n'impactent pas vos scores de performance réels. Autre piège : désactiver AMP sans mettre en place de redirections 301 correctes, ce qui peut créer des erreurs 404 et perturber l'indexation temporairement.

Enfin, ne tombez pas dans le syndrome du « deux versions parfaites ». Maintenir deux versions optimisées en parallèle est coûteux en temps et en ressources techniques. Si AMP ne vous apporte pas de gains mesurables (vitesse de crawl, taux de clic amélioré, etc.), il peut être plus rentable de vous concentrer sur une seule version mobile ultra-optimisée et de rediriger tout le trafic vers elle. Ces arbitrages techniques et stratégiques peuvent être complexes à trancher seul. Si vous hésitez sur la meilleure approche pour votre site, faire appel à une agence SEO spécialisée peut vous aider à évaluer précisément l'impact de chaque scénario et à piloter la transition sans risque de perte de trafic.

• Vérifiez dans Search Console et sur les SERP mobiles si AMP est effectivement servi à vos utilisateurs.
• Comparez les Core Web Vitals de vos versions mobile et AMP dans PageSpeed Insights et le CrUX.
• Si AMP est dominant, optimisez en priorité cette version (poids des composants, CLS publicitaire, lazy loading).
• Si vous désactivez AMP, testez d'abord sur un segment de pages et surveillez l'impact avant de généraliser.
• Mettez en place des redirections 301 propres si vous supprimez AMP pour éviter les erreurs 404 et la perte de signaux.
• Évitez de maintenir deux versions en parallèle si AMP n'apporte pas de bénéfice mesurable en trafic ou conversion.