Faut-il vraiment supprimer vos pages AMP cassées plutôt que de les garder ?

Pourquoi Google se montre aussi strict sur les pages AMP cassées ?

Google a longtemps poussé AMP (Accelerated Mobile Pages) comme levier de performance mobile, notamment avec le carrousel Top Stories et l'éligibilité prioritaire dans certains résultats. Mais une page AMP mal implémentée — code HTML invalide, balises manquantes, ressources bloquées — génère des erreurs de validation dans la Search Console.

Ces erreurs ne sont pas anodines. Elles fragmentent le budget de crawl, créent des conflits de canonicalisation entre la version AMP et la version standard, et peuvent même provoquer une désindexation partielle si Google ne parvient pas à interpréter le contenu. Le message de Splitt est clair : si vous ne pouvez pas maintenir une page AMP valide, vous perdez plus que vous ne gagnez.

Quels sont les risques concrets d'une page AMP cassée ?

Une page AMP invalide peut provoquer plusieurs effets pervers. D'abord, elle consomme du crawl pour rien — Googlebot tente de la valider, échoue, revient plus tard, et ainsi de suite. Ensuite, elle pollue votre structure de données structurées : si vous utilisez Schema.org côté AMP et que la page est mal formée, Google peut ignorer ces signaux.

Enfin, et c'est le point le plus sournois : une page AMP cassée peut rester indexée en cache mais ne plus bénéficier des traitements prioritaires d'AMP. Résultat ? Vous croyez avoir une version AMP fonctionnelle, mais Google la traite comme une page mobile classique — sans les avantages de vitesse ni d'affichage. C'est du faux-semblant technique qui dilue vos efforts SEO sans que vous ne vous en rendiez compte immédiatement.

Comment savoir si vos pages AMP sont réellement cassées ?

La Search Console reste votre meilleur allié : rendez-vous dans la section « Expérience » > « AMP » pour identifier les erreurs de validation. Google classe ces erreurs par type : balises interdites, attributs manquants, ressources non-HTTPS, scripts bloqués, etc. Chaque erreur remonte avec l'URL concernée et un extrait du code problématique.

Mais attention : toutes les erreurs ne se valent pas. Une balise <img> non-AMP (au lieu de <amp-img>) bloque la validation intégrale, tandis qu'un attribut de tracking manquant peut passer inaperçu en production. L'outil de test AMP officiel (validator.ampproject.org) vous permet de vérifier en temps réel si une page respecte la spec AMP HTML — c'est indispensable avant chaque déploiement.

• Une page AMP invalide consomme du crawl budget inutilement et crée des conflits de canonicalisation avec la version standard.
• Google peut indexer la page AMP cassée sans lui accorder les bénéfices de vitesse ni de traitement prioritaire dans les résultats.
• La Search Console et le validator AMP officiel sont vos deux outils de diagnostic incontournables pour repérer et corriger les erreurs.
• Les erreurs AMP ne sont pas toutes bloquantes : hiérarchisez selon l'impact réel sur l'indexation et l'expérience utilisateur.
• Si vous ne pouvez pas maintenir AMP à jour, mieux vaut supprimer la version AMP que de la laisser se dégrader.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, et c'est même une position plus ferme que ce que Google affirmait il y a quelques années. À l'époque du lancement d'AMP, Google était tolérant sur les implémentations approximatives — tant que la page se chargeait vite, les erreurs de validation mineures passaient. Depuis que les Core Web Vitals sont devenus facteur de classement et qu'AMP n'est plus obligatoire pour Top Stories, Google a resserré la vis.

Sur des audits récents, on observe que des pages AMP invalides restent indexées mais ne profitent plus d'aucun boost. Pire : elles génèrent des soft 404 dans certains cas, car le contenu AMP cassé renvoie un contenu vide ou partiel. La recommandation de Splitt reflète cette réalité : si vous ne pouvez pas garantir la conformité AMP, abandonnez-la proprement.

Quelles nuances faut-il apporter à cette directive ?

D'abord, toutes les erreurs AMP ne justifient pas une suppression immédiate. Une erreur de tracking ou une balise Schema.org mal formée côté AMP n'empêche pas la validation HTML stricte — et peut être corrigée sans impact majeur. En revanche, une erreur structurelle (balise interdite, attribut manquant sur <amp-img>) bloque la validation et nécessite une action rapide.

