Pourquoi Google n'indexe-t-il pas vos pages AMP non-canoniques ?

Que signifie exactement "AMP non-canonique" ?

Une page AMP non-canonique est une version AMP qui pointe via sa balise canonical vers la page HTML principale. C'est le schéma classique : vous avez example.com/article (HTML) et example.com/article/amp (AMP), et cette dernière déclare la première comme version de référence.

Dans ce scénario, Google traite l'AMP comme un format alternatif, au même titre qu'une version imprimable ou mobile spécifique. L'index de Google stocke uniquement la page HTML standard. L'AMP est conservé en tant que variante de présentation, utilisée pour servir les utilisateurs mobiles dans les SERP quand la vitesse de chargement est critique.

Comment Google décide-t-il quelle version indexer ?

La logique suit strictement la balise canonical. Si votre AMP pointe vers le HTML via rel="canonical", Google considère le HTML comme la version principale et n'indexe que celle-ci. L'inverse existe aussi : une page AMP peut être self-canonical (pointer vers elle-même), auquel cas c'est cette version qui entre dans l'index.

Cette déclaration de Gary Illyes clarifie un point souvent mal compris : avoir une version AMP ne crée pas automatiquement deux entrées distinctes dans l'index Google. Le moteur consolide les signaux (backlinks, ancres, engagement) sur la version canonique uniquement.

Quelles conséquences pour le crawl et le budget d'exploration ?

Techniquement, Googlebot crawle les deux versions — la HTML et l'AMP — pour valider la cohérence et détecter le format alternatif. Mais seule la version canonique bénéficie de l'indexation complète et du calcul de PageRank interne.

Cela signifie que si vous investissez du temps à optimiser finement votre AMP non-canonique (balises schema, maillage interne poussé), ces efforts n'impactent pas directement votre positionnement. Ils peuvent influencer l'expérience utilisateur une fois que le visiteur atterrit sur l'AMP depuis les SERP mobiles, mais les signaux SEO remontent vers la version HTML.

• Version canonique HTML : seule indexée, reçoit tous les signaux SEO (liens, autorité, contenu).
• Version AMP alternative : crawlée mais non indexée séparément, sert uniquement à la diffusion rapide sur mobile.
• Consolidation des signaux : tous les backlinks, ancres et métriques d'engagement sont attribués à la page canonique HTML.
• Balise canonical critique : une erreur dans sa configuration peut inverser le schéma d'indexation ou créer des conflits de duplication.

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

Globalement, oui. Les tests menés sur des sites utilisant AMP comme format alternatif montrent bien que les backlinks pointant vers l'AMP apparaissent dans les outils d'analyse de liens comme associés à la version HTML canonique. Google consolide effectivement les signaux.

Cependant, un point mérite attention : certains professionnels ont observé des cas où Google affiche l'URL AMP dans les SERP même quand elle n'est pas canonique, créant une confusion perçue. L'URL visible peut être l'AMP (avec le logo éclair), mais l'indexation reste bien sur le HTML. C'est une distinction subtile entre indexation et présentation.

Quelles nuances faut-il apporter à cette règle ?

La déclaration de Gary Illyes s'applique au schéma AMP-as-alternative. Si votre stratégie consiste à faire de l'AMP la version canonique (self-canonical), alors c'est bien l'AMP qui est indexée. Ce choix reste rare en pratique, sauf pour des médias ayant tout misé sur AMP dès le départ. [A vérifier] : Google n'a jamais publié de données chiffrées sur la répartition entre ces deux approches.

Autre nuance : même si l'AMP n'est pas indexée séparément, elle doit rester techniquement valide selon les specs AMP. Une AMP cassée ou invalide peut entraîner un refus d'affichage dans les SERP mobiles, vous privant du bénéfice UX que vous recherchiez initialement.

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

Le problème surgit quand un site configure mal ses canonicals, créant un conflit bidirectionnel : le HTML pointe vers l'AMP et vice-versa. Dans ce cas, Google doit trancher, et l'algo choisit généralement la version qu'il estime la plus pertinente — ce qui peut ne pas être celle que vous souhaitez indexer.

Autre cas critique : si vous avez construit une stratégie de contenu distinct entre HTML et AMP (par exemple, un résumé sur AMP et le contenu complet sur HTML), la non-indexation de l'AMP signifie que ce résumé ne sera jamais découvert directement via la recherche organique. Soyons honnêtes, cette stratégie de contenu différencié est rarement judicieuse en SEO.

Que faut-il vérifier sur mon site AMP actuel ?

Première action : auditer vos balises canonical sur toutes les pages AMP. Elles doivent pointer explicitement vers la version HTML principale si vous utilisez AMP comme format alternatif. Utilisez un crawler comme Screaming Frog ou Oncrawl pour extraire ces balises à l'échelle.

Ensuite, vérifiez que vos pages HTML contiennent bien la balise rel="amphtml" pointant vers l'équivalent AMP. C'est ce lien bidirectionnel qui permet à Google de détecter et associer les deux versions. Un lien manquant ou rompu empêche l'affichage du logo éclair dans les SERP mobiles.

Comment s'assurer que les signaux SEO remontent correctement ?

Testez la consolidation des backlinks : si un lien externe pointe vers votre URL AMP, il devrait apparaître dans votre profil de liens (Search Console, Ahrefs, Majestic) comme associé à l'URL HTML canonique. Si ce n'est pas le cas, c'est un signal que Google n'a pas correctement interprété votre configuration canonical.

Surveillez également vos Core Web Vitals sur les deux versions. Même si l'AMP n'est pas indexée, Google peut évaluer sa performance pour décider de l'afficher ou non aux utilisateurs mobiles. Une AMP lente ou boguée perd son intérêt — et c'est là que ça coince souvent.

Quelles erreurs éviter absolument ?

Ne créez jamais de contenu unique sur vos pages AMP non-canoniques. Tout ce qui n'existe que sur l'AMP ne sera pas indexé, donc invisible pour Google. Le contenu doit être strictement équivalent entre HTML et AMP (modulo les contraintes techniques AMP).

Évitez aussi de dupliquer vos efforts d'optimisation sémantique ou de schema markup uniquement sur l'AMP. Ces efforts doivent d'abord porter sur la version HTML canonique. L'AMP peut ensuite en hériter ou les reproduire, mais elle ne doit jamais être la seule version optimisée.

• Vérifier que chaque page AMP contient une balise canonical pointant vers le HTML principal.
• Confirmer que chaque page HTML inclut un lien rel="amphtml" vers son équivalent AMP.
• Tester la validité AMP via l'outil officiel Google AMP Test ou Search Console.
• Auditer les backlinks externes pour s'assurer qu'ils sont consolidés sur la version canonique HTML.
• Comparer le contenu HTML et AMP pour garantir une équivalence stricte (titres, paragraphes, images essentielles).
• Monitorer les Core Web Vitals sur les deux versions pour éviter toute dégradation de performance.