Google suit-il vraiment les Core Web Vitals des pages AMP et non-AMP séparément ?

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

La logique de Google repose sur un principe simple : les Core Web Vitals reflètent l'expérience utilisateur réelle, et cette expérience varie drastiquement selon l'URL visitée. Une page AMP, par conception, charge différemment d'une version HTML classique — cache Google, JS restreint, CSS inline.

Google utilise le Chrome User Experience Report (CrUX) pour collecter ces métriques. Quand un utilisateur Chrome visite une URL, les données (LCP, FID, CLS) sont rattachées à cette URL précise. Si votre site propose example.com/article ET example.com/article/amp/, ce sont deux URLs différentes avec deux historiques CrUX distincts.

Cette approche change radicalement la donne pour les sites qui maintiennent deux versions en parallèle. Vous ne pouvez plus compter sur les performances AMP pour "sauver" les métriques de vos pages standard — et inversement, une version non-AMP catastrophique n'affecte pas directement vos URLs AMP.

Comment Search Console affiche-t-il ces données distinctes ?

Dans le rapport Signaux Web essentiels de Search Console, chaque URL est évaluée individuellement. Si 80% de votre trafic organique atterrit sur des pages AMP ultra-rapides mais que 20% frappe des versions non-AMP lentes, vous verrez deux ensembles de données.

Le piège ? Search Console agrège par groupes d'URLs similaires. Si vous avez /article (non-AMP) ET /article/amp/, ils peuvent apparaître dans deux lignes distinctes du rapport. Certains praticiens SEO pensent encore voir une "moyenne" globale — c'est faux. Vous devez analyser chaque version séparément.

Concrètement, cela signifie que votre stratégie de monitoring doit segmenter AMP vs non-AMP dès le départ. Impossible de diagnostiquer correctement sans cette distinction.

Quelle version Google utilise-t-il pour le classement ?

Si Google indexe et affiche votre page AMP dans les résultats de recherche, ce sont les CWV de l'URL AMP qui comptent pour ce résultat. Si c'est la version non-AMP qui apparaît, ce sont ses métriques à elle qui jouent.

Le changement majeur post-Page Experience Update : Google ne privilégie plus automatiquement AMP dans les top stories. Il évalue chaque URL sur ses propres mérites. Une page non-AMP avec d'excellents CWV peut surpasser une AMP médiocre.

• Google suit deux datasets CrUX distincts pour les versions AMP et non-AMP d'une même page
• Search Console affiche ces données séparément, sans moyenne globale
• Le classement dépend de l'URL réellement indexée et affichée dans les SERPs
• Le trafic direct impacte les métriques non-AMP, le trafic Search peut alimenter les deux versions
• Une version peut être "Bonne" pendant que l'autre est "À améliorer" dans le même rapport

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

Absolument. Les praticiens qui ont migré d'AMP vers non-AMP exclusivement ont constaté des changements brutaux dans leurs rapports CWV — pas une transition graduelle, mais un reset complet. Les données historiques AMP deviennent inutiles pour prédire les performances post-migration.

