Faut-il vraiment rediriger vos URLs AMP lors d'un changement ?

Pourquoi Google différencie-t-il les URLs AMP des URLs normales ?

La distinction repose sur l'architecture même du cache AMP. Contrairement aux URLs classiques qui dépendent du crawl traditionnel de Googlebot, les pages AMP sont servies depuis le cache Google (cdn.ampproject.org). Ce cache fonctionne selon une logique de rafraîchissement automatique beaucoup plus agressive.

Quand vous changez une URL normale sans redirection 301, Google doit redécouvrir la nouvelle page, comprendre qu'elle remplace l'ancienne, et transférer les signaux historiques. Ce processus prend généralement plusieurs semaines voire plusieurs mois selon l'autorité du site et la fréquence de crawl. Pour AMP, le système détecte et rafraîchit les contenus en quelques jours — d'où cette tolérance accrue.

Que signifie concrètement ce délai de quelques jours ?

Mueller parle d'un délai entre découverte et mise à jour de quelques jours. Attention : cela ne signifie pas que la transition est instantanée. Pendant ce laps de temps, votre ancienne URL AMP retournera probablement une erreur 404 si vous l'avez supprimée, ce qui dégrade l'expérience utilisateur.

Les visiteurs arrivant depuis la Search ou Google Discover tomberont sur une page cassée jusqu'à ce que le cache se mette à jour. C'est tolérable pour un blog avec peu de trafic AMP, beaucoup moins pour un média qui génère des milliers de clics quotidiens depuis les surfaces Google. Le risque est une perte de trafic temporaire mais mesurable.

Dans quels cas cette règle s'applique-t-elle vraiment ?

Cette déclaration concerne spécifiquement les changements d'URLs AMP côté éditeur — refonte de structure, migration de domaine, modification de slugs. Elle ne s'applique pas aux erreurs de validation AMP, aux problèmes de cache ou aux désindexations pour raisons qualitatives.

Il faut aussi comprendre que même si Google rafraîchit vite, les autres acteurs de l'écosystème AMP (Twitter, LinkedIn, agrégateurs tiers) ne suivent pas nécessairement la même cadence. Vous risquez donc des liens cassés dans des environnements hors Google si vous ne redirigez pas proprement.

• Le cache AMP se rafraîchit automatiquement en quelques jours lors d'un changement d'URL, contrairement au crawl standard qui prend des semaines
• L'absence de redirection crée une fenêtre de 404 temporaire mais réelle, impactant l'expérience utilisateur et le trafic
• Google recommande quand même de rediriger — ce qui signale que cette tolérance technique ne dispense pas des bonnes pratiques
• Les plateformes tierces (réseaux sociaux, agrégateurs) ne bénéficient pas du même système de rafraîchissement rapide
• Cette règle ne couvre que les changements d'URLs, pas les problèmes de validation ou d'indexation AMP

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, l'expérience confirme que le cache AMP réagit beaucoup plus vite qu'un crawl classique. Sur des migrations AMP que j'ai supervisées, les nouvelles URLs apparaissaient effectivement dans le cache Google en 48-96 heures sans redirection. Mais — et c'est un gros mais — cette rapidité ne compense pas les dégâts collatéraux.

Pendant ces quelques jours, les anciennes URLs génèrent des 404 dans la Search Console, les utilisateurs tombent sur des erreurs, et surtout vous perdez le bénéfice de la continuité des signaux. Une redirection 301 transfère instantanément l'autorité et les métriques d'engagement. Sans elle, même si Google retrouve vite la nouvelle page, il la traite comme une nouvelle entité — au moins temporairement.

Quels risques cette approche tolérante fait-elle courir ?

Le premier risque est purement business : quelques jours de 404 sur un site à fort trafic AMP peuvent représenter des milliers de sessions perdues. Pour un média publicitaire ou un e-commerce qui génère du revenu à chaque visite, cette perte est tangible et mesurable. [À vérifier] si Google compense réellement ce délai en accélérant le transfert de ranking — aucune donnée officielle là-dessus.

Le second risque concerne les signaux utilisateurs. Des pages qui génèrent des 404 pendant plusieurs jours voient leurs métriques Core Web Vitals dégradées (puisque les visiteurs rebondissent immédiatement), ce qui peut impacter le ranking même après la mise à jour du cache. Et contrairement à une URL classique où vous contrôlez la redirection, avec AMP vous dépendez du bon vouloir du système de cache Google.

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

Cette tolérance ne fonctionne que si Google peut découvrir rapidement la nouvelle URL via le sitemap AMP, le flux RSS, ou le crawl naturel. Si votre nouvelle structure n'est pas correctement signalée, le délai peut s'allonger considérablement — et là, vous perdez l'avantage du rafraîchissement rapide.

Elle ne s'applique pas non plus aux migrations de domaine AMP complexes impliquant un changement d'hébergeur ou de CDN. Dans ce cas, même avec un cache rapide, vous avez besoin de redirections serveur pour éviter les conflits de résolution DNS et les erreurs HTTPS. Soyons honnêtes : se passer de redirections sur une migration AMP reste une pratique à risque, même si techniquement Google peut s'en accommoder.

Que faut-il faire concrètement lors d'un changement d'URLs AMP ?

Même si Google tolère l'absence de redirection, mettez en place des redirections 301 côté serveur pour toutes vos URLs AMP modifiées. C'est la seule façon de garantir une transition sans couture pour les utilisateurs et les robots, tout en préservant l'équité de liens et les signaux historiques. Configurez ces redirections au niveau Apache, Nginx ou via votre CDN.

Parallèlement, soumettez votre sitemap AMP mis à jour via la Search Console immédiatement après le changement. Cela accélère la découverte des nouvelles URLs et réduit la fenêtre de latence mentionnée par Mueller. Si vous utilisez un flux RSS pour AMP, mettez-le à jour simultanément. Et surtout, purgez manuellement le cache AMP via l'outil de Google si vous avez besoin d'une mise à jour quasi instantanée.

Quelles erreurs éviter absolument ?

Ne vous fiez pas à la tolérance technique pour négliger le suivi post-migration. Beaucoup de sites changent leurs URLs AMP, constatent que Google les retrouve effectivement en quelques jours, et en concluent que tout va bien — alors que leurs métriques de trafic AMP ont chuté de 20-30% pendant cette période. Cette perte n'est pas toujours récupérée ensuite.

Évitez aussi de traiter différemment AMP et non-AMP lors d'une migration. Si vous redirigez vos URLs standards mais pas les AMP sous prétexte que "Google rafraîchit vite", vous créez une incohérence de structure qui complique le suivi analytique et peut générer des signaux contradictoires pour les algorithmes. Uniformisez votre approche : une URL qui change doit être redirigée, point final.

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

Surveillez vos logs serveur et la Search Console AMP pendant les 7 jours suivant le changement. Vous devez constater une baisse progressive des requêtes vers les anciennes URLs (si vous avez redirigé) ou des 404 temporaires (si vous n'avez pas redirigé). Dans tous les cas, les nouvelles URLs doivent apparaître dans le rapport de couverture en moins de 72 heures.

Testez manuellement le cache AMP en visitant https://cdn.ampproject.org/c/s/votresite.com/nouvelle-url pour vérifier que la version cachée correspond bien à votre nouvelle page. Si ce n'est pas le cas après 96 heures, il y a un problème de découverte ou de validation qu'il faut investiguer. Et bien sûr, comparez votre trafic AMP semaine par semaine pour détecter toute anomalie prolongée.

• Configurer des redirections 301 pour toutes les URLs AMP modifiées, même si Google tolère leur absence
• Soumettre le sitemap AMP mis à jour immédiatement via Search Console
• Purger manuellement le cache AMP pour les URLs critiques via l'outil Google
• Surveiller les logs serveur et le rapport AMP Search Console pendant 7 jours minimum
• Vérifier manuellement le cache AMP (cdn.ampproject.org) pour confirmer la mise à jour
• Comparer les métriques de trafic AMP avant/après pour détecter toute perte anormale