Le rel=canonical est-il vraiment obligatoire sur toutes les pages AMP, même standalone ?

Pourquoi Google impose-t-il un canonical sur toutes les pages AMP ?

La directive rel=canonical joue un rôle structurant dans l'architecture AMP de Google. Elle permet au moteur de distinguer clairement les relations entre versions d'une même ressource. Pour les pages AMP couplées, le canonical indique quelle est la version de référence — typiquement la page HTML classique.

Pour les AMP standalone, la logique diffère. Pas de version classique, donc pas de cible externe à désigner. Le self-canonical (la page pointe vers elle-même) évite toute ambiguïté et signale explicitement à Google que cette page AMP constitue la seule et unique version disponible. C'est une forme de déclaration d'identité technique.

Le canonical AMP est-il lié aux configurations hreflang ?

Non. Mueller précise que la règle du canonical AMP s'applique indépendamment de hreflang et des configurations multilingues. Certains SEO pensaient que hreflang pouvait remplacer ou contourner le canonical sur les pages AMP traduites — c'est faux.

Hreflang gère les relations inter-langues, canonical gère les relations inter-versions d'une même langue. Les deux mécanismes sont orthogonaux et doivent coexister sur les pages AMP multilingues. Un site AMP en anglais, français, allemand doit implémenter hreflang ET canonical sur chaque page, quelle que soit sa configuration.

Que se passe-t-il si le canonical est absent ou mal configuré ?

Google peut refuser d'indexer la page AMP, ou l'indexer en tant que duplicate content si une version classique existe. Le cache AMP peut également ne pas servir la page correctement, ce qui impacte directement la performance du carrousel AMP dans les résultats mobiles.

Les symptômes classiques : pages AMP exclues dans Search Console, messages d'erreur de validation AMP, ou pire — indexation de la version AMP alors que vous vouliez privilégier la version classique. Le canonical manquant ou erroné crée une ambiguïté de signaux que Google ne résout pas toujours en votre faveur.

• Canonical obligatoire sur toutes les pages AMP, couplées ou standalone
• Self-canonical pour les AMP standalone (la page pointe vers elle-même)
• Indépendant de hreflang — les deux mécanismes doivent coexister sur les sites multilingues
• Risques d'indexation en cas de canonical absent ou mal configuré
• Impact direct sur le cache AMP et la visibilité dans les résultats mobiles

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

Oui, et c'est même une des rares positions de Google qui correspond exactement à ce qu'on observe en production. Les sites qui omettent le canonical sur les pages AMP standalone rencontrent régulièrement des problèmes de crawl et d'indexation. La Search Console remonte d'ailleurs des erreurs explicites dans l'outil de validation AMP quand le canonical est absent.

Là où ça coince parfois : les CMS mal configurés qui génèrent automatiquement des pages AMP sans self-canonical. WordPress avec certains plugins AMP, par exemple, a longtemps eu ce défaut. Les développeurs pensaient que le canonical n'était requis que pour les configurations couplées — erreur terrain classique.

Quelles nuances faut-il apporter à cette règle ?

Mueller ne précise pas le comportement de Google face à un canonical contradictoire — par exemple une page AMP standalone qui pointe vers une URL classique qui n'existe plus. Dans ce cas, Google suit-il le canonical ou indexe-t-il l'AMP malgré tout ? [A vérifier] en conditions réelles, car la documentation officielle reste floue sur ce scénario.

Autre zone grise : les pages AMP dynamiques avec paramètres URL. Faut-il canonicaliser vers la version sans paramètres ou accepter un self-canonical paramétré ? Google ne donne pas de directive claire, et les retours terrain sont contradictoires selon les secteurs (e-commerce vs média). La règle générale s'applique, mais son implémentation pratique reste sujette à interprétation dans ces cas limites.

Dans quels cas cette règle pourrait-elle poser problème ?

Sur les sites à contenus éphémères (actualités, événements), migrer une page classique vers une AMP standalone nécessite de changer le canonical. Si vous oubliez cette étape, Google peut continuer à chercher l'ancienne version classique et marquer l'AMP comme orpheline. Symptôme vécu : pages qui disparaissent de l'index pendant 48-72h le temps que Googlebot recrawle et comprenne la nouvelle architecture.

Autre cas concret : les tests A/B sur AMP. Si vous testez deux versions AMP d'une même page, laquelle canonicaliser ? Google recommande de canonicaliser vers la version de contrôle, mais si les deux versions sont servies aléatoirement, vous risquez un canonical instable qui perturbe l'indexation. La déclaration de Mueller ne couvre pas ce scénario, pourtant fréquent en optimisation CRO.

Que faut-il faire concrètement sur un site AMP ?

Première étape : auditer toutes vos pages AMP pour vérifier la présence du canonical. Un simple crawl avec Screaming Frog ou Sitebulb suffit — filtrez les URLs AMP et vérifiez que 100% d'entre elles ont un canonical déclaré dans le <head>. Pour les AMP standalone, assurez-vous que le canonical pointe vers l'URL de la page elle-même, pas vers une version classique inexistante.

Ensuite, vérifiez la cohérence des canonical sur les versions traduites. Une page AMP en français doit canonicaliser vers elle-même (si standalone) ou vers la version classique française (si couplée) — jamais vers une version anglaise ou allemande. Hreflang gère les relations inter-langues, canonical gère l'identité de version. Les deux doivent être alignés mais indépendants.

Quelles erreurs éviter absolument ?

Erreur classique n°1 : le canonical relatif au lieu d'absolu. Certains CMS génèrent des canonical en /page-amp au lieu de https://example.com/page-amp. Google peut interpréter ça correctement, mais c'est une source de bugs sur les environnements de dev/staging. Utilisez toujours des URLs absolues avec protocole HTTPS.

Erreur n°2 : oublier le canonical lors d'une migration de couplée vers standalone. Vous supprimez la version classique, transformez l'AMP en page unique, mais le canonical continue de pointer vers l'ancienne URL classique qui renvoie maintenant une 404. Google se retrouve face à un signal contradictoire et peut désindexer la page. Mettez à jour le canonical AVANT de supprimer la version classique.

Comment vérifier que mon site est conforme ?

Utilisez l'outil de test AMP de Google (ou le validateur AMP officiel) sur un échantillon de pages. L'outil remonte explicitement les erreurs de canonical manquant ou mal configuré. Complétez avec un crawl complet pour détecter les pages qui auraient échappé à la validation manuelle.

Dans la Search Console, consultez le rapport Couverture > AMP. Les pages AMP sans canonical correct apparaissent souvent dans les erreurs « Page AMP non indexée » ou « Problème de canonical détecté ». Si vous voyez ces messages, corrigez le canonical et demandez une réindexation via l'outil d'inspection d'URL.

• Crawlez toutes les pages AMP et vérifiez la présence d'un canonical dans le <head>
• Pour les AMP standalone, assurez-vous que le canonical pointe vers l'URL de la page elle-même
• Utilisez des URLs absolues (https://...) dans vos canonical, jamais de chemins relatifs
• Vérifiez la cohérence canonical/hreflang sur les sites multilingues
• Testez un échantillon avec le validateur AMP officiel pour détecter les erreurs
• Surveillez le rapport AMP de Search Console pour identifier les pages problématiques