Ce qui surprend encore certains SEO : même quand Google affiche la version AMP en cache (via l'ancien système de top stories), les métriques CrUX proviennent bien de l'URL AMP elle-même. Pas de "transfert" magique entre les deux versions. Chacune vit sa propre vie dans CrUX.

Quelles implications cette séparation a-t-elle sur la stratégie AMP ?

Soyons honnêtes : depuis que Google a abandonné le badge AMP et le carrousel dédié, maintenir deux versions devient souvent un poids mort. Si vos pages non-AMP sont rapides, l'AMP n'apporte plus de bénéfice SEO direct — juste une complexité technique doublée.

Le problème que j'observe : des sites qui ont investi dans AMP il y a 3-4 ans continuent de maintenir les deux versions par inertie. Résultat ? Deux surfaces d'attaque pour les problèmes CWV, deux ensembles de templates à optimiser, deux séries de bugs potentiels. Et c'est là que ça coince.

Si votre trafic AMP représente moins de 10% du total et que vos pages standard sont déjà performantes, vous gaspillez probablement des ressources. [À vérifier] : Google n'a jamais publié de données claires sur le taux de clics AMP vs non-AMP dans les résultats actuels — on navigue à vue.

Dans quels cas cette règle devient-elle problématique ?

Le cas classique : un site d'actualités avec strong trafic direct sur desktop (non-AMP) et trafic Search majoritairement mobile (AMP). Vous obtenez deux images complètement différentes de vos performances, et aucune des deux ne reflète la "vraie" expérience utilisateur globale.

Autre piège : les canonical croisés mal configurés. Si votre page AMP pointe vers la non-AMP en canonical mais que Google continue d'indexer l'AMP, vous pouvez avoir une version indexée avec d'excellents CWV... mais qui n'est jamais affichée aux utilisateurs. Le bénéfice SEO théorique ne se traduit pas en réalité.

Comment auditer correctement vos données CWV avec deux versions ?

Première étape : identifiez précisément quelle version Google indexe et affiche dans les SERPs pour vos pages stratégiques. Un simple "site:" ne suffit pas — utilisez l'outil d'inspection d'URL de Search Console pour voir l'URL canonique reconnue par Google.

Deuxième action : segmentez vos rapports CWV dans Search Console par pattern d'URL. Créez des filtres pour /amp/, /amp.html, ou le schéma que vous utilisez. Analysez les deux groupes séparément, comme s'il s'agissait de deux sites distincts.

Troisième point crucial : vérifiez votre Google Analytics ou équivalent. Si 90% de votre trafic organique mobile atterrit sur des URLs AMP mais que votre développement se concentre sur les pages standard, vous optimisez la mauvaise cible. Alignez vos priorités sur la réalité du trafic.

Faut-il abandonner AMP ou le maintenir ?

La réponse dépend de trois facteurs : volume de trafic AMP actuel, différentiel de performance entre les deux versions, et coût de maintenance. Si vos pages non-AMP atteignent déjà "Bonne" dans CWV et que l'AMP ne représente que 5% du trafic, la décision est facile.

Mais si vous êtes un site d'actualités avec 40% de trafic mobile passant par AMP et que vos pages standard plafonnent à "À améliorer", abandonner AMP pourrait dégrader brutalement vos métriques globales. Dans ce cas, mieux vaut d'abord optimiser les non-AMP avant de migrer.

Le timing compte : planifiez une migration progressive en redirigeant 10-20% du trafic AMP vers non-AMP via des tests A/B. Mesurez l'impact CWV réel avant de basculer à 100%. Une migration brutale peut provoquer une chute temporaire si vos pages standard ne sont pas prêtes.

Quelles erreurs éviter dans le monitoring ?

Erreur numéro un : mélanger les métriques AMP et non-AMP dans un dashboard unique sans distinction. Vous obtenez une "moyenne" qui ne correspond à aucune expérience utilisateur réelle. Créez deux vues séparées dans vos outils de reporting.

Deuxième piège : ignorer les données CrUX au profit de tests synthétiques (Lighthouse, PageSpeed Insights en mode labo). Ces outils testent une URL à la fois, dans des conditions idéales qui ne reflètent pas le terrain. CrUX capture la vraie expérience — réseau 3G, devices bas de gamme, extensions Chrome actives.

Troisième erreur classique : déployer des optimisations sur la version non-AMP et attendre que Search Console reflète les changements en quelques jours. CrUX nécessite 28 jours de données utilisateur réel minimum pour mettre à jour un groupe d'URLs. Patience et suivi dans la durée sont indispensables.

• Identifiez quelle version (AMP ou non-AMP) Google indexe réellement pour chaque segment de pages
• Segmentez vos rapports Search Console avec des filtres d'URL distincts pour AMP et non-AMP
• Comparez le volume de trafic réel entre les deux versions via Analytics avant toute décision stratégique
• Si vous maintenez les deux, déployez les optimisations CWV sur les DEUX versions en parallèle
• Si vous migrez, testez progressivement (10-20% du trafic) avant un basculement complet
• Utilisez CrUX (données réelles) comme référence, pas uniquement Lighthouse (synthétique)