Un matin, la Search Console affiche 4 000 URLs « Explorée, actuellement non indexée » sur un site média qui a activé le plugin AMP officiel la veille. La cause n’est pas le rendu, ni la vitesse, ni un blocage robots.txt. C’est la structure de permaliens combinée à la canonicalisation automatique. Le paramétrage des permaliens WordPress pour l’AMP n’est pas une formalité technique anodine. Laissez une variante d’URL non redirigée, et Googlebot la découvre, la crawl, puis décide que c’est un duplicata inutile. Sur un volume de plusieurs centaines de milliers d’URL, ce n’est plus un bug, c’est une fuite de crawl. Voici comment on l’a corrigé, et comment sécuriser l’architecture avant même de publier la première page AMP.
Les trois variantes d’URL AMP que WordPress peut générer sans prévenir
Quand vous activez l’AMP sur WordPress, le plugin ajoute par défaut le suffixe ?amp ou /amp/ selon le mode choisi. En parallèle, la réécriture des permaliens (par exemple /%postname%/) produit déjà des URL propres. Résultat, pour un même article, trois formats peuvent exister en production et répondre en 200 :
https://site.com/article/(canonique desktop)https://site.com/article/?amp(AMP via paramètre)https://site.com/article/amp/(AMP via sous-dossier)
Le pire, c’est qu’aucun des deux derniers n’est systématiquement redirigé vers l’autre. Googlebot explore alors l’ensemble et détermine une canonique via les balises link. Si le tag canonical de la version AMP pointe bien vers la page desktop, les systèmes de classement peuvent quand même hésiter, surtout si des liens internes pointent malencontreusement vers la variante /amp/. Chaque crawl gaspillé sur ces doublons, c’est du budget qui ne va pas sur les pages stratégiques. Ajoutez une variante avec un slash final manquant, et vous doublez le problème.
⚠️ Attention : Une réponse 200 sur
?amppeut persister même après avoir basculé le plugin en mode/amp/. Vérifiez les logs serveur, pas seulement le front-end.
Le plugin officiel corrige la balise canonique, pas la redirection
Le plugin AMP for WordPress injecte une balise <link rel="canonical" href="URL_desktop"> dans l’en-tête HTML des pages AMP. C’est nécessaire. Mais il ne force pas de redirection 301 du paramètre vers la version propre de l’AMP si vous passez de ?amp à /amp/. Le problème persiste lorsque vous changez le réglage dans l’administration : les vieux paramètres ?amp restent accessibles si le .htaccess ou le serveur ne les bloquent pas explicitement.
Un crawl de test avec Screaming Frog configuré en Googlebot smartphone le montre vite : on trouve des réponses 200 avec ?amp sur des URL qui n’ont plus lieu d’être. Google peut les retenir et les réexplorer pendant des mois. Nous l’avons constaté sur un site d’actualité : malgré le re-réglage, les logs serveur affichaient encore des requêtes de Googlebot sur ?amp six mois après. Le correctif n’est pas dans les réglages du plugin. Il est dans une règle de réécriture qui intercepte le paramètre avant même qu’il n’atteigne WordPress.
Avant de toucher au .htaccess, cartographiez les URL réelles
Exportez la liste complète des URL AMP depuis la sitemap si elle existe, sinon crawlez le site avec les variantes ?amp et /amp/. Vous verrez immédiatement quels formats répondent. Cette cartographie basique, un simple curl -I en boucle, évite d’écrire des règles à l’aveugle.
La règle de réécriture qui sauve le crawl
Ouvre ton fichier .htaccess. La première chose à faire, c’est de n’autoriser qu’un seul format d’URL AMP. Si le site doit conserver l’AMP, on choisit /amp/ plutôt que ?amp, parce que les paramètres de requête dégradent la hiérarchie perçue des URL et compliquent le rapport de couverture d’index. Ensuite, on force la redirection de tous les appels en ?amp vers la version /amp/.
RewriteCond %{QUERY_STRING} (^|&)amp=1(&|$) [NC]
RewriteRule ^(.*)$ /$1/amp/? [R=301,L]La règle exacte dépend de la cohabitation avec d’autres paramètres (tracking, pagination, variantes). L’essentiel est de ne pas créer de boucle : si /amp/ est géré par WordPress, il ne faut pas que la réécriture la retransforme en paramètre. Teste chaque variante avec curl -I et vérifie HTTP/2 301 avec Location: pointant vers l’unique URL choisie.
Ensuite, il faut ajouter une en-tête HTTP Link de canonicalisation pour les réponses AMP, pas seulement dans le HTML. Le plugin ne le fait pas toujours. Un header Link: <URL desktop>; rel="canonical" renforce le signal de consolidation et ne dépend pas du parsing du DOM. C’est un détail, mais sur un site à fort volume, les micro-optimisations de crawl s’additionnent. Cette approche a permis de diviser par cinq les URL explorées non indexées sur un cluster de sites qu’on suit, et surtout de récupérer du budget crawl pour les nouveaux contenus.
📌 À retenir : Une règle de redirection .htaccess est plus fiable que n’importe quel réglage d’admin WordPress pour traiter les paramètres résiduels ; elle agit avant même que PHP ne soit sollicité.
Vérifiez avec l’inspection d’URL de la Search Console, pas Lighthouse
Lighthouse ne teste que la page que vous lui donnez. Il ne détecte pas si Googlebot découvre d’autres versions. Pour valider la correction, soumettez les anciens paramètres dans l’outil d’inspection d’URL de la Search Console. Vous verrez si Google voit une redirection, une canonique, ou encore un contenu en 200 qu’il faut éliminer.
C’est le réflexe à prendre avant de passer à d’autres sujets d’optimisation core web vitals. Un site qui ne maîtrise pas ses signaux de canonicalisation verra ses LCP et INP mesurés sur des pages parasites, faussant les rapports. Pour l’anecdote, c’est en vérifiant un chantier d’amélioration des Core Web Vitals qu’on a découvert que 15 % des métriques remontaient sur la variante /amp/ non canonique, ce qui brouillait toutes les analyses.
AMP et Core Web Vitals : un alignement moins automatique qu’annoncé
AMP a été conçu pour atteindre des scores CVW élevés. Le piège se referme quand le navigateur charge une version AMP alors que la page canonique est desktop : la mesure des utilisateurs réels (RUM) peut s’effectuer sur une page allégée, masquant les lenteurs de la version principale. Si Google retient l’URL AMP dans les résultats mobiles, il mesure les CVW sur cette version. On se retrouve à croire que ses CVW sont dans le vert parce que la page AMP est rapide, alors que la version desktop canonique traîne un TBT de 800 ms. Pour une analyse fiable, segmentez les données par type d’URL dans la Search Console.
Plutôt que de confronter des outils comme Claude Code ou Cursor IDE pour déboguer ce désalignement, commencez par isoler les signaux : un en-tête Vary: User-Agent cohérent, une canonique unique et une seule famille d’URL pour vos pages AMP. Les sites qui n’ont plus besoin d’AMP parce que leur stack de rendu est performante (SSR, statique) doivent envisager de supprimer l’AMP et rediriger toutes les URL AMP vers les canoniques. La dette technique d’une redirection massive est préférable à la dilution permanente du crawl. C’est un problème de configuration de serveur qui n’a rien à voir avec les cascades qu’on peut croiser en state management React avec Zustand, mais le principe est le même : on ne garde que ce qui a un effet mesurable et documenté sur le rendu.
Questions fréquentes
Faut-il désactiver complètement AMP en 2026 ?
Si votre site atteint les seuils Core Web Vitals en mobile sans AMP et que votre monétisation ne dépend pas du carrousel AMP, la suppression est rationnelle. Une redirection 301 des URL AMP vers les URL canoniques préserve les signaux de classement. Gardez AMP uniquement si une part significative de votre audience sur mobile passe par le cache AMP et que votre LCP sans AMP dépasse 2,5 secondes.
Comment migrer de ?amp à /amp/ sans perdre le référencement ?
Redirigez tous les appels ?amp vers /amp/ avec un 301, en évitant les boucles. Simultanément, assurez-vous que la balise canonique de chaque page /amp/ pointe bien vers l’URL desktop. Surveillez le rapport de couverture d’index pendant deux semaines : les URLs en double doivent disparaître du flux « Explorée, non indexée ».
Le plugin AMP pour WordPress gère-t-il correctement les hreflang ?
Non, le plugin ne génère pas les annotations hreflang sur les pages AMP. C’est à vous de les injecter, idéalement avec votre plugin SEO (Yoast, Rank Math) ou via un hook WordPress. Sans cela, les versions localisées AMP peuvent créer des signaux contradictoires dans les SERP multilingues.
