AMP en 2026 : faut-il garder ou supprimer ses pages AMP ?

AMP ne fait plus gagner de position dans les résultats de recherche, et ce n'est pas une nouveauté : Google a détaché l'accès au carrousel Top Stories du format AMP dès 2021, puis a généralisé les critères de vitesse via les Core Web Vitals à toutes les pages, AMP ou pas. La vraie question, en 2026, n'est donc plus « est-ce que je perds du trafic si je retire AMP ? » mais « ai-je encore une raison technique de maintenir un second gabarit de page, et si non, comment le retirer sans casser ce qui est déjà indexé ? »

Cet article répond aux deux volets de cette question : ce qu'AMP apporte réellement, ou n'apporte plus, au référencement aujourd'hui, puis la séquence de retrait à suivre pas à pas — redirections, bascule de la balise canonique, et vérifications dans Search Console — pour les sites qui ont déjà tranché et veulent le faire proprement.

Pourquoi AMP est encore présent sur tant de sites

AMP (Accelerated Mobile Pages) est né en 2015 d'un constat simple : les pages mobiles des sites d'actualité et de contenu étaient trop lourdes, et Google a proposé un format HTML restreint, mis en cache sur son propre réseau, pour garantir un chargement quasi instantané. En échange de contraintes strictes — JavaScript interdit sauf composants AMP officiels, CSS inline limité, images passant obligatoirement par la balise amp-img — les pages AMP obtenaient un badge distinctif dans les résultats mobiles et, pour les éditeurs d'actualité, l'accès au carrousel Top Stories.

Beaucoup de sites l'ont adopté à cette période, souvent via un plugin (une extension AMP pour WordPress, par exemple) générant automatiquement une version /amp/ de chaque page existante. Neuf ou dix ans plus tard, ce gabarit tourne toujours en arrière-plan sur des milliers d'installations, fréquemment sans que personne dans l'équipe actuelle ne sache précisément pourquoi il a été mis en place, ni s'il rend encore un service quelconque.

AMP apporte-t-il encore un avantage dans les résultats de recherche ?

Non, pas directement. Depuis juin 2021, le carrousel Top Stories ne nécessite plus AMP, et le badge visuel associé a disparu des résultats à peu près à la même période. Depuis, une page AMP et une page HTML classique sont évaluées avec les mêmes critères : pertinence du contenu, expérience de page, et vitesse mesurée par les Core Web Vitals (LCP, INP, CLS) sur des données de champ, c'est-à-dire les vraies visites d'utilisateurs réels, pas un environnement de test en laboratoire.

Ce qu'AMP imposait auparavant — forcer une page légère par contrainte de format — est donc devenu un moyen parmi d'autres d'atteindre un objectif de vitesse, plus une exigence en soi. Une page en HTML classique, correctement optimisée (images dimensionnées et chargées en différé, CSS critique en ligne, scripts tiers limités et chargés de façon asynchrone), peut obtenir un LCP et un INP tout aussi bons qu'une page AMP, sans les contraintes du format. Dans ce cas précis, AMP n'apporte plus rien que la version standard n'obtiendrait pas autrement, par un autre chemin technique.

