AMP est mort : migrer vos pages AMP sans perdre de trafic

Google a retiré l'avantage AMP du carrousel Top Stories en juin 2021. Depuis, le cache AMP de Google a été déprécié, et les Core Web Vitals sont devenus le vrai signal de performance mobile. Pourtant, des milliers de sites traînent encore des pages AMP fantômes — avec leurs canonicals croisés, leur markup dupliqué et leur dette technique silencieuse.

Si vous êtes dans ce cas, chaque jour qui passe aggrave la situation : crawl budget gaspillé, contenu dupliqué latent, et une infrastructure que plus personne ne maintient. Voici comment démanteler proprement votre implémentation AMP.

L'état des lieux : pourquoi AMP ne sert plus à rien en 2026

AMP (Accelerated Mobile Pages) reposait sur un deal implicite : vous acceptiez les contraintes du framework (JavaScript limité, composants propriétaires, hébergement sur le cache Google) en échange d'un placement privilégié dans les résultats mobiles. Ce deal n'existe plus.

La chronologie de la dépréciation

Juin 2021 : Google ouvre le carrousel Top Stories à toutes les pages, AMP ou non. Le seul avantage concurrentiel d'AMP disparaît.
Novembre 2022 : Google annonce la fin du cache AMP. Les pages AMP ne sont plus servies depuis cdn.ampproject.org mais depuis votre propre serveur.
2023-2024 : les Core Web Vitals (LCP, INP, CLS) deviennent le signal de performance réel. AMP ne garantit plus de meilleur score qu'une page classique bien optimisée.
2025 : le projet AMP est en maintenance minimale. La plupart des éditeurs majeurs (Washington Post, BBC) ont terminé leur démantèlement.

Ce que vos pages AMP vous coûtent encore

Le problème n'est pas qu'AMP "ne sert plus". C'est qu'AMP vous coûte activement :

Crawl budget : chaque article qui existe en version AMP (/article/amp/) et en version classique (/article/) double le nombre d'URLs à crawler. Sur un média de 20 000 articles, ça représente 20 000 URLs supplémentaires que Googlebot doit visiter, évaluer et indexer — ou ignorer. L'analyse des logs serveur montre souvent que Googlebot continue de crawler ces pages AMP des mois après qu'elles ont perdu tout intérêt.

Contenu dupliqué : la relation <link rel="amphtml"> / <link rel="canonical"> entre vos pages classiques et AMP crée un lien de dépendance bidirectionnel. Si un des deux côtés casse (erreur 404 sur la version AMP, canonical mal configuré), vous entrez dans un scénario de contenu dupliqué que Google peut mettre des semaines à résoudre.

Dette de maintenance : le markup AMP utilise des composants spécifiques (<amp-img>, <amp-carousel>, <amp-analytics>) qui nécessitent un pipeline de build séparé. Chaque modification du template principal doit être répliquée dans le template AMP. Vos développeurs passent du temps sur un format mort.

Audit préalable : cartographier votre surface AMP

Avant de toucher à quoi que ce soit, vous devez connaître l'étendue exacte de votre implémentation AMP. Une migration à l'aveugle est le meilleur moyen de provoquer une régression SEO majeure.

Identifier toutes les URLs AMP

Lancez un crawl Screaming Frog en ciblant spécifiquement les patterns AMP. La plupart des implémentations suivent l'un de ces schémas :

/article-slug/amp/ (suffixe)
/amp/article-slug/ (préfixe)
m.example.com/article-slug (sous-domaine mobile avec AMP intégré)
Paramètre ?amp=1

Dans Screaming Frog, configurez un crawl avec extraction personnalisée :

Configuration > Custom Extraction > Add:
- Name: "AMP HTML tag"
  Regex: <html[^>]*(\samp|\s⚡)[^>]*>
  Extract: Inner HTML (first match)

- Name: "AMP Canonical"  
  XPath: //link[@rel='canonical']/@href
  Extract: Attribute value

- Name: "AmpHTML reference"
  XPath: //link[@rel='amphtml']/@href
  Extract: Attribute value

Exportez les résultats. Vous obtenez deux datasets essentiels :

Pages classiques qui pointent vers une version AMP (celles qui ont un <link rel="amphtml">)
Pages AMP elles-mêmes (celles dont le <html> contient l'attribut amp ou ⚡)

Vérifier l'état d'indexation dans Search Console

Dans Google Search Console, allez dans Pages > Pourquoi les pages ne sont-elles pas indexées. Filtrez par URL contenant /amp/ (ou votre pattern). Vous verrez probablement un mélange de :

Pages AMP indexées avec un canonical correct vers la version classique
Pages AMP indexées comme canonical d'elles-mêmes (problème)
Pages AMP en erreur (validation AMP échouée)
Pages AMP exclues ("Page avec redirection", "Autre page avec canonical correcte")

Les rapports souvent ignorés de Search Console contiennent ces informations. Le rapport "Pages" avec le filtre d'URL est votre point de départ.

Mesurer le trafic résiduel

Vérifiez dans Google Analytics (ou votre outil d'analytics) le trafic organique qui arrive encore sur les URLs AMP. Sur beaucoup de sites, ce trafic est proche de zéro depuis la fin du cache AMP. Mais sur certains médias, des pages AMP bien positionnées captent encore du trafic — c'est ces URLs-là qu'il faudra traiter en priorité.

Scénario concret : migration AMP d'un média de 18 000 articles

Prenons un cas réel typique : un média d'information avec 18 000 articles publiés entre 2017 et 2023. Chaque article existe en deux versions — classique et AMP — soit 36 000 URLs au total. Le site tourne sur un CMS headless avec un front Next.js.

Données initiales

18 200 pages AMP crawlées par Screaming Frog
14 800 correctement indexées avec canonical vers la version classique
2 100 indexées comme canonical d'elles-mêmes (erreur de configuration)
1 300 en erreur 404 ou soft 404
Trafic organique sur les URLs AMP : 3 200 sessions/mois (2,1% du trafic total)
Crawl budget consommé par les URLs AMP : environ 22% des requêtes Googlebot d'après l'analyse des logs

Objectifs de la migration

Supprimer toutes les pages AMP
Rediriger proprement chaque URL AMP vers sa version classique
Nettoyer les balises <link rel="amphtml"> des pages classiques
Récupérer 22% de crawl budget
Perte de trafic cible : < 5% sur les 3 200 sessions/mois impactées

Planning d'exécution

Semaine 1 : audit + préparation des redirections + tests sur staging Semaine 2 : déploiement des redirections + suppression du <link rel="amphtml"> Semaine 3-4 : monitoring + traitement des erreurs résiduelles Semaine 5-8 : stabilisation + nettoyage du sitemap + suivi Search Console

La durée totale peut sembler longue pour "juste des redirections", mais l'expérience montre que les déploiements précipités causent des catastrophes SEO. Prenez le temps.

Mise en place des redirections 301

C'est le cœur technique de la migration. Chaque URL AMP doit retourner une redirection 301 permanente vers la version classique correspondante.

Configuration Nginx

Si vos URLs AMP suivent le pattern /article-slug/amp/, la règle Nginx est directe :

server {
    listen 443 ssl http2;
    server_name www.example-media.fr;

    # Redirection des URLs AMP suffixées
    # /mon-article/amp/ → /mon-article/
    # /mon-article/amp  → /mon-article/
    location ~ ^(/.*?)/(amp)/?$ {
        return 301 $1/;
    }

    # Redirection des URLs AMP préfixées
    # /amp/mon-article/ → /mon-article/
    location ~ ^/amp(/.*) {
        return 301 $1;
    }

    # Gestion du paramètre ?amp=1
    if ($arg_amp = "1") {
        rewrite ^(.*)$ $1? permanent;
    }

    # Le reste de votre configuration...
}

Quelques points critiques :

Testez chaque pattern de regex sur regex101.com avec vos URLs réelles avant de déployer.
La redirection doit retourner un code 301, pas 302. Un 302 dit à Google que la page AMP pourrait revenir. Un 301 dit que c'est définitif.
Si vous utilisez un CDN devant Nginx (Varnish, Cloudflare, etc.), vérifiez que le CDN ne cache pas les anciennes réponses 200 des pages AMP. Purgez le cache du CDN après déploiement.

Configuration Apache

L'équivalent en .htaccess :

RewriteEngine On

# /mon-article/amp/ → /mon-article/
RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]

# /amp/mon-article/ → /mon-article/
RewriteRule ^amp/(.+)$ /$1 [R=301,L]

# Paramètre ?amp=1
RewriteCond %{QUERY_STRING} (^|&)amp=1(&|$)
RewriteRule ^(.*)$ /$1? [R=301,L]

Vérification des redirections

Avant de considérer les redirections comme opérationnelles, validez avec cURL sur un échantillon de 50-100 URLs :

# Vérification unitaire
curl -I -L "https://www.example-media.fr/politique/reforme-2024/amp/"

# Vérification en masse depuis un fichier d'URLs AMP
while IFS= read -r url; do
    status=$(curl -o /dev/null -s -w "%{http_code}" -I "$url")
    final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$url")
    echo "$status | $url → $final"
done < amp-urls.txt | tee redirect-audit.log

# Filtrer les redirections qui ne retournent pas 301
grep -v "^301" redirect-audit.log

Tout ce qui ne retourne pas un 301 propre vers la bonne URL classique doit être investigué. Les cas problématiques courants : chaînes de redirections (AMP → ancienne URL → nouvelle URL), redirections vers la homepage (catch-all mal configuré), et boucles de redirection.

Nettoyage du markup HTML

Les redirections seules ne suffisent pas. Vous devez nettoyer le HTML de vos pages classiques pour supprimer toute référence à AMP.

Supprimer les balises `<link rel="amphtml">`

Chaque page classique qui avait une version AMP contient quelque chose comme :

<head>
    <!-- AVANT : à supprimer -->
    <link rel="amphtml" href="https://www.example-media.fr/politique/reforme-2024/amp/">
    
    <!-- À conserver tel quel -->
    <link rel="canonical" href="https://www.example-media.fr/politique/reforme-2024/">
</head>

La balise <link rel="amphtml"> doit être retirée. Si elle pointe vers une URL qui redirige en 301, Google finira par comprendre — mais c'est un signal confus qui ralentit la transition. Un signal propre = une transition rapide.

Sur un CMS headless avec un front Next.js, la modification est souvent dans le composant <Head> :

// components/ArticleHead.tsx — AVANT
import Head from 'next/head';

interface ArticleHeadProps {
  article: {
    slug: string;
    title: string;
    description: string;
    canonicalUrl: string;
  };
}

export function ArticleHead({ article }: ArticleHeadProps) {
  return (
    <Head>
      <title>{article.title}</title>
      <meta name="description" content={article.description} />
      <link rel="canonical" href={article.canonicalUrl} />
      {/* SUPPRIMER cette ligne : */}
      <link rel="amphtml" href={`${article.canonicalUrl}amp/`} />
    </Head>
  );
}

// components/ArticleHead.tsx — APRÈS
export function ArticleHead({ article }: ArticleHeadProps) {
  return (
    <Head>
      <title>{article.title}</title>
      <meta name="description" content={article.description} />
      <link rel="canonical" href={article.canonicalUrl} />
      {/* Plus de référence AMP */}
    </Head>
  );
}

Si vous utilisez un CMS comme WordPress avec un plugin AMP (AMP for WordPress, par exemple), la désactivation du plugin devrait supprimer automatiquement la balise amphtml. Mais vérifiez — certains plugins laissent des résidus dans le HTML même après désactivation. Inspectez le source HTML d'au moins 10 pages après désactivation.

Nettoyer le sitemap

Votre sitemap XML contient probablement les URLs AMP. Deux approches :

Si les URLs AMP avaient leur propre sitemap (sitemap-amp.xml) : supprimez le fichier et retirez-le du sitemap-index.xml.
Si les URLs AMP étaient mélangées dans le sitemap principal : regénérez le sitemap sans les URLs AMP.

Dans les deux cas, ne laissez jamais des URLs qui redirigent dans votre sitemap. Google interprète un sitemap comme une déclaration de vos URLs canoniques actives. Y laisser des URLs 301 envoie un signal contradictoire.

Après nettoyage, soumettez le sitemap mis à jour dans Search Console.

Supprimer le code AMP du build

Si votre projet contenait un pipeline de génération des pages AMP (templates AMP, composants <amp-*>, validation AMP dans le CI), supprimez tout. Ce code mort est une source de confusion pour les nouveaux développeurs et un vecteur de bugs si quelqu'un le réactive par erreur.

Intégrez un check dans votre CI/CD qui vérifie l'absence de balises AMP dans le HTML généré :

# check-no-amp.sh — à intégrer dans votre pipeline CI
#!/bin/bash
set -e

BUILD_DIR="./out"  # ou .next, dist, etc.
AMP_FOUND=0

# Chercher les attributs AMP dans les fichiers HTML générés
while IFS= read -r file; do
    if grep -qiE '<html[^>]*([\s]amp[\s>]|[\s]⚡)' "$file"; then
        echo "ERREUR: attribut AMP trouvé dans $file"
        AMP_FOUND=1
    fi
    if grep -qiE 'rel="amphtml"' "$file"; then
        echo "ERREUR: lien amphtml trouvé dans $file"
        AMP_FOUND=1
    fi
done < <(find "$BUILD_DIR" -name "*.html" -type f)

if [ "$AMP_FOUND" -eq 1 ]; then
    echo "❌ Des résidus AMP ont été détectés. Migration incomplète."
    exit 1
else
    echo "✅ Aucun résidu AMP détecté."
fi

Performance des pages classiques : combler le gap

AMP avait un avantage réel : ses contraintes forçaient des pages légères. Quand vous redirigez une page AMP (< 100 KB, rendu quasi-instantané) vers une page classique qui charge 3 MB de JavaScript, vous allez perdre en Core Web Vitals.

Auditer les Core Web Vitals de vos pages de destination

Utilisez Chrome DevTools en mode mobile (Lighthouse, onglet Performance) sur un échantillon de vos pages classiques. Les métriques clés :

LCP (Largest Contentful Paint) : doit être < 2,5s. Si vos pages classiques ont un LCP > 4s, vous allez sentir l'impact de la migration.
INP (Interaction to Next Paint) : doit être < 200ms. Si votre page classique charge un framework JS lourd avec hydration côté client, l'INP peut exploser.
CLS (Cumulative Layout Shift) : doit être < 0,1. Les pubs display et les images sans dimensions explicites sont les coupables habituels.

Si vos pages classiques sont des SPA rendues côté client, vous avez un problème plus profond que la migration AMP. Googlebot peut interpréter le JavaScript, mais les divergences entre SSR et CSR créent des comportements imprévisibles. Migrer vers du SSR ou SSG devrait être une priorité parallèle.

Quick wins performance

Quelques optimisations rapides qui rapprochent vos pages classiques des performances qu'avait AMP :

Lazy loading natif sur les images — AMP le faisait par défaut avec <amp-img>. Vos pages classiques doivent utiliser loading="lazy" sur toutes les images hors viewport initial :

<!-- Image dans le viewport initial (hero) : pas de lazy loading -->
<img src="/images/article-hero.webp" 
     alt="Titre de l'article" 
     width="1200" 
     height="630"
     fetchpriority="high">

<!-- Images dans le corps de l'article : lazy loading -->
<img src="/images/infographie-donnees.webp" 
     alt="Infographie des données" 
     width="800" 
     height="450" 
     loading="lazy" 
     decoding="async">

Préchargement du LCP — identifiez l'élément LCP de vos articles (souvent l'image hero ou le premier paragraphe) et ajoutez un <link rel="preload"> dans le <head> :

<link rel="preload" as="image" href="/images/article-hero.webp" fetchpriority="high">

Réduction du JS bloquant — AMP interdisait le JavaScript custom. Vos pages classiques chargent probablement des trackers, des widgets sociaux, des scripts pub. Chaque script bloquant ajoute au LCP. Auditez avec Performance Insights dans Chrome DevTools et différez tout ce qui n'est pas critique au rendu initial.

Monitoring post-migration : les 8 semaines critiques

Les deux premiers mois après la migration sont la période à risque. Les problèmes ne sont pas toujours visibles immédiatement — certaines régressions mettent 2-3 semaines à se manifester dans les données Search Console.

Semaine 1-2 : vérifier les redirections

Surveillez dans Search Console le rapport Pages filtré par URL AMP. Vous devriez voir les URLs AMP migrer progressivement du statut "Page indexée" vers "Page avec redirection". Si certaines URLs AMP restent indexées sans redirection, il y a un trou dans votre configuration.

Dans vos logs serveur, vérifiez que Googlebot suit bien les redirections 301 :

# Extraire les requêtes Googlebot sur les URLs AMP depuis les access logs
grep "Googlebot" /var/log/nginx/access.log | grep -E "/amp/|/amp$|\?amp=1" | \
    awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -20

Vous devez voir des 301 en masse. Si vous voyez des 200 (la page AMP est encore servie) ou des 404, corrigez immédiatement.

Semaine 3-4 : surveiller les fluctuations de trafic

Comparez le trafic organique semaine par semaine sur les URLs impactées. Une baisse de 10-15% la première semaine est normale — Google recrawle et réévalue les pages. Si la baisse persiste au-delà de 3 semaines ou dépasse 20%, investiguez :

Les pages classiques sont-elles bien indexées ?
Les Core Web Vitals des pages classiques sont-ils corrects ?
Y a-t-il des erreurs de crawl dans Search Console ?

Semaine 5-8 : confirmer la stabilisation

Le trafic devrait se stabiliser, voire augmenter légèrement grâce au crawl budget récupéré. Dans notre scénario de média à 18 000 articles, la récupération de 22% de crawl budget signifie que Googlebot peut découvrir et réindexer plus rapidement les nouveaux contenus.

Un outil de monitoring SEO continu comme Seogard détecte automatiquement les régressions pendant cette période critique : apparition soudaine de 404 sur les anciennes URLs AMP, réapparition de balises amphtml après un déploiement, ou dégradation des Core Web Vitals sur les pages de destination.

Signaux de succès

Votre migration AMP est réussie quand :

Zéro URL AMP dans l'index Google (vérifiable via Search Console > Pages, filtre URL)
Trafic organique sur les pages impactées revenu au niveau pré-migration (± 5%)
Crawl budget AMP tombé à zéro dans les logs serveur
Aucune balise amphtml dans le HTML de votre site (vérifiable via le check CI décrit plus haut)
Core Web Vitals des pages classiques dans le vert pour mobile

Edge cases et pièges fréquents

Pages AMP sans équivalent classique

Certains sites ont créé des pages AMP qui n'ont pas de version classique correspondante — souvent des landing pages AMP Stories ou des pages de test oubliées. Pour celles-ci, deux options :

La page a du trafic/des backlinks : créez une version classique, puis redirigez l'URL AMP vers cette nouvelle page.
La page n'a ni trafic ni backlinks : renvoyez un 410 (Gone) plutôt qu'un 404. Le 410 dit explicitement à Google que la page a été volontairement supprimée.

Backlinks pointant vers des URLs AMP

Des sites externes pointent peut-être directement vers vos URLs AMP. La redirection 301 transfère l'essentiel du link equity, mais vérifiez avec Ahrefs, Majestic ou Search Console (Liens > Liens externes) les backlinks les plus importants pointant vers des URLs AMP. Si un backlink de forte autorité pointe vers une URL AMP, assurez-vous que la chaîne de redirection est propre (un seul hop, pas de 302 intermédiaire).

AMP sur des sous-domaines

Si votre implémentation AMP utilisait un sous-domaine (amp.example.com), la migration est plus complexe. Les redirections doivent être cross-domain, et vous devez maintenir le sous-domaine actif uniquement pour servir les 301. Ne supprimez pas le DNS du sous-domaine tant que Google n'a pas fini de recrawler toutes les URLs — comptez 3-6 mois selon le volume.

Pages AMP dans le cache de services tiers

Certains agrégateurs (Flipboard, Apple News, etc.) peuvent avoir mis en cache vos pages AMP. Les redirections 301 suffiront pour Google, mais ces services tiers peuvent mettre plus longtemps à mettre à jour. Si vous avez des intégrations directes avec ces plateformes, prévenez-les de la migration.

Le piège du "on verra plus tard"

La tentation est forte de laisser les pages AMP en place en se disant qu'elles ne font pas de mal. Elles en font. Chaque URL AMP qui reste est une URL de plus dans votre périmètre de crawl, une source potentielle de contenu dupliqué, et une page de plus à surveiller pour les régressions.

Plus vous attendez, plus il y a de risque qu'un déploiement futur casse les canonicals croisés sans que personne ne s'en aperçoive. Et quand le problème devient visible dans les données, il est déjà trop tard — Google a indexé le mauvais canonical depuis des semaines.

AMP est un format abandonné. Traitez-le comme tel : démontez-le méthodiquement, redirigez proprement, monitorez la transition, et passez à autre chose. Votre crawl budget, votre équipe de développement et votre dette technique vous remercieront. Un outil comme Seogard peut surveiller automatiquement que vos anciennes URLs AMP restent bien en 301 et qu'aucun résidu amphtml ne réapparaît après un déploiement — exactement le type de régression silencieuse qui passe entre les mailles des audits ponctuels.

AMP est mort : migrer vos pages AMP sans perdre de trafic

L'état des lieux : pourquoi AMP ne sert plus à rien en 2026

La chronologie de la dépréciation

Ce que vos pages AMP vous coûtent encore

Audit préalable : cartographier votre surface AMP

Identifier toutes les URLs AMP

Vérifier l'état d'indexation dans Search Console

Mesurer le trafic résiduel

Scénario concret : migration AMP d'un média de 18 000 articles

Données initiales

Objectifs de la migration

Planning d'exécution

Mise en place des redirections 301

Configuration Nginx

Configuration Apache

Vérification des redirections

Nettoyage du markup HTML

Supprimer les balises `<link rel="amphtml">`

Nettoyer le sitemap

Supprimer le code AMP du build

Performance des pages classiques : combler le gap

Auditer les Core Web Vitals de vos pages de destination

Quick wins performance

Monitoring post-migration : les 8 semaines critiques

Semaine 1-2 : vérifier les redirections

Semaine 3-4 : surveiller les fluctuations de trafic

Semaine 5-8 : confirmer la stabilisation

Signaux de succès

Edge cases et pièges fréquents

Pages AMP sans équivalent classique

Backlinks pointant vers des URLs AMP

AMP sur des sous-domaines

Pages AMP dans le cache de services tiers

Le piège du "on verra plus tard"

Articles connexes

Mobile-first indexing : checklist technique complète

AMP est mort : migrer vos pages AMP sans perdre de trafic

L'état des lieux : pourquoi AMP ne sert plus à rien en 2026

La chronologie de la dépréciation

Ce que vos pages AMP vous coûtent encore

Audit préalable : cartographier votre surface AMP

Identifier toutes les URLs AMP

Vérifier l'état d'indexation dans Search Console

Mesurer le trafic résiduel

Scénario concret : migration AMP d'un média de 18 000 articles

Données initiales

Objectifs de la migration

Planning d'exécution

Mise en place des redirections 301

Configuration Nginx

Configuration Apache

Vérification des redirections

Nettoyage du markup HTML

Supprimer les balises <link rel="amphtml">

Nettoyer le sitemap

Supprimer le code AMP du build

Performance des pages classiques : combler le gap

Auditer les Core Web Vitals de vos pages de destination

Quick wins performance

Monitoring post-migration : les 8 semaines critiques

Semaine 1-2 : vérifier les redirections

Semaine 3-4 : surveiller les fluctuations de trafic

Semaine 5-8 : confirmer la stabilisation

Signaux de succès

Edge cases et pièges fréquents

Pages AMP sans équivalent classique

Backlinks pointant vers des URLs AMP

AMP sur des sous-domaines

Pages AMP dans le cache de services tiers

Le piège du "on verra plus tard"

Articles connexes

Mobile-first indexing : checklist technique complète

Supprimer les balises `<link rel="amphtml">`