Pourquoi les annotations rel="amphtml" doivent-elles être présentes sur les deux versions de vos pages ?

Quelle est la logique derrière cette exigence de double annotation ?

Google a besoin d'établir une correspondance bidirectionnelle entre vos pages mobiles classiques et leurs équivalents AMP. Sans cette liaison explicite dans les deux sens, l'algorithme ne peut pas déterminer avec certitude quelle page AMP sert de version accélérée à quelle page mobile.

Cette exigence répond à un problème d'ambiguïté : une page AMP pourrait techniquement correspondre à plusieurs URLs mobiles si vous n'établissez pas ce lien canonique réciproque. L'annotation rel="amphtml" sur la page mobile pointe vers l'AMP, tandis que la page AMP doit contenir un rel="canonical" renvoyant vers la version mobile originale.

Que se passe-t-il en l'absence de cette double déclaration ?

Sans les deux annotations, Google peut tout simplement ignorer votre page AMP ou la traiter comme une page indépendante. Vous perdez alors le bénéfice de l'affichage accéléré dans les résultats mobiles, et potentiellement vous créez un problème de contenu dupliqué.

Le crawl devient également moins efficace. Googlebot doit faire des hypothèses plutôt que de suivre des directives explicites, ce qui rallonge le temps de traitement et peut retarder l'indexation de vos mises à jour.

Quelle différence avec les balises canonical classiques ?

Une balise canonical standard indique quelle version d'une page doit être indexée quand plusieurs versions existent. Ici, la logique est différente : vous ne déclarez pas une version comme préférentielle, vous établissez une relation de type "version accélérée".

La page AMP reste une variante technique de la page mobile, pas un doublon à éviter. L'annotation rel="amphtml" dit à Google : "cette page possède une version AMP optimisée que tu peux servir dans certains contextes". Sans cette précision, le moteur ne sait pas qu'il peut proposer l'alternative accélérée aux utilisateurs mobiles.

• L'annotation bidirectionnelle crée une association explicite entre page mobile et page AMP
• Sans liaison complète, Google peut ignorer la version AMP ou la traiter comme contenu dupliqué
• rel="amphtml" sur la page mobile pointe vers l'AMP, tandis que rel="canonical" sur l'AMP renvoie à la mobile
• Cette logique diffère du canonical classique qui résout les doublons plutôt que de déclarer des variantes techniques
• L'absence de ces annotations ralentit le crawl et retarde l'indexation des mises à jour

Cette directive reflète-t-elle ce qu'on observe sur le terrain ?

Dans la pratique, les sites qui implémentent correctement cette double annotation obtiennent effectivement un meilleur taux d'affichage de leurs pages AMP dans les résultats mobiles. Les audits montrent que les configurations incomplètes entraînent des fluctuations d'indexation, Google alternant entre versions selon son humeur.

Attention toutefois : même avec une implémentation parfaite, Google ne garantit pas d'afficher systématiquement la version AMP. Le moteur peut décider de servir la page mobile classique si elle offre une expérience qu'il juge supérieure, notamment sur les Core Web Vitals. [À vérifier] : aucune métrique officielle ne quantifie ce taux de préférence.

Quelles incohérences subsistent dans cette recommandation ?

Google ne précise pas comment gérer les cas où une page mobile possède plusieurs variantes AMP (tests A/B, versions régionales, etc.). La documentation reste vague sur la priorisation quand plusieurs pages AMP pointent vers la même URL mobile via rel="canonical".

De plus, l'absence de sanction explicite pour non-conformité crée une zone grise. Certains sites fonctionnent correctement sans liaison bidirectionnelle complète, tandis que d'autres rencontrent des problèmes d'indexation massifs pour la même configuration. Cette inconstance suggère que d'autres facteurs entrent en jeu sans que Google ne les documente.

Dans quels scénarios cette règle devient-elle problématique ?

Pour les sites avec des milliers de pages, synchroniser ces annotations représente un défi technique considérable. Une erreur dans le template peut casser l'association sur des sections entières, et les outils de détection ne remontent pas toujours ces problèmes immédiatement.

Les migrations de domaine compliquent encore la donne. Quand vous redirigez une ancienne URL mobile vers une nouvelle, vous devez mettre à jour l'annotation canonical de la page AMP correspondante, sinon vous créez une incohérence qui persiste tant que Google n'a pas recrawlé l'ensemble. Les délais de propagation peuvent atteindre plusieurs semaines sur les gros sites.

Comment vérifier que vos annotations sont correctement configurées ?

Commencez par inspecter le code source de quelques pages représentatives. Sur votre page mobile, cherchez la balise <link rel="amphtml" href="..."> dans le <head>. Sur la page AMP correspondante, vérifiez la présence de <link rel="canonical" href="..."> qui renvoie exactement vers l'URL mobile.

Utilisez l'outil de test AMP de Google pour valider chaque paire. Il détecte non seulement les erreurs de syntaxe AMP mais aussi les incohérences de liaison canonique. Complétez avec un crawl Screaming Frog en mode "AMP" qui extrait et compare automatiquement ces annotations sur l'ensemble du site.

Quelles erreurs d'implémentation rencontre-t-on le plus souvent ?

L'erreur classique : pointer vers une URL AMP en HTTP alors que la mobile est en HTTPS, ou l'inverse. Google traite ces URLs comme distinctes, cassant l'association. Même chose avec les trailing slashes incohérents (exemple.com/page/ vs exemple.com/page).

Autre piège fréquent : laisser des annotations rel="amphtml" sur des pages qui n'ont plus de version AMP active. Si l'URL AMP renvoie une 404 ou redirige, Google considère l'annotation comme invalide et peut pénaliser la page mobile pour mauvaise configuration.

Faut-il maintenir AMP en priorité ou migrer vers d'autres solutions ?

Depuis l'arrivée des Core Web Vitals comme facteur de ranking, l'avantage d'AMP s'est réduit. Si votre site mobile atteint déjà de bonnes performances natives, l'effort de maintenir deux versions peut ne plus se justifier. Google lui-même a confirmé que les pages rapides non-AMP bénéficient du même traitement.

Pour les sites d'actualités ou les gros éditeurs, AMP conserve néanmoins des atouts dans le carrousel Top Stories sur mobile. Évaluez le ROI réel : mesurez le trafic provenant spécifiquement des pages AMP versus l'effort technique de synchronisation. Si le delta est marginal, une migration vers une architecture mobile performante unique peut s'avérer plus rentable.

• Crawler l'intégralité du site pour extraire toutes les paires mobile/AMP et vérifier leur cohérence
• Valider que les URLs dans les annotations sont absolues et utilisent le même protocole (HTTPS)
• Contrôler l'absence d'annotations orphelines pointant vers des pages AMP supprimées ou redirigées
• Tester un échantillon représentatif avec l'outil de test AMP officiel de Google
• Monitorer Search Console pour détecter les erreurs d'indexation AMP remontées par Google
• Documenter le processus de mise à jour des annotations lors de migrations ou modifications d'URLs