Declaration officielle
Autres déclarations de cette vidéo 6 ▾
- 7:06 Google peut-il vraiment distinguer le vrai du faux dans vos contenus ?
- 18:28 Pourquoi votre page est-elle invisible dans Google sans être spam ?
- 35:03 Les pages de faible qualité pénalisent-elles vraiment vos pages performantes ?
- 43:29 L'AMP est-il vraiment utile pour le SEO hors carrousel actualités ?
- 48:34 Comment éviter les conseils SEO qui tuent votre référencement ?
- 53:40 Pourquoi Google peut modifier ses alertes Search Console sans vous prévenir ?
Google ne déploie pas de user-agent distinct pour crawler les pages AMP : c'est le Googlebot mobile standard qui s'en charge. L'essentiel réside dans la configuration correcte du lien canonique permettant à Google d'associer version AMP et version classique. Si cette annotation est mal ficelée, Google risque de traiter vos pages AMP comme du contenu orphelin ou dupliqué, avec des conséquences directes sur l'indexation.
Ce qu'il faut comprendre
Pourquoi Google n'a-t-il pas créé de user-agent dédié pour AMP ?
La logique est simple : Google traite AMP comme un format de page mobile, pas comme un protocole à part. Créer un user-agent séparé aurait impliqué une complexité technique inutile pour les webmasters et une gestion supplémentaire côté infrastructure. Le Googlebot mobile habituel (celui qui se présente avec un user-agent smartphone) prend en charge le crawl des versions AMP exactement comme il crawle n'importe quelle page responsive.
Cette approche évite la fragmentation : pas besoin de gérer deux configurations robots.txt distinctes, ni de surveiller deux profils de crawl différents dans Search Console. Google centralise le comportement de crawl mobile, qu'il s'agisse de pages AMP, de pages mobiles classiques ou de sites responsive.
Qu'est-ce que l'annotation canonique et pourquoi est-elle critique ?
L'annotation canonique est le lien qui relie votre page AMP à sa version HTML classique. Techniquement, il s'agit d'une balise <link rel="canonical"> placée dans le <head> de la page AMP, pointant vers l'URL de la version standard. Inversement, la page HTML classique doit contenir une balise <link rel="amphtml"> pointant vers l'AMP.
Sans cette double annotation, Google ne peut pas comprendre que ces deux pages sont liées. Il risque alors de les considérer comme du contenu dupliqué, d'indexer l'une en ignorant l'autre, ou pire, de ne pas servir la version AMP dans les contextes où elle serait pertinente (recherche mobile, carrousels Top Stories). La découvrabilité repose entièrement sur cette configuration bidirectionnelle.
Comment Google découvre-t-il vos pages AMP concrètement ?
Le processus commence par le crawl de votre page HTML classique. Le Googlebot mobile parcourt votre contenu, détecte la balise <link rel="amphtml">, puis suit ce lien pour crawler la version AMP. Une fois sur la page AMP, il vérifie la présence de la balise canonical pointant en retour vers l'URL d'origine.
Si cette boucle est cohérente, Google comprend qu'il s'agit de deux représentations du même contenu et peut décider laquelle servir selon le contexte (appareil, fonctionnalité de recherche). Si la boucle est rompue ou contradictoire, Google ignore généralement la version AMP ou la traite comme une page orpheline, ce qui casse votre stratégie mobile.
- Pas de user-agent spécifique AMP : le Googlebot mobile classique s'en charge.
- Annotation bidirectionnelle obligatoire : rel="amphtml" sur la page standard, rel="canonical" sur la page AMP.
- Crawl en deux temps : détection de l'AMP depuis la page classique, puis vérification du canonical.
- Cohérence requise : toute incohérence entre les deux annotations bloque l'association des versions.
- Impact direct sur l'indexation : erreur de configuration = perte de visibilité mobile ou duplication de contenu.
Avis d'un expert SEO
Cette déclaration est-elle cohérente avec les observations terrain ?
Oui, c'est parfaitement aligné avec ce qu'on observe dans les logs serveur et dans Search Console. Les requêtes crawl AMP proviennent bien du Googlebot mobile standard, avec le même user-agent string qu'une page mobile classique. On ne voit jamais de bot distinct identifiable pour AMP, contrairement à d'autres technologies comme Google-InspectionTool qui a son propre user-agent.
Là où ça coince parfois, c'est que certains webmasters s'attendent à voir un signal explicite dans leurs outils de monitoring. Ils cherchent un marqueur "AMP" dans les logs alors que le seul indicateur fiable est l'URL crawlée elle-même (souvent en /amp/ ou avec un paramètre ?amp=1). Cette confusion conduit à des erreurs de diagnostic quand le crawl AMP n'apparaît pas dans leurs rapports filtrés.
Quelles erreurs fréquentes cette déclaration permet-elle d'éviter ?
La première, c'est de bloquer par erreur le crawl AMP via robots.txt en pensant qu'un user-agent spécifique existe. Certains sites configurent des règles pour "Googlebot-AMP" qui n'existe pas, ou bloquent /amp/ en croyant protéger du trafic bot, alors qu'ils empêchent simplement Google de découvrir ces pages. Le résultat : des pages AMP orphelines qui ne s'affichent jamais dans les résultats mobiles.
Deuxième erreur classique : négliger la balise canonical côté AMP. Beaucoup de CMS génèrent automatiquement le rel="amphtml" sur la page standard, mais oublient d'ajouter le canonical inverse sur l'AMP. Google crawle alors la version AMP, ne trouve pas de lien retour, et considère le contenu comme dupliqué ou non lié. On voit ça régulièrement sur des sites WordPress où le plugin AMP est mal configuré ou désactivé puis réactivé sans audit complet.
Faut-il encore investir dans AMP aujourd'hui ?
C'est la vraie question, et Google reste volontairement flou. AMP a perdu son statut de critère de ranking privilégié depuis que les Core Web Vitals sont devenus le standard mobile. Les carrousels Top Stories ne requièrent plus AMP depuis quelques années. Techniquement, rien n'oblige à maintenir des pages AMP pour performer en SEO mobile.
Mais : sur certains secteurs (actualités, e-commerce mobile intensif), AMP continue d'offrir un avantage de vitesse réel, surtout sur des connexions 3G ou dans des zones géographiques où la latence réseau est élevée. Si votre trafic mobile représente 70%+ et que vos Core Web Vitals peinent à passer au vert, AMP reste un levier tactique. [À vérifier] : Google n'a jamais confirmé officiellement si AMP bénéficie encore d'un léger boost algorithmique caché, mais rien dans les patents récents ne le suggère.
Impact pratique et recommandations
Que faut-il vérifier en priorité sur vos pages AMP existantes ?
Commencez par auditer la cohérence des annotations bidirectionnelles. Crawlez votre site avec Screaming Frog ou un outil équivalent en mode mobile, extrayez toutes les balises rel="amphtml" depuis vos pages standards, puis vérifiez que chaque URL AMP ciblée contient bien un rel="canonical" pointant en retour vers l'URL d'origine. Toute asymétrie (AMP sans canonical, ou canonical pointant vers une mauvaise URL) doit être corrigée immédiatement.
Ensuite, contrôlez dans Search Console l'index des pages AMP. Google propose un rapport dédié "AMP" (si vos pages sont détectées) qui liste les erreurs de validation et les problèmes d'indexation. Si des pages AMP n'apparaissent pas dans ce rapport alors qu'elles existent, c'est probablement que le lien amphtml n'est pas découvert lors du crawl de la version standard.
Comment tester que Google crawle correctement vos AMP ?
Utilisez l'outil Inspection d'URL dans Search Console sur une page HTML standard contenant un lien amphtml. Google vous indique s'il a détecté la version AMP associée. Si ce n'est pas le cas, inspectez le code source de votre page : la balise amphtml est-elle présente dans le <head> ? Pointe-t-elle vers une URL valide et accessible ?
Ensuite, inspectez directement l'URL AMP. Google doit vous confirmer qu'elle est indexable et qu'elle contient un canonical valide. Si l'outil signale "Page alternative avec balise canonique appropriée", c'est que la boucle fonctionne correctement. Toute autre mention ("Exclue par la balise canonical", "Détectée mais pas indexée") signale un problème de configuration à résoudre d'urgence.
Faut-il ajuster robots.txt ou les en-têtes HTTP pour AMP ?
Non, et c'est justement l'intérêt de l'approche Google. Puisque le crawl AMP utilise le Googlebot mobile standard, aucune règle spécifique n'est nécessaire dans robots.txt. Si vous bloquez déjà certaines sections de votre site au Googlebot mobile (par exemple des filtres ou des pages de pagination infinies), ces règles s'appliqueront également aux versions AMP de ces pages, ce qui est généralement cohérent.
Côté en-têtes HTTP, assurez-vous que vos pages AMP renvoient bien un Content-Type: text/html classique, et non un type MIME exotique. Certains serveurs mal configurés servent les pages AMP avec application/xhtml+xml, ce qui peut perturber le rendu ou la validation. Vérifiez également que les en-têtes de cache sont cohérents avec votre stratégie SEO globale : pas de no-index accidentel, pas de canonicalisation HTTP contradictoire avec la balise HTML.
- Auditer la présence et la cohérence des balises rel="amphtml" et rel="canonical" sur l'ensemble du site.
- Vérifier dans Search Console que les pages AMP sont détectées et indexées sans erreur de validation.
- Tester avec l'outil Inspection d'URL la découverte de la version AMP depuis la page standard.
- Contrôler les logs serveur pour s'assurer que le Googlebot mobile crawle effectivement les URLs AMP.
- Valider que robots.txt ne bloque pas involontairement les répertoires contenant les pages AMP.
- S'assurer que les en-têtes HTTP des pages AMP sont propres (Content-Type, Cache-Control, pas de no-index).
❓ Questions frequentes
Puis-je bloquer le crawl AMP dans robots.txt sans impacter le crawl mobile classique ?
Que se passe-t-il si j'oublie la balise canonical sur mes pages AMP ?
Est-ce que Search Console affiche des données de crawl séparées pour AMP ?
Faut-il un sitemap XML dédié pour les pages AMP ?
Peut-on servir une page AMP comme version canonique principale ?
🎥 De la même vidéo 6
Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 36 min · publiée le 30/06/2016
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.