Page canonique, site mobile, AMP : pourquoi Google distingue-t-il ces trois versions ?

Pourquoi Google reconnaît-il trois versions distinctes d'une même page ?

Techniquement, Google traite chaque URL comme une entité séparée, même si le contenu est identique. La page canonique représente votre URL de référence, celle que vous voulez voir indexée et classée dans les résultats de recherche.

Le site mobile est une version optimisée pour les écrans tactiles, souvent hébergée sur un sous-domaine (m.exemple.com) ou un répertoire dédié (/mobile/). L'AMP, lui, est une technologie spécifique développée par Google qui impose un HTML simplifié et des contraintes strictes pour garantir un chargement quasi-instantané.

Ces trois versions coexistent-elles encore dans l'écosystème web actuel ?

La réalité terrain est plus nuancée. Depuis le mobile-first indexing, la plupart des sites modernes utilisent un design responsive unique qui sert de version canonique ET mobile. Les sites mobiles séparés (m.exemple.com) sont en déclin prononcé depuis plusieurs années.

L'AMP connaît lui aussi un recul significatif après que Google a retiré le badge éclair et l'avantage dans le carrousel Top Stories. Beaucoup de sites l'ont abandonné au profit d'optimisations Core Web Vitals sur leurs pages classiques.

Quels signaux permettent à Google de faire le lien entre ces versions ?

Google s'appuie sur des balises HTML spécifiques pour comprendre la relation entre ces URLs. La balise canonical indique quelle version est la principale, tandis que les annotations alternate précisent les variantes mobiles ou AMP.

Sans ces signaux correctement configurés, Google peut indexer la mauvaise version, diluer votre autorité entre plusieurs URLs, ou ignorer complètement certaines variantes. C'est un problème fréquent sur les sites ayant conservé une architecture mobile séparée sans maintenance adéquate.

• Page canonique : version de référence, souvent desktop ou responsive, contient le contenu complet
• Site mobile : variante optimisée tactile, peut avoir un contenu réduit ou une navigation simplifiée
• AMP : version ultra-légère avec HTML restreint, CSS inline limité, JavaScript contrôlé par Google
• Annotations croisées : chaque version doit pointer vers les autres avec les balises appropriées (canonical, alternate, amphtml)
• Mobile-first indexing : Google indexe prioritairement la version mobile, rendant la distinction canonique/mobile moins pertinente pour les sites responsive

Cette distinction reflète-t-elle encore la réalité des architectures web modernes ?

Soyons francs : cette déclaration sent le recyclage de documentation datée. La séparation entre page canonique et site mobile est un vestige de l'époque pré-responsive, quand les sites maintenaient effectivement deux versions distinctes (www et m.).

Aujourd'hui, la majorité écrasante des sites professionnels utilisent un design responsive unique qui sert à la fois de canonique et de mobile. Cette architecture élimine naturellement les problèmes de duplication et simplifie la gestion des signaux pour Google. Continuer à présenter la distinction canonique/mobile comme standard est trompeur.

L'AMP mérite-t-il encore qu'on le mentionne comme option viable ?

L'AMP a perdu son principal avantage concurrentiel quand Google a supprimé le badge éclair et ouvert le carrousel Top Stories aux pages non-AMP. Les données terrain montrent un abandon massif : des sites majeurs comme The Guardian, Reddit ou Le Monde ont supprimé leurs versions AMP.

Maintenir de l'AMP représente un coût de développement et maintenance non négligeable pour un bénéfice qui se résume désormais à un gain marginal de vitesse de chargement. Ce gain est souvent annulé par les limitations fonctionnelles (tracking, monétisation, interactivité) qui frustrent les éditeurs. [À vérifier] : Google communique peu sur les statistiques d'adoption actuelles de l'AMP.

Quels sont les vrais risques si on gère mal ces distinctions ?

Le principal danger concerne les sites legacy ayant conservé une architecture mobile séparée sans implémenter correctement les annotations. Google peut alors indexer m.exemple.com au lieu de www.exemple.com, créant confusion et dilution d'autorité.

Avec l'AMP, le risque est différent : si les balises amphtml et canonical ne sont pas symétriques, Google peut traiter les deux versions comme du contenu dupliqué et appliquer des filtres. Pire, il peut choisir d'indexer uniquement l'AMP, privant votre analytics des données complètes et bloquant certains scripts tiers essentiels.

Que faire si mon site utilise encore un sous-domaine mobile séparé ?

La première question à vous poser : pourquoi conservez-vous cette architecture obsolète ? La migration vers un design responsive unique devrait être votre priorité absolue. Elle élimine les problèmes de duplication, simplifie votre code et aligne votre site sur les standards actuels.

En attendant la migration, vérifiez que chaque page mobile contient <link rel="canonical" href="https://www.exemple.com/page"> et que chaque page desktop inclut <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.exemple.com/page">. Testez ces annotations dans Google Search Console section Couverture.

Comment décider si l'AMP vaut encore le coup pour mon site ?

Analysez vos Core Web Vitals sur vos pages normales. Si vous atteignez déjà les seuils verts (LCP < 2.5s, FID < 100ms, CLS < 0.1), l'AMP n'apportera qu'un gain marginal. Le jus n'en vaut probablement pas la chandelle.

Si vous êtes un site d'actualité publiant des dizaines d'articles quotidiens avec des scores CWV catastrophiques, l'AMP peut offrir une solution de contournement rapide. Mais considérez-le comme temporaire : investissez parallèlement dans l'optimisation de vos pages classiques pour terme l'AMP à moyen terme.

Quelles vérifications techniques effectuer pour éviter les erreurs de configuration ?

Utilisez l'outil Test d'optimisation mobile de Google pour confirmer que votre version mobile est correctement détectée. Vérifiez dans Search Console que Google indexe bien la version que vous souhaitez (regardez l'URL indexée dans le rapport Couverture).

Pour l'AMP, le validateur officiel (validator.ampproject.org) est indispensable. Un seul élément HTML non-conforme suffit à invalider toute la page. Contrôlez également que vos balises canonical/amphtml forment un cycle cohérent entre versions AMP et non-AMP.

• Auditer toutes les pages pour vérifier la cohérence des balises canonical et alternate
• Confirmer dans Search Console quelle version (desktop/mobile/AMP) Google indexe réellement
• Tester la parité de contenu entre versions : le mobile/AMP ne doit pas manquer d'éléments clés présents sur le desktop
• Surveiller les rapports Core Web Vitals pour évaluer si l'AMP apporte un bénéfice mesurable
• Planifier une migration vers responsive si vous maintenez encore m.exemple.com
• Valider toutes les pages AMP avec le validateur officiel et corriger les erreurs critiques