Il reste toutefois une nuance à connaître. La mise en cache AMP côté Google (l'AMP Cache) servait historiquement les pages depuis des serveurs proches géographiquement de l'utilisateur, ce qui pouvait aider sur des réseaux mobiles lents ou dans des zones mal desservies par un CDN classique. Si votre audience se trouve majoritairement sur des connexions rapides et que votre hébergement dispose déjà d'un CDN correctement configuré, cet avantage résiduel est nul aujourd'hui. S'il vous reste un lectorat significatif sur des réseaux mobiles de qualité irrégulière, l'écart peut encore exister dans certains cas, mais il tient alors à une différence d'infrastructure de diffusion, pas à un traitement préférentiel accordé par Google au format AMP lui-même.

Les signes qu'il est temps de retirer AMP

Plusieurs signaux, pris ensemble plutôt qu'isolément, indiquent qu'AMP est devenu un coût sans contrepartie réelle pour un site donné :

• Les pages non-AMP passent déjà les Core Web Vitals dans le rapport « Signaux web essentiels » de Search Console : le gabarit AMP ne compense plus une faiblesse de performance réelle sur la version standard.
• L'équipe technique maintient deux versions de chaque modèle de page, et chaque nouvelle fonctionnalité — un bloc d'avis clients, un lecteur vidéo, un test A/B — doit être adaptée ou explicitement exclue du gabarit AMP à cause de ses restrictions sur le JavaScript.
• Le trafic organique vers les URLs en /amp/, visible en filtrant par page dans le rapport Performances de Search Console, représente une part marginale et déclinante du trafic mobile total du site.
• Le plugin ou le générateur AMP n'a pas reçu de mise à jour depuis longtemps, entre en conflit avec d'autres extensions du site, et personne dans l'équipe actuelle ne sait précisément ce qu'il produit ni comment il est configuré.
• L'équipe monétisation ou les annonceurs signalent un rendu publicitaire dégradé sur les pages AMP par rapport à la version standard du même contenu.

Les cas où garder AMP a encore du sens

Retirer AMP n'est pas non plus une évidence universelle applicable à tous les sites de la même façon. Quelques configurations justifient encore de le conserver, au moins pour le moment présent :

• Un site d'actualité à très fort volume de publication, où la version AMP reste largement utilisée par des lecteurs qui arrivent via des applications tierces (agrégateurs de flux, certaines applications d'actualité mobiles) pointant spécifiquement vers les URLs AMP existantes.
• Une plateforme dont l'équipe technique est réduite, dont le site AMP fonctionne sans incident depuis des années sans nécessiter d'intervention, et où le temps de migration serait objectivement mieux investi ailleurs — retirer AMP a un coût réel de projet, pas seulement un coût de maintenance qu'on pourrait ignorer.
• Un cas où les pages standard n'ont, en pratique, jamais réussi à passer les Core Web Vitals malgré plusieurs tentatives d'optimisation sérieuses, et où AMP sert temporairement de filet de sécurité en attendant un chantier de performance plus large sur le reste du site.

Le plan de retrait, étape par étape

Le retrait d'AMP casse rarement quelque chose parce qu'AMP est supprimé en soi, mais presque toujours parce que l'ordre des opérations a été inversé. La séquence suivante évite les cas les plus fréquents de liens morts et de contenu dupliqué mal signalé après coup.

Un point technique souvent oublié dans ce processus : l'AMP Cache de Google conserve les versions qu'il a mises en cache selon ses propres cycles de rafraîchissement internes, pas sur demande explicite du site concerné. Il n'existe pas d'outil public permettant à un éditeur de purger cette cache instantanément ; une fois la redirection en place, l'ancienne version cachée disparaît progressivement au fil des prochains passages du robot d'indexation, ce qui prend généralement de quelques jours à deux ou trois semaines selon la fréquence de crawl habituelle du site concerné.

• Faire l'inventaire complet des URLs AMP existantes : sitemap AMP dédié s'il en existe un, crawl du site en filtrant les URLs contenant /amp/ ou le paramètre ?amp, et rapport « Pages » de Search Console pour repérer précisément celles qui sont indexées à ce jour.
• Identifier le modèle technique en place : AMP « pairée », où une URL AMP distincte est reliée à la page standard par une balise rel="amphtml" placée sur la page standard et une balise canonical placée sur la page AMP, ou AMP comme seule version existante d'une page donnée. Ce second cas, plus rare aujourd'hui, demande de recréer une version standard avant toute suppression.
• Retirer les balises rel="amphtml" des pages standard en premier, pour arrêter d'annoncer publiquement une version AMP qui va disparaître, et cela avant de toucher aux URLs AMP elles-mêmes.
• Mettre en place des redirections 301, une par une, de chaque URL AMP vers sa page standard équivalente exacte — jamais vers la page d'accueil ou vers une page de catégorie générique, qui serait traitée comme une redirection peu pertinente plutôt que comme la continuation logique et directe de la page d'origine.
• Vérifier que chaque page standard porte une balise canonical qui se référence elle-même correctement, sans trace résiduelle pointant encore vers une ancienne URL AMP.
• Ne désactiver le plugin ou le générateur AMP qu'une fois les redirections en place et vérifiées une par une, jamais avant : le désactiver en premier transforme immédiatement toutes les URLs AMP en erreurs 404 non contrôlées, plutôt qu'en redirections propres et maîtrisées.
• Mettre à jour le sitemap XML pour qu'il ne liste plus aucune URL AMP, puis soumettre ce sitemap actualisé dans Search Console pour accélérer la découverte du changement.