Ensuite, la suppression d'AMP doit être accompagnée d'une redirection 301 vers la version standard, et d'une mise à jour du balisage canonique. Si vous supprimez AMP sans rediriger, vous créez des 404 massifs sur les URL AMP indexées, ce qui fragmente votre crawl et peut faire chuter temporairement votre visibilité. [A vérifier] : Google n'a jamais publié de données chiffrées sur l'impact SEO exact d'une migration AMP vers non-AMP — les retours terrain varient selon la qualité de la version standard et l'historique de crawl du site.

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

Si vous êtes dans un secteur où le carrousel Top Stories ou Google Discover génère une part significative de votre trafic, et que votre version AMP est techniquement valide mais présente des erreurs de tracking ou de Schema.org, il peut être judicieux de corriger plutôt que de supprimer. AMP reste un levier de visibilité dans certains contextes éditoriaux, notamment l'actualité et les contenus visuels à forte viralité.

En revanche, si votre version standard affiche des Core Web Vitals au vert et que votre AMP ne vous apporte pas de trafic mesurable, la suppression est la décision la plus rationnelle. Gardez en tête que maintenir AMP exige une veille technique continue — chaque mise à jour du CMS, du thème ou des scripts peut casser la validation. Si vous n'avez pas les ressources pour suivre, mieux vaut ne pas jouer avec AMP.

Que faut-il faire concrètement si vous avez des pages AMP cassées ?

Commencez par un audit complet dans la Search Console : section « Expérience » > « AMP ». Identifiez les erreurs par type et par volume d'URL affectées. Priorisez les erreurs bloquantes (balises interdites, attributs manquants) qui empêchent la validation HTML stricte — ce sont elles qui nuisent le plus au crawl et à l'indexation.

Ensuite, décidez si vous voulez réparer ou supprimer. Si vos pages AMP génèrent du trafic mesurable depuis Discover ou Top Stories, et que les erreurs sont corrigeables (balises mal formées, ressources non-HTTPS), investissez dans la correction. Si AMP ne vous apporte rien et que votre version standard est performante, supprimez les pages AMP et redirigez en 301 vers les URL standard.

Quelles erreurs éviter absolument lors d'une migration ou suppression AMP ?

Ne supprimez jamais les URL AMP sans redirection 301 — c'est la faute classique qui provoque des 404 massifs sur les URL indexées et fait chuter le trafic organique. Mettez à jour le balisage <link rel="amphtml"> côté version standard pour qu'il ne pointe plus vers une page AMP inexistante, et vérifiez que le canonical AMP renvoie bien vers la version standard.

Autre piège : oublier de soumettre un nouveau sitemap XML après la suppression d'AMP. Google continue de crawler les anciennes URL AMP si elles restent listées dans le sitemap, ce qui gaspille du budget de crawl. Enfin, si vous décidez de réparer AMP, testez chaque page avec le validator officiel avant de la remettre en production — une erreur de validation non détectée en dev peut se propager à des milliers de pages.

Comment vérifier que la transition s'est bien passée ?

Surveillez la Search Console pendant 2-3 semaines après la migration : les erreurs AMP doivent disparaître progressivement, et les 404 sur les anciennes URL AMP doivent être accompagnées de redirections 301 valides. Vérifiez aussi que votre trafic organique depuis mobile reste stable ou augmente — une chute brutale peut indiquer un problème de redirection ou de balisage canonique.

Utilisez Google Analytics pour comparer le trafic avant/après sur les URL concernées. Si vous observez une baisse de trafic depuis Discover ou Top Stories, c'est que votre version standard ne compense pas les avantages d'AMP dans ces placements — et qu'il aurait peut-être mieux valu réparer que supprimer.

• Auditez les erreurs AMP dans la Search Console et priorisez les erreurs bloquantes (balises interdites, attributs manquants).
• Décidez de réparer ou supprimer en fonction du trafic généré par AMP et de votre capacité à maintenir la validation.
• Si vous supprimez AMP, redirigez en 301 vers la version standard et mettez à jour le balisage <link rel="amphtml">.
• Soumettez un nouveau sitemap XML sans les URL AMP pour éviter le crawl inutile des anciennes pages.
• Testez chaque page réparée avec le validator AMP officiel avant remise en production.
• Surveillez les métriques Search Console et Analytics pendant 2-3 semaines post-migration pour détecter toute anomalie.