AMP n'est plus une obligation pour apparaître dans les résultats enrichis ou dans les fonctionnalités de Google Search. Il reste pourtant présent dans des parcs éditoriaux, parfois pour de bonnes raisons, parfois parce que personne n'a réévalué la double chaîne de publication. Le risque n'est pas de conserver une technologie ancienne par principe ; c'est de payer deux versions dont les contenus, le consentement ou la mesure ne racontent plus la même histoire.
Cette analyse s'adresse aux responsables SEO, produit, média et plateforme qui exploitent encore des URL AMP, préparent une refonte mobile ou cherchent à simplifier leur architecture. Elle ne pose pas « AMP ou pas AMP » comme un débat idéologique. Elle permet de décider par famille de pages, avec des preuves de trafic, de parité, de performance et de coût opérationnel.
La thèse est simple : AMP reste supporté et peut être conservé, mais il ne bénéficie pas d'un avantage automatique dans Google Search. Une page AMP doit satisfaire les mêmes exigences de contenu et d'expérience qu'une autre page, tandis qu'une présence dans un résultat enrichi n'est jamais garantie. La valeur doit donc être observée dans le service rendu, pas déduite du format.
Notre accompagnement SEO technique aide à inventorier les routes, mesurer les écarts entre versions et sécuriser une décision de maintien ou de retrait. L'objectif est une pile mobile explicable, instrumentée et soutenable, sans sacrifier une audience utile ni prolonger une dette par habitude.
Replacer AMP dans le cadre de Google en 2026
Un format encore supporté, sans privilège de classement
La documentation AMP de Google Search indique qu'une page AMP est indexée comme toute autre page et doit respecter les mêmes pratiques. Google précise également que ses systèmes n'accordent pas de préférence particulière au format. Cela exclut deux raccourcis : conserver AMP ne garantit pas une hausse de positions, et le retirer ne crée pas mécaniquement une baisse.
Ce cadrage change la question de départ. L'équipe n'a pas à prouver qu'AMP est moderne ou dépassé ; elle doit montrer qu'il rend encore un service supérieur à son coût. Ce service peut être une distribution partenaire, une version mobile réellement plus stable ou un patrimoine de liens encore actif. En revanche, le simple fait que Googlebot continue de crawler les URL n'est pas une preuve de valeur : un hit dans les logs ne démontre ni l'indexation retenue, ni la conversion, ni la préférence canonique.
Top Stories et résultats enrichis ne justifient plus seuls AMP
AMP n'est plus requis pour être éligible à Top Stories. Les pages doivent surtout respecter les règles applicables à Google News et les exigences propres aux données structurées utilisées. Une page Article valide peut néanmoins ne jamais obtenir de présentation enrichie : l'éligibilité technique autorise l'évaluation, elle ne promet pas l'affichage.
En réalité, garder une seconde pile uniquement par peur de perdre une fonctionnalité qui n'exige plus AMP augmente parfois le risque au lieu de le réduire. D'abord, l'équipe identifie les apparitions réelles et les pages concernées ; ensuite, elle vérifie que la version HTML reprend contenu, image, auteur, dates et balisage ; puis elle observe le résultat après une cohorte limitée. Si les preuves ne montrent aucun usage spécifique, le maintien doit être défendu par un autre bénéfice concret.
Pour qui AMP reste une décision active
Les cas où conserver AMP reste rationnel
Un média peut conserver AMP lorsqu'une audience significative arrive encore sur ces URL, que la parité est automatisée et que la chaîne ne ralentit pas la publication. Un distributeur peut aussi dépendre temporairement du format. Dans ces cas, la décision est locale : une version AMP stable sur le gabarit actualité n'oblige pas à l'étendre aux dossiers, comparateurs ou espaces abonnés.
Cas concret : sur un site où 22 % des sessions organiques d'actualité atteignent encore AMP et où la publication dérive du même modèle de contenu, une suppression immédiate concentre un risque inutile. Le seuil de sortie peut être fixé à zéro écart de titre, image, auteur, consentement et données structurées pendant 30 jours, puis à une migration de 10 % des routes. Si la cohorte conserve rendu, clics et revenus dans la variabilité habituelle, alors la bascule peut s'élargir.
Les cas où la double pile devient une dette
La sortie devient prioritaire lorsque les fonctionnalités divergent, que l'analytics ne rapproche plus les sessions, que les corrections doivent être développées deux fois ou que la version principale tient déjà ses objectifs de performance. Une AMP rapide mais privée de paywall, de consentement fiable ou de contenu actualisé n'est pas une optimisation : elle expose une autre expérience et fragilise la mesure.
Le coût cache se voit rarement dans une ligne budgétaire AMP. Il apparaît dans les incidents de parité, la QA dupliquée, les composants JavaScript remplacés par des variantes, les délais éditoriaux et les décisions prises sur des données incomplètes. Pour une petite équipe, deux heures de contrôle par release peuvent peser davantage qu'un gain de rendu devenu marginal. Pour une rédaction industrialisée, la même charge peut être absorbée ; le seuil dépend du rythme et du modèle de publication.
Auditer l'usage, la parité et la dette de publication
Relier chaque route AMP à sa version et à son usage
L'inventaire part des URL réellement exposées : sitemap, balises amphtml, canonicals, maillage, logs, analytics, cache CDN et backlinks connus. Pour chaque route, l'équipe enregistre le statut, la destination HTML, le gabarit, le volume utile et le propriétaire. Les URL appelées uniquement par un robot interne ne sont pas mélangées avec celles qui servent une audience ou un partenaire.
La sortie attendue est une matrice par famille, pas un total global. Elle sépare une page AMP autonome, une paire AMP/HTML et une ancienne route déjà redirigée. Elle signale les chaînes, les 404, les canonicals divergentes et les pages dont le HTML final n'est pas équivalent. Cette granularité évite de conclure « AMP représente 3 % » alors qu'une seule rubrique critique concentre presque tout l'usage résiduel.
Tester la parité éditoriale, fonctionnelle et réglementaire
La comparaison ne se limite pas au texte visible. Titre, chapô, médias, auteur, date, liens, données structurées, consentement, publicité, abonnement, analytics et accessibilité sont vérifiés. Le HTML rendu peut révéler un composant absent alors que le modèle source est commun. La QA doit donc comparer le DOM après rendu, pas seulement les données envoyées au template.
Un écart n'a pas toujours la même gravité. Une décoration différente peut être acceptée ; un lien d'abonnement, une mention légale ou une mise à jour absente bloque la décision. L'équipe qualifie chaque défaut par impact, fréquence et responsabilité. Si la même divergence revient après trois releases, alors elle n'est plus une anomalie ponctuelle : elle prouve que le contrat de parité n'est pas tenu par l'architecture actuelle.
Comparer la performance terrain sans confondre les causes
Séparer laboratoire, données terrain et qualité du parcours
Une mesure Lighthouse ponctuelle ne décrit pas l'expérience de l'ensemble des visiteurs. La décision rapproche les données terrain au 75e percentile, la distribution des appareils, le réseau, le TTFB, le rendu principal et les erreurs de parcours. AMP peut rester plus rapide sur un gabarit, mais la cause peut être un JavaScript plus sobre ou un cache plus efficace, deux propriétés que la version principale peut parfois reprendre sans conserver le format.
Le contrôle porte aussi sur la stabilité fonctionnelle. Une page qui charge vite mais perd une vidéo, un formulaire ou la mesure du consentement ne gagne pas. Inversement, une version HTML légèrement plus lente en laboratoire peut offrir une navigation plus complète et un meilleur taux de lecture. Les Core Web Vitals participent à l'évaluation ; ils ne remplacent ni l'utilité, ni l'accessibilité, ni la conversion réelle.
Comparer des cohortes équivalentes sur une fenêtre suffisante
Exemple concret : l'équipe sélectionne 200 articles de même âge, de même rubrique et de trafic comparable. Cent restent en AMP, cent passent sur le HTML canonique. Pendant 28 jours, elle suit clics, sessions, erreurs de rendu, revenus, données terrain et taux de crawl, sans modifier simultanément le template éditorial. Si la variation reste dans l'intervalle observé avant la migration, alors aucune causalité forte ne peut être attribuée au format.
Les seuils sont définis avant l'expérience. Une rupture de consentement, une perte d'une fonction critique ou une hausse durable des erreurs bloque la cohorte, même si le trafic global reste stable. Une fluctuation de position isolée ne déclenche pas seule le rollback : l'équipe vérifie d'abord canonical, indexation, disponibilité et saisonnalité. Ce faisceau empêche de transformer une corrélation de quelques jours en verdict technologique.
Décider avec une matrice de valeur et de risque
Noter les dimensions qui commandent vraiment le choix
La matrice comporte cinq axes : audience spécifique, qualité de parité, performance terrain, coût de maintenance et dépendances externes. Chaque axe reçoit une preuve, un owner et une date. Une forte audience ne suffit pas si la version est juridiquement incomplète ; un coût élevé ne suffit pas à couper une route encore distribuée par un partenaire. La décision résulte de la combinaison, jamais d'une préférence technique isolée.
Trois issues sont possibles. « Conserver » implique un contrat de parité et une CI capables d'empêcher les écarts. « Retirer » implique une destination équivalente, une trajectoire d'URL et une fenêtre de contrôle. « Réduire » maintient AMP uniquement sur les familles où sa valeur est démontrée. Cette troisième option est souvent la plus réaliste pour dissocier actualité, archives et pages interactives.
Formuler des règles qui évitent l'arbitrage au ressenti
Si une rubrique possède un partenaire encore actif, alors elle reste en maintien jusqu'à migration contractuelle. Si le coût de double QA dépasse le budget local et que le HTML tient les critères de rendu, alors la sortie devient prioritaire. Si les canonicals ou le consentement divergent, aucune extension AMP n'est autorisée avant correction. Ces règles transforment des signaux dispersés en décisions opposables.
- Conserver lorsque l'usage spécifique est mesuré, la parité automatisée et le run soutenable.
- Réduire lorsque seules certaines familles ou distributions retirent encore une valeur prouvée du format.
- Retirer lorsque la version HTML rend le même service et que la double maintenance crée plus de défauts qu'elle n'en évite.
- Reporter lorsque la destination, les redirections ou la mesure ne permettent pas encore une reprise sûre.
La matrice est revue à chaque changement majeur de CMS, de paywall ou de distribution. Elle n'a pas vocation à produire un score décoratif. Elle doit expliquer pourquoi une route reste, qui la possède et quelle condition permettra de fermer l'exception. Sans date de réexamen, un maintien temporaire redevient vite une dette silencieuse.
Plan d'action : conserver ou sortir sans rupture
Industrialiser la conservation plutôt que tolérer deux versions
Si AMP reste, l'entrée du workflow est un modèle éditorial unique et la sortie est une paire de pages dont le contenu, les données structurées et la mesure sont cohérents. L'owner produit possède la parité fonctionnelle ; la plateforme possède le rendu et le cache ; le SEO contrôle canonical, crawl et indexation ; la conformité valide consentement et publicité. La CI compare les champs obligatoires et refuse une publication quand le contrat est rompu.
L'instrumentation relie chaque défaut au gabarit et à la release. Un monitoring synthétique rejoue les routes critiques, tandis que les logs distinguent Googlebot, utilisateurs et partenaires. Le runbook précise le seuil d'alerte, la responsabilité, le repli et le délai de correction. Conserver AMP devient alors une capacité opérée, pas une pile secondaire que l'on découvre seulement lorsqu'un contenu manque.
Migrer par famille avec une reprise préparée
D'abord, la version HTML reprend contenu, métadonnées, données structurées, analytics et fonctions. Ensuite, une cohorte retire le lien amphtml et aligne les canonicals ; les anciennes URL AMP rejoignent leur équivalent pertinent selon l'architecture retenue. Puis l'équipe met à jour sitemap, maillage, flux et caches, sans renvoyer toutes les routes vers une page générique.
Le rollback est préparé avant le déploiement : liste des routes, configuration précédente, preuve de parité et fenêtre de reprise. Si un partenaire échoue ou qu'une fonction critique disparaît, alors la cohorte revient au palier documenté ; l'incident est corrigé sans réactiver aveuglément tout le parc. Cette responsabilité et cette traçabilité évitent une migration globale dont personne ne peut isoler la cause.
La fermeture intervient seulement après plusieurs cycles de crawl et de trafic. Les logs ne doivent plus montrer d'appels internes vers AMP, les redirections doivent rester directes, et Google doit pouvoir explorer la destination. Le délai exact dépend du volume et de la fréquence de recrawl ; aucune durée universelle ne garantit la consolidation. L'équipe conserve les redirections pertinentes et continue le monitoring au-delà de la fin du projet.
Erreurs fréquentes autour d'AMP
Promettre un gain ou une absence de risque
La première erreur consiste à vendre AMP comme un bonus de classement. Google n'annonce aucun traitement préférentiel du format, et l'éligibilité à une présentation ne garantit pas son affichage. L'erreur inverse consiste à promettre qu'une suppression est neutre parce qu'AMP n'est plus requis. Une mauvaise migration peut casser une route, une canonical, une distribution ou une expérience encore utilisée.
La deuxième erreur est de choisir à partir d'une moyenne. Une audience AMP faible au niveau du site peut rester décisive sur l'actualité chaude ; une excellente performance médiane peut masquer une fonction absente. Le diagnostic garde les familles séparées et qualifie les cas extrêmes. C'est dans ces écarts que se trouvent les incidents coûteux, pas dans le chiffre global le plus rassurant.
Couper les signaux avant d'avoir stabilisé la destination
Retirer amphtml, changer la canonical et rediriger dans la même release sans cohorte rend la cause illisible. Une destination lente, un balisage incomplet ou un cache mal invalidé apparaît alors en même temps que la nouvelle trajectoire d'URL. Le bon ordre consiste à stabiliser le HTML, prouver la parité, puis modifier les signaux et observer.
Bloquer les anciennes routes via robots.txt est également contre-productif si Google doit encore lire une redirection ou un changement de canonical. Le crawl doit rester possible pendant la consolidation. Enfin, supprimer les logs et tableaux de bord dès la bascule retire précisément la preuve nécessaire pour comprendre les appels résiduels. La reprise exige de garder la mémoire de l'ancien système assez longtemps.
Relier AMP aux chantiers mobile et performance
Partir des règles actuelles plutôt que d'un souvenir du format
La source principale reste la documentation Google sur les pages AMP dans Google Search. Elle couvre les paires AMP/non-AMP, les pages autonomes, les données structurées et le comportement d'indexation. La documentation des données structurées Article rappelle séparément que le balisage peut rendre une page éligible, sans garantir de résultat enrichi.
Ces sources doivent être relues au moment de la décision, car l'écosystème évolue. Elles ne remplacent cependant pas les données du site. Un document officiel décrit les règles de Search ; seuls les logs, l'analytics, le terrain et la QA montrent si une rubrique dépend encore de la route AMP et si la destination rend le même service.
Poursuivre par le rendu mobile et les signaux terrain
L'analyse de la navigation mobile et de son impact sur le crawl aide à contrôler ce que Googlebot atteint réellement dans le rendu mobile. Le travail sur le monitoring des Core Web Vitals fournit le cadre terrain pour comparer les cohortes sans confondre laboratoire et expérience agrégée.
Ces chantiers sont complémentaires. L'indexation mobile vérifie le contenu et les signaux accessibles ; les données terrain décrivent l'expérience ; l'audit AMP mesure le coût et la parité. Aucun indicateur ne remplace les deux autres. Une décision robuste relie les trois, puis consigne les hypothèses qui restent encore non vérifiées.
Conclusion : choisir la pile mobile la plus fiable
AMP reste une technologie supportée, mais son utilité en 2026 ne se déduit ni de son histoire ni d'une promesse SEO. Elle se démontre par une audience, une distribution, une performance ou une capacité de publication qui conserve plus de valeur que la double pile n'ajoute de dette.
La bonne décision peut différer selon les gabarits. Conserver l'actualité, retirer les archives et reconstruire les pages interactives est parfois plus défendable qu'un verdict uniforme. La matrice rend ces différences explicites et impose une date aux exceptions.
Une sortie réussie protège la destination avant de modifier les signaux, avance par cohorte et maintient assez longtemps les redirections, les logs et le monitoring. Une conservation réussie automatise la parité et attribue chaque défaut. Dans les deux cas, la qualité vient de l'exploitation, pas du nom du format.
Pour qualifier les familles, instrumenter les preuves et piloter une migration réversible, l'accompagnement SEO technique de Dawap relie architecture, performance mobile, indexation et run dans une même décision opérationnelle.