Ce qu'il faut vérifier dans Search Console après la bascule

Une fois AMP retiré, le rapport AMP de Search Console ne vous apprend plus grand-chose ; le suivi se fait avec les outils génériques de l'interface, mais de façon tout aussi précise si l'on sait précisément où regarder.

• L'outil d'inspection d'URL, testé sur une ancienne URL AMP précise : il doit indiquer qu'elle redirige bien vers l'URL canonique attendue, et que celle-ci est elle-même correctement indexée. Une URL AMP encore signalée comme « indexée » plusieurs semaines après la mise en place de la redirection mérite d'être testée à nouveau après une demande d'exploration manuelle.
• Le rapport « Pages » (anciennement nommé Couverture) : surveiller la catégorie des URLs redirigées pour confirmer qu'elles y apparaissent bien comme telles, et non comme des erreurs 404 isolées ou comme des doublons sans URL canonique désignée par le site.
• Le rapport Performances, filtré page par page : dans les semaines suivant la bascule, les clics et impressions des anciennes URLs AMP doivent décroître progressivement pendant que ceux des URLs standard équivalentes augmentent d'autant — un transfert normal, pas une perte nette de visibilité. Une baisse du total combiné des deux séries, observée sur plusieurs semaines, est le seul signal qui justifie une investigation plus poussée du problème.
• Le rapport Signaux web essentiels : comparer les données de champ des pages standard avant et après la période de retrait, pour confirmer qu'elles maintiennent, ou idéalement améliorent, les scores que la version AMP obtenait auparavant sur le même contenu.
• Le rapport Sitemaps : vérifier qu'aucune erreur nouvelle n'apparaît sur le sitemap mis à jour, et que le nombre d'URLs découvertes correspond bien à ce qui est attendu une fois les entrées AMP retirées de la liste.

Les erreurs qui transforment un retrait simple en incident SEO

La plupart des problèmes rencontrés après un retrait d'AMP viennent d'un désordre dans l'ordre des étapes suivies, plutôt que d'une décision de fond réellement discutable.

• Désactiver le plugin AMP avant d'avoir mis en place les redirections correspondantes : chaque URL AMP renvoie alors une erreur 404 brute, y compris pour les visiteurs arrivant depuis des liens externes anciens ou des favoris déjà enregistrés et indexés.
• Rediriger l'ensemble des URLs AMP vers l'URL racine du site plutôt que vers la page standard réellement correspondante : Google traite ce schéma comme un signal de mauvaise qualité de la redirection, proche d'une redirection générique non pertinente, et le contenu de la page perdue n'est transmis à aucune page réellement pertinente.
• Oublier des annotations liées à AMP présentes dans les données structurées ou dans d'autres flux annexes (RSS, flux d'actualités spécifiques) qui référençaient encore l'ancienne URL, laissant des liens internes ou externes pointer vers une impasse technique.
• Supprimer les balises canonical en même temps que les balises AMP, sans vérifier qu'il en reste une valide et auto-référente sur chaque page standard restante — un oubli qui peut créer un nouveau problème de contenu dupliqué sans URL canonique désignée, totalement indépendant d'AMP à l'origine.
• S'attendre à une bascule immédiate et visible dans les résultats de recherche : Google doit recrawler et retraiter chaque URL individuellement, et le remplacement complet d'un jeu d'URLs par un autre dans l'index s'étale généralement sur plusieurs semaines, jamais sur quelques jours seulement.