Les pages AMP exclues de l'index signalent-elles vraiment une mauvaise implémentation ?

Pourquoi Google parle-t-il de pages « alternates » plutôt que de pages indépendantes ?

Les pages AMP ne sont pas indexées comme des URLs autonomes dans la majorité des cas. Elles fonctionnent comme des versions accélérées de vos pages classiques, liées par une relation bidirectionnelle : la page HTML standard pointe vers l'AMP via une balise link rel=amphtml, et l'AMP renvoie vers l'original via un canonical.

Cette architecture permet à Google de servir la version AMP dans les contextes où la vitesse prime — résultats mobiles, carrousels Top Stories — tout en préservant la page HTML comme référence canonique. Le moteur ne duplique donc pas le contenu dans son index : il stocke une URL principale et associe l'AMP comme variante.

Que signifie concrètement « un grand nombre de pages marquées comme exclues » ?

Dans la Search Console, l'onglet Couverture liste les URLs découvertes mais non indexées. Si vos pages AMP apparaissent massivement dans les catégories « Exclue par la balise noindex », « URL alternative avec balise canonical appropriée » ou « Page dupliquée sans URL canonique définie par l'utilisateur », c'est le signal d'un problème structurel.

Google tolère quelques pages AMP exclues — par exemple, des URLs de test ou des contenus volontairement désindexés. Mais un volume anormal révèle généralement que le maillage canonical est cassé, que les balises AMP/HTML sont inversées, ou que les validateurs AMP détectent des erreurs critiques bloquant l'indexation.

Pourquoi une mauvaise implémentation AMP pose-t-elle problème en SEO ?

Une configuration AMP défaillante crée du crawl budget gaspillé : Googlebot visite des dizaines ou centaines de pages qu'il finit par rejeter. Pire, si les canonical sont mal orientés, vous risquez de voir vos pages AMP indexées à la place des pages HTML — ce qui dilue les signaux de ranking entre deux versions et fragmente vos métriques.

Certains sites ont même connu des chutes de trafic en lançant AMP avec des canonical inversés, forçant Google à privilégier une version épurée sans le maillage interne, les CTA ou les schémas JSON-LD présents sur la page standard. Résultat : moins de conversions, moins de profondeur de crawl, et un désalignement total entre intention utilisateur et contenu servi.

• AMP = alternate, pas autonome : toujours liée à une page HTML classique via canonical.
• Exclusion massive = red flag : vérifie les canonical, la validation AMP, et les conflits d'URL.
• Canonical inversé : risque d'indexer AMP au lieu de HTML, avec perte de signaux SEO.
• Crawl budget : pages AMP rejetées = ressources de crawl perdues sur des URLs inutiles.
• Métriques fragmentées : deux versions indexées = dilution du ranking et confusion analytique.

Cette déclaration est-elle alignée avec les observations terrain ?

Oui, mais avec une nuance importante : Google ne précise pas le seuil à partir duquel « un grand nombre » devient problématique. Sur des sites de plusieurs milliers de pages, voir 10-15 % d'AMP exclues peut être normal — URLs de pagination, contenus archivés, ou pages volontairement noindexées. En revanche, si 50 % ou plus de vos AMP sont exclues, c'est un signal critique.

Les audits que j'ai menés montrent que les erreurs les plus fréquentes sont : (1) canonical pointant vers l'AMP elle-même au lieu de la page HTML, (2) balise rel=amphtml absente de la page classique, (3) erreurs de validation AMP non détectées en dev mais bloquantes en production. Google ne crawle pas toujours les AMP avec la même fréquence que les pages standard, donc un délai de plusieurs semaines peut s'écouler avant que les exclusions apparaissent dans la Search Console.

Faut-il s'inquiéter si mes AMP sont marquées « URL alternative avec balise canonical appropriée » ?

Non, c'est justement le comportement attendu. Ce statut confirme que Google a identifié la relation AMP/HTML et choisi d'indexer la page classique comme référence. Beaucoup de SEO paniquent en voyant des centaines d'URLs dans cette catégorie, alors que c'est exactement ce que Google recommande.

Le vrai problème survient quand vos AMP sont marquées « Exclue par la balise noindex » ou « Page dupliquée sans URL canonique définie par l'utilisateur ». Là, vous avez soit un conflit entre directives (balise noindex côté serveur vs. absence de canonical), soit une erreur de templating qui génère des URLs AMP orphelines sans lien vers l'HTML.

Dans quels cas l'implémentation AMP reste-t-elle pertinente aujourd'hui ?

Soyons honnêtes : AMP a perdu du terrain depuis que Google a retiré le badge éclair et ouvert les Top Stories aux pages non-AMP respectant les Core Web Vitals. Pour les médias qui ont investi lourdement dans AMP, désactiver la techno n'est pas trivial — risque de perte de visibilité résiduelle, refonte des templates, migration des URLs.

Mais pour un nouveau projet, [À vérifier] si AMP apporte encore un avantage tangible face à une stack moderne (Next.js, SSR, CDN bien configuré). Les tests A/B que j'ai vus montrent que les gains de vitesse d'AMP sont souvent rattrapés par une page HTML bien optimisée, avec l'avantage de ne pas gérer deux versions en parallèle.

Comment diagnostiquer une mauvaise implémentation AMP dans la Search Console ?

Rendez-vous dans Couverture > Exclues et filtrez par « AMP » dans la barre de recherche. Si vous voyez un volume anormal d'URLs sous « Page dupliquée sans URL canonique définie par l'utilisateur » ou « Exclue par la balise noindex », creusez les exemples fournis. Inspectez l'URL dans l'outil d'inspection d'URL pour voir comment Googlebot interprète les canonical et les balises de relation.

Vérifiez aussi l'onglet Améliorations > AMP : Google y liste les erreurs de validation critiques (balises interdites, CSS inline trop lourd, JavaScript non autorisé). Une erreur de validation bloque systématiquement l'indexation, même si le canonical est correct. Ne négligez pas les avertissements : ils n'empêchent pas l'indexation immédiate, mais peuvent dégrader l'expérience utilisateur au point que Google finisse par exclure la page.

Quelles erreurs de canonical éviter absolument ?

L'erreur classique : mettre un rel=canonical dans l'AMP qui pointe vers… l'AMP elle-même. Résultat, Google considère l'AMP comme page principale et ignore la version HTML. Autre piège : oublier la balise link rel=amphtml dans la page classique — sans ce lien bidirectionnel, Google ne fait pas le rapprochement et peut indexer les deux comme des contenus distincts, avec risque de cannibalisation.

Certains CMS génèrent des URLs AMP avec des paramètres (?amp=1) ou des sous-domaines (amp.example.com). Assurez-vous que les canonical pointent toujours vers l'URL sans paramètre et sur le domaine principal. Enfin, si vous utilisez des CDN ou des reverse proxies, vérifiez que les headers HTTP ne surchargent pas les balises HTML — un Link: rel=canonical en header peut entrer en conflit avec celui du <head>.

Que faire si je constate un volume élevé de pages AMP exclues ?

D'abord, quantifie le problème : si moins de 10 % de tes AMP sont exclues et qu'elles correspondent à des contenus marginaux (archives, pages de test), pas de panique. Au-delà de 20-30 %, lance un audit technique : crawl ton site avec Screaming Frog en mode AMP, exporte les canonical, et compare-les avec les URLs HTML attendues.

Ensuite, corrige les erreurs par ordre de priorité : (1) canonical inversés ou absents, (2) erreurs de validation AMP critiques, (3) balises rel=amphtml manquantes. Une fois les correctifs déployés, soumets un échantillon d'URLs AMP corrigées via l'outil d'inspection pour forcer un re-crawl rapide. Surveille l'évolution dans la Search Console sur 2-3 semaines — Google ne met pas à jour instantanément les statuts d'exclusion.

• Filtrer les URLs exclues dans Search Console et isoler les pages AMP.
• Inspecter les canonical avec l'outil d'inspection d'URL de Google.
• Vérifier que chaque page HTML contient link rel=amphtml vers son AMP.
• Valider les AMP avec l'outil officiel Google AMP Test ou ampproject.org/validator.
• Crawler le site en mode AMP avec Screaming Frog pour détecter les canonical cassés.
• Soumettre les URLs corrigées pour re-crawl via Search Console.