Comment Google mesure-t-il les Core Web Vitals sur vos pages AMP et non-AMP ?

Pourquoi Google distingue-t-il les données CWV entre AMP et non-AMP ?

Google collecte les Core Web Vitals à partir de l'expérience réelle des utilisateurs via le Chrome User Experience Report (CrUX). Quand un site propose deux versions — AMP et non-AMP — les utilisateurs peuvent atteindre ces pages par des chemins différents.

Les visiteurs provenant de Google Search accèdent souvent à la version AMP (notamment via les carrousels Top Stories ou les résultats mobiles optimisés). Les visiteurs arrivant directement (favoris, liens externes, réseaux sociaux) atterrissent généralement sur la version canonique non-AMP. Google enregistre donc deux jeux de métriques distincts pour ces deux URLs.

Quelle version compte pour le classement dans les résultats de recherche ?

Google applique une logique simple mais souvent mal comprise : le ranking s'appuie sur les données CWV de la version que l'utilisateur verra dans les SERP. Si votre page AMP s'affiche dans les résultats, Google évalue ses métriques LCP, FID, CLS.

Inversement, si c'est la version non-AMP qui apparaît, ce sont ses données qui déterminent le signal page experience. Cette distinction est critique : vous pouvez avoir une version canonique avec d'excellents CWV, mais si l'AMP affichée dans Search est lente, c'est ce dernier score qui pénalise votre positionnement.

Comment Google décide-t-il quelle version afficher dans les SERP ?

La décision dépend de plusieurs facteurs : le type de résultat (Top Stories favorise AMP), le contexte utilisateur (mobile vs desktop), et les annotations techniques (balises rel=amphtml et rel=canonical). Google privilégie parfois AMP pour des raisons de vitesse de chargement ou de format (carrousels).

Mais attention — et c'est là que ça coince — Google ne communique pas toujours clairement quel critère prévaut dans chaque cas. Un site peut voir son AMP servi dans certaines requêtes et sa version standard dans d'autres, créant une fragmentation des signaux difficile à piloter.

• Google collecte les données CWV séparément pour AMP et non-AMP via CrUX
• Seules les métriques de la version affichée dans Search impactent le classement
• La version servie dépend du type de résultat, du contexte utilisateur et des annotations techniques
• Un site peut voir différentes versions servies selon les requêtes, fragmentant les signaux CWV
• Les métriques de trafic direct (souvent non-AMP) n'influencent pas le ranking si AMP est affiché dans les SERP

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

Oui, cette logique correspond aux patterns observés sur des sites dual-stack AMP/non-AMP. Les données CrUX montrent effectivement deux origines distinctes quand les versions sont hébergées sur des URLs différentes (par exemple example.com vs example.com/amp/). La Search Console affiche d'ailleurs ces métriques séparément.

Mais — et c'est un point que Mueller n'aborde pas — cette séparation pose un problème d'attribution. Quand Google oscille entre servir AMP ou non-AMP selon les requêtes, vous ne pouvez pas piloter une stratégie CWV unifiée. Vous devez optimiser deux versions, sans toujours savoir laquelle sera évaluée pour quelle requête. [A vérifier] : la proportion exacte des cas où Google bascule entre les deux versions sur un même site reste floue.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller simplifie un mécanisme en réalité plus granulaire. Google collecte les données CWV au niveau de l'origine (domain), puis les agrège par page. Mais les seuils de suffisance statistique dans CrUX impliquent qu'une page AMP peu visitée peut ne pas avoir de données propres — Google utilise alors les métriques de l'origine complète.

Concrètement ? Si votre AMP reçoit peu de trafic organique direct, Google peut appliquer les métriques globales de votre domaine, diluant l'impact spécifique de cette version. Par ailleurs, la distinction AMP/non-AMP devient obsolète avec le déclin progressif d'AMP : Google a retiré l'icône éclair, réduit les privilèges dans Top Stories, et les sites migrent massivement vers des solutions non-AMP optimisées.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre site utilise AMP paired mode (version AMP et non-AMP coexistent sur des URLs distinctes), la règle s'applique pleinement. Mais si vous utilisez AMP-only (une seule version pour tout le trafic), la distinction disparaît : il n'y a qu'un seul jeu de métriques.

Autre cas limite : les sites qui ont abandonné AMP mais conservent encore des URLs AMP indexées. Google peut continuer à servir ces anciennes pages dans certains résultats, créant une dette technique invisible. Sans redirection 301 propre vers les versions canoniques, ces zombies AMP plombent vos CWV sans que vous le remarquiez dans vos dashboards habituels.

Que faut-il faire concrètement pour gérer les CWV sur AMP et non-AMP ?

Première étape : identifiez quelle version Google affiche réellement dans les SERP pour vos requêtes prioritaires. Utilisez la Search Console (Performance > Pages) pour croiser les URLs indexées avec les données CWV (Expérience > Core Web Vitals). Si vous voyez un mix AMP/non-AMP, vous devez optimiser les deux.

Pour chaque version, auditez séparément les métriques CrUX : LCP (chargement du plus grand élément visible), FID (réactivité à la première interaction), CLS (stabilité visuelle). Les solutions diffèrent : sur AMP, la marge d'optimisation est limitée par le framework (pas de JS custom), alors que sur non-AMP vous contrôlez tout le stack — lazy loading, preload, code splitting.

Quelles erreurs éviter dans un environnement dual-stack ?

Erreur classique : optimiser uniquement la version non-AMP en pensant que c'est la version canonique qui compte. Si Google sert votre AMP dans Search, vos efforts sont perdus. Autre piège : ne pas monitorer les changements de comportement de Google. Le moteur peut décider de basculer d'AMP vers non-AMP (ou l'inverse) sans préavis, modifiant brutalement les métriques évaluées.

Troisième erreur : conserver des URLs AMP indexées après une migration. Ces pages orphelines continuent à recevoir du trafic sporadique, accumulant des données CWV dégradées que Google peut utiliser pour le ranking. Mettez en place des redirections 301 propres et désindexez explicitement les anciennes URLs AMP.

Comment vérifier que votre configuration est optimale ?

Utilisez PageSpeed Insights avec l'API CrUX pour comparer les métriques field data (utilisateurs réels) entre vos versions AMP et non-AMP. Si l'écart est significatif, identifiez quelle version Google sert majoritairement via la Search Console (rapport Performances, filtre par page).

Testez manuellement vos requêtes prioritaires en navigation privée mobile : Google affiche-t-il l'AMP ou la version standard ? Si la réponse varie selon les requêtes, vous êtes dans un scénario hybride complexe. Dans ce cas, priorisez l'optimisation de la version la plus fréquemment servie, mais ne négligez pas l'autre — un écart trop important peut vous pénaliser sur des segments de requêtes.

• Auditez dans Google Search Console quelles URLs (AMP vs non-AMP) sont indexées et servent du trafic organique
• Comparez les données CrUX (PageSpeed Insights ou CrUX API) pour chaque version séparément
• Testez manuellement vos requêtes prioritaires en navigation privée mobile pour identifier quelle version Google affiche
• Si dual-stack, optimisez les deux versions en parallèle — ne misez pas tout sur la version canonique
• Après migration d'AMP vers non-AMP, mettez en place des redirections 301 et désindexez les anciennes URLs AMP
• Monitorez mensuellement les changements de comportement de Google : la version servie peut basculer sans préavis