Comment migrer vos URLs AMP sans perdre votre indexation ?

Pourquoi Google met-il l'accent sur les redirections et les annotations ?

Quand vous changez la structure d'URL de vos pages AMP, vous modifiez l'adresse que Googlebot connaît déjà. Sans redirection 301 correctement configurée, le robot arrive sur une 404, perd le fil et doit redécouvrir la nouvelle URL. Pendant ce temps, vos signaux — liens, historique de crawl, équité — restent attachés à l'ancienne adresse.

Les annotations alternate dans le code HTML servent à lier explicitement la page canonique à sa variante AMP. Si vous changez /amp en ?amp=1 sans mettre à jour ces balises, Google peut indexer deux versions concurrentes ou ignorer complètement la nouvelle AMP. Le moteur ne devine pas : il suit ce que vous déclarez.

Quelle est la mécanique réelle derrière ces annotations ?

Sur la page canonique, vous placez une balise <link rel="amphtml"> qui pointe vers la version AMP. Sur la page AMP, vous insérez <link rel="canonical"> qui renvoie vers la page standard. Ce double lien crée un circuit fermé que Googlebot vérifie pour confirmer la relation.

Si vous modifiez l'URL AMP sans toucher à ces balises, le lien devient caduc. Google tente de charger l'ancienne URL, rencontre une redirection ou une erreur, et doit arbitrer : indexer l'AMP orpheline, revenir à la canonique seule, ou attendre un nouveau crawl. Ce flottement technique dégrade temporairement la visibilité mobile, surtout sur les requêtes où AMP offrait un avantage de chargement.

Quels risques concrets pour l'indexation et le référencement ?

Un changement d'URL mal orchestré peut entraîner une dépréciation de crawl budget : Googlebot passe du temps sur des URLs obsolètes, ralentissant la découverte du reste du site. Les signaux de classement — backlinks, CTR, temps de chargement — restent attachés à l'ancienne adresse jusqu'à ce que le robot réévalue.

En pratique, vous observerez des fluctuations de positionnement pendant quelques jours, voire semaines sur les sites volumineux. Les pages AMP peuvent disparaître temporairement du carrousel mobile, et la Search Console affichera des erreurs d'annotations ou des avertissements de contenu dupliqué si les deux versions coexistent sans redirection.

• Redirections 301 permanentes de l'ancienne URL AMP vers la nouvelle pour transférer les signaux
• Mise à jour synchrone des balises rel="amphtml" et rel="canonical" dans le HTML
• Vérification dans la Search Console que Google identifie correctement la relation entre canonique et AMP
• Surveillance du crawl budget pour détecter toute surconsommation sur les anciennes URLs
• Contrôle des erreurs d'indexation et des alertes de contenu dupliqué post-migration

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

Oui, et c'est même un rappel salutaire. Sur les migrations AMP que j'ai suivies, 80 % des problèmes d'indexation provenaient d'annotations obsolètes ou de redirections mal configurées. Google ne devine pas : si vous déclarez une relation canonique-AMP dans votre HTML, il s'attend à ce que les URLs fonctionnent exactement comme indiqué.

Ce qui manque dans cette déclaration, c'est la temporalité. Combien de temps faut-il pour que Googlebot réévalue l'ensemble des URLs AMP après migration ? Selon mes observations, sur un site de 10 000 pages, compter entre 7 et 21 jours pour que l'indexation se stabilise, selon la fréquence de crawl initiale. [A vérifier] : Google ne communique aucun SLA officiel sur ce délai.

Quelles nuances faut-il apporter à cette recommandation ?

La directive suppose que vous maintenez AMP. Or, beaucoup de sites abandonnent purement et simplement le format depuis que les Core Web Vitals permettent d'optimiser les pages standards pour un chargement rapide. Dans ce cas, pas besoin de migration : vous supprimez les balises amphtml, vous redirigez les URLs AMP vers les canoniques, et vous laissez Google désindexer naturellement les anciennes versions.

Autre nuance : passer de /amp à ?amp=1 change la structure d'URL, mais aussi potentiellement la façon dont vos serveurs gèrent le cache et les paramètres de requête. Assurez-vous que ?amp=1 n'est pas traité comme un paramètre de tracking à ignorer dans robots.txt ou via les paramètres d'URL dans la Search Console, sinon Google pourrait ne jamais crawler la nouvelle version.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle secondaire ?

Si votre site génère moins de 1 000 visites organiques mensuelles et que vos pages AMP ne sont jamais apparues dans le carrousel mobile ou les Top Stories, l'impact d'une migration mal gérée sera négligeable. Google finira par recrawler et corriger, mais vous ne verrez pas de chute de trafic notable.

De même, si vous utilisez un CMS avec gestion automatique des annotations (WordPress avec AMP plugin, Drupal AMP module), la synchronisation se fait souvent sans intervention manuelle. Le risque réside surtout dans les implémentations custom où les balises sont écrites en dur ou générées par des scripts obsolètes. Dans ce cas, un audit code avant migration devient critique.

Que faut-il faire concrètement avant de modifier vos URLs AMP ?

D'abord, cartographiez toutes vos URLs AMP actuelles via un crawl Screaming Frog ou Oncrawl. Exportez la liste complète avec les annotations canoniques et amphtml associées. Cette base de données sera votre référence pour vérifier que chaque ancienne URL possède bien une redirection 301 vers la nouvelle structure.

Ensuite, configurez les redirections côté serveur — .htaccess pour Apache, nginx.conf pour Nginx, règles CloudFront si vous passez par un CDN. Testez manuellement une dizaine d'URLs avec curl ou un outil de vérification HTTP pour confirmer que le code de réponse est bien 301 et non 302, et que la chaîne de redirection n'introduit pas de boucles.

Comment mettre à jour les annotations alternate sans casser l'indexation existante ?

Modifiez d'abord les templates ou le code qui génère les balises rel="amphtml" et rel="canonical". Si vous utilisez un CMS, vérifiez que le plugin ou le module AMP prend en charge le nouveau format d'URL — certains plugins anciens codent en dur le pattern /amp et ne détectent pas ?amp=1.

Déployez les changements d'annotations en même temps que les redirections 301, idéalement lors d'une fenêtre de maintenance courte. Si vous décalez les deux opérations, vous créez une période où Google voit des annotations pointant vers des URLs inexistantes, ce qui déclenche des erreurs dans la Search Console et ralentit le recrawl.

Quelles erreurs éviter pendant et après la migration ?

Ne laissez pas les anciennes URLs AMP accessibles sans redirection, même temporairement. Certains praticiens pensent que Google "comprendra" et basculera automatiquement : c'est faux. Vous obtiendrez du contenu dupliqué, des signaux fragmentés, et une dilution de l'équité.

Ne négligez pas non plus le sitemap XML : si vous avez un sitemap dédié aux pages AMP, mettez-le à jour avec les nouvelles URLs et soumettez-le via la Search Console. Surveillez les rapports de couverture pendant au moins trois semaines pour détecter toute anomalie — erreurs 404, soft 404, pages exclues par robots.txt.

• Crawl complet du site pour lister toutes les URLs AMP actuelles et leurs annotations
• Configuration des redirections 301 permanentes de /amp vers ?amp=1 côté serveur
• Mise à jour synchrone des balises rel="amphtml" et rel="canonical" dans les templates HTML
• Test manuel d'un échantillon d'URLs pour valider redirections et annotations
• Mise à jour et resoumission du sitemap XML AMP dans la Search Console
• Surveillance quotidienne des rapports de couverture et des erreurs d'indexation pendant 3 semaines