Comment Google choisit-il quelle version de contenu afficher entre PWA, desktop et AMP ?

Pourquoi Google impose-t-il de choisir une version principale ?

Quand un même contenu existe sous plusieurs formes — site desktop classique, Progressive Web App, page AMP — Google doit décider laquelle indexer comme référence. Sans directive claire, le moteur risque de traiter chaque version comme un contenu distinct, créant ainsi de la cannibalisation interne.

La consigne de Splitt n'est pas nouvelle, mais elle clarifie un point souvent mal compris : c'est au site de déclarer sa préférence, pas à Google de la deviner. Le « conviendra au plus grand nombre d'utilisateurs » signifie la version la plus complète, la plus stable, celle qui représente l'expérience que vous souhaitez offrir par défaut.

Comment Google décide-t-il quelle version montrer ensuite ?

Une fois la version principale désignée via les balises canoniques appropriées, Google peut choisir de servir une autre version dans les résultats si elle correspond mieux au contexte de recherche. Par exemple, une page AMP pour un utilisateur mobile en recherche rapide d'actualité, ou la PWA pour un utilisateur récurrent.

Ce mécanisme repose sur des signaux contextuels : type d'appareil, intention de recherche, historique de navigation, vitesse de connexion estimée. Google ne communique pas la pondération exacte de ces critères — [A vérifier] — mais les observations terrain montrent que la vitesse de chargement et la compatibilité mobile pèsent lourd.

Qu'est-ce qui change pour un SEO qui gère plusieurs versions ?

La directive impose une hiérarchie explicite entre les versions. Fini le temps où on pouvait laisser cohabiter desktop et AMP sans balises canoniques claires en espérant que Google « comprenne ». Aujourd'hui, chaque version non principale doit pointer vers la version de référence via rel=canonical.

Pour les PWA, c'est moins évident car elles fonctionnent souvent comme une surcouche de l'expérience desktop. Si la PWA et le site desktop servent exactement le même HTML à l'URL identique, il n'y a techniquement qu'une seule version aux yeux de Google. Le problème surgit quand la PWA utilise des URLs distinctes ou un rendu côté client massif.

• Désigner une version principale claire via les canoniques pour éviter la duplication d'index
• Relier toutes les variantes (AMP, mobile, PWA) à cette version principale
• Tester la cohérence des balises canonical et alternate media pour s'assurer que Google comprend la hiérarchie
• Ne pas supposer que Google fera automatiquement le bon choix sans directives explicites
• Surveiller les rapports de couverture Search Console pour détecter les versions indexées non souhaitées

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

Oui, largement. Les audits SEO révèlent régulièrement des cas de cannibalisation entre versions desktop et AMP mal configurées, où Google indexe les deux URLs comme distinctes et dilue le signal de ranking. La consigne de Splitt confirme ce qu'on observe : sans canonical explicite, Google ne fait pas de miracle.

En revanche, le passage « Google décidera laquelle montrer en fonction des besoins des utilisateurs » reste délibérément flou. Quels « besoins » exactement ? Vitesse ? Compatibilité ? Contenu enrichi ? Google ne publie pas de grille de décision, et les tests A/B montrent que ce choix peut varier pour une même requête selon le contexte. [A vérifier] avec vos propres données de trafic organique.

Quelles nuances faut-il apporter à cette recommandation ?

Splitt part du principe que les différentes versions servent le même contenu. Mais dans la réalité, AMP impose souvent des compromises (JavaScript limité, CSS restreint, fonctionnalités amputées). Si votre page AMP est une version appauvrie de l'expérience desktop, faut-il vraiment la proposer comme alternative ?

Deuxième nuance : pour les sites qui génèrent du contenu dynamique côté client (React, Vue, Angular en PWA), la « version principale » vue par Googlebot peut différer de celle vue par l'utilisateur. L'hydratation JavaScript crée parfois un écart entre le HTML initial (ce que Google indexe) et l'expérience finale. Dans ces cas, la consigne « choisir celle qui convient au plus grand nombre » devient ambiguë.

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

Si vous n'avez qu'une seule version de contenu — par exemple, un site responsive classique sans AMP ni PWA séparée — cette consigne ne vous concerne pas. C'est le cas majoritaire pour les sites e-commerce et corporate qui ont abandonné AMP ou ne l'ont jamais adopté.

Autre exception : les sites qui utilisent une stratégie de contenu différencié par canal (app mobile avec contenu exclusif, version desktop avec modules avancés). Dans ce cas, vous n'avez pas « plusieurs versions du même contenu », mais plusieurs contenus distincts — donc pas de canonical à poser, mais une architecture d'information à documenter.

Que faut-il faire concrètement pour déclarer une version principale ?

Première étape : auditer toutes les URLs actives pour identifier les variantes (desktop, mobile, AMP, PWA si elle utilise des URLs distinctes). Listez chaque URL et son type. Ensuite, décidez quelle version représente l'expérience de référence — généralement, c'est le site desktop ou la version responsive principale.

Implémentez ensuite les balises canonical sur toutes les versions secondaires pointant vers la version principale. Pour AMP, ajoutez aussi la balise <link rel="amphtml"> sur la version principale pointant vers l'AMP, et <link rel="canonical"> sur la page AMP pointant vers la principale. Cette bidirectionnalité est essentielle.

Quelles erreurs éviter lors de la mise en place des canoniques ?

Erreur classique : créer des boucles de canonical où la page A pointe vers B, et B vers A. Google ignore ces directives contradictoires et choisit arbitrairement. Autre piège : pointer toutes les variantes vers une URL qui elle-même redirige (301 ou 302) — le canonical doit pointer vers l'URL finale, pas vers une redirection.

Ne supposez pas que Google « comprendra » si vous omettez les canoniques sur certaines pages. Chaque page AMP doit avoir son canonical, chaque version mobile alternative doit pointer vers le desktop (sauf si vous utilisez un responsive pur, auquel cas il n'y a qu'une URL). Les oublis créent de l'indexation parasite et diluent le ranking.

Comment vérifier que Google respecte vos directives ?

Utilisez le rapport de couverture dans Search Console pour lister les URLs indexées. Filtrez par type de page (AMP, mobile, desktop). Si vous voyez des URLs AMP indexées alors que vous avez posé des canoniques vers le desktop, soit les balises sont mal codées, soit Google les ignore (ce qui arrive si la version principale est inaccessible ou très lente).

Testez aussi avec l'outil d'inspection d'URL : soumettez une page AMP et vérifiez que Google détecte bien le canonical vers la version principale. Si le canonical déclaré par Google diffère de celui que vous avez codé, cherchez des balises canonical multiples ou contradictoires dans le HTML.

• Auditer toutes les variantes d'URLs (desktop, mobile, AMP, PWA) et documenter leur rôle
• Désigner la version principale et implémenter les canoniques depuis toutes les autres versions
• Ajouter les balises alternate amphtml sur la version principale si vous utilisez AMP
• Tester chaque page avec l'outil d'inspection Search Console pour valider la détection du canonical
• Surveiller le rapport de couverture pour détecter les indexations non souhaitées
• Éviter les boucles ou chaînes de redirections dans les URLs canoniques