Pourquoi Google affiche-t-il les deux versions mobile et desktop de vos pages dans ses résultats ?

Que signifie vraiment cette duplication d'URLs dans les SERP ?

Quand vous cherchez votre marque ou vos mots-clés principaux et que vous voyez apparaître à la fois example.com/page et m.example.com/page, ce n'est pas un bug de Google. C'est le symptôme direct d'un problème de configuration canonique entre vos versions mobile et desktop.

Cette situation révèle que Googlebot ne sait pas quelle version privilégier. Sans directives claires, le moteur indexe les deux variantes et les considère comme des pages distinctes. Résultat : vous cannibalisez votre propre trafic et fragmentez vos signaux de ranking entre deux URLs qui devraient être unifiées.

Comment Google détermine-t-il quelle version afficher normalement ?

Avec le déploiement du Mobile-First Indexing, Google utilise par défaut la version mobile d'une page pour l'indexation et le classement. Mais cette logique ne fonctionne que si les balises canonical sont correctement configurées dans les deux sens.

La page mobile doit pointer en canonical vers la version desktop (link rel="canonical" href="https://www.example.com/page"), tandis que la page desktop doit avoir un link alternate media vers la version mobile. Ce double signalement permet à Google de comprendre que les deux URLs représentent le même contenu et de n'en indexer qu'une seule.

Pourquoi cette configuration est-elle si souvent mal implémentée ?

La majorité des sites qui maintiennent encore des sous-domaines mobiles séparés ont hérité de cette architecture à une époque où le responsive design n'était pas la norme. Beaucoup ont migré vers des templates responsive mais ont oublié de nettoyer les anciennes URLs mobiles ou de synchroniser les canonicals.

D'autres cas révèlent des conflits entre plugins ou CMS qui génèrent automatiquement des balises canonical sans cohérence entre versions. Les plateformes e-commerce custom sont particulièrement concernées, avec des systèmes de gestion de templates qui ne parlent pas entre eux.

• Vérifier la cohérence des canonicals entre versions mobile et desktop sur toutes vos pages stratégiques
• Auditer les balises alternate media depuis la version desktop pour s'assurer qu'elles pointent correctement vers le sous-domaine mobile
• Tester l'affichage dans les SERP avec des requêtes brand pour détecter rapidement toute duplication
• Privilégier le responsive design pour éviter cette complexité technique si vous lancez un nouveau site
• Documenter l'architecture technique pour que toute modification future respecte cette logique de canonicalisation bidirectionnelle

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Les audits techniques révèlent régulièrement ce type de duplication, et dans 90% des cas, c'est bien un problème de canonical mal configuré ou absent. Ce que Mueller ne précise pas, c'est que cette duplication peut aussi survenir lors de migrations ou de refonte, quand les anciennes URLs mobiles restent indexées pendant plusieurs semaines.

Un point rarement abordé : même avec des canonicals parfaits, si vos redirections 301 entre versions ne sont pas synchrones (redirection conditionnelle selon user-agent), Google peut temporairement maintenir les deux versions en index. Le délai de consolidation varie selon la fréquence de crawl de votre site.

Quelles nuances faut-il apporter à ce conseil ?

Mueller recommande que la page mobile ait un canonical vers la desktop et vice versa. Soyons clairs : avec le Mobile-First Indexing généralisé, cette configuration est devenue partiellement obsolète pour les sites full responsive. Si vous n'avez qu'une seule URL par contenu, le canonical pointe simplement vers lui-même.

La vraie complexité concerne les sites qui maintiennent encore un sous-domaine mobile séparé (m.example.com). Pour eux, la règle s'applique strictement. Mais attention : même bien configurée, cette architecture reste fragile. Tout changement de template, toute mise à jour de CMS peut casser ces liens. [À vérifier] régulièrement via Search Console et des crawls automatisés.

Dans quels cas cette configuration échoue-t-elle malgré tout ?

Premier cas fréquent : les conflits de canonical entre plugins. Si Yoast SEO génère un canonical et qu'un plugin de mobile detection en génère un autre, le dernier déclaré dans le code l'emporte. Google peut alors recevoir des signaux contradictoires selon la version crawlée.

Deuxième piège : les URLs avec paramètres (utm, tracking, pagination). Si votre page mobile est m.example.com/page?variant=blue et pointe en canonical vers www.example.com/page sans le paramètre, Google peut considérer qu'il s'agit de contenus différents et maintenir la duplication.

Que faut-il faire concrètement pour corriger cette duplication ?

Première étape : auditer l'état actuel. Lancez une recherche site:m.votresite.com dans Google pour voir combien de pages mobiles sont indexées. Comparez avec site:www.votresite.com. Si les deux retournent des résultats significatifs, vous avez un problème.

Ensuite, vérifiez le code source de vos pages clés. Sur la version mobile, cherchez <link rel="canonical"> : elle doit pointer vers l'URL desktop correspondante. Sur la version desktop, cherchez <link rel="alternate" media="only screen and (max-width: 640px)"> : elle doit pointer vers la version mobile. Ces deux signaux doivent être symétriques et cohérents.

Quelles erreurs éviter lors de l'implémentation ?

Ne vous contentez pas de corriger la homepage. La duplication touche souvent des sections entières du site : fiches produits, articles de blog, pages catégories. Automatisez la génération de ces balises via votre CMS ou templates pour garantir la cohérence à l'échelle.

Autre erreur classique : corriger les canonicals mais oublier de mettre à jour les sitemaps XML. Si votre sitemap mobile continue de lister toutes les URLs m. comme canoniques, Google reçoit un signal contradictoire. Votre sitemap mobile devrait idéalement pointer vers les URLs desktop avec un attribut mobile alternate, ou disparaître complètement si vous passez en full responsive.

Comment vérifier que la correction est effective ?

Utilisez Google Search Console pour monitorer l'évolution. Dans la section Couverture, surveillez la baisse progressive des pages indexées sur le sous-domaine mobile. Ce processus prend entre 2 et 6 semaines selon la fréquence de crawl de votre site.

Testez aussi avec l'outil d'inspection d'URL : soumettez quelques pages clés de chaque version et vérifiez que Google identifie bien la version desktop comme canonique. Si ce n'est pas le cas après correction, cherchez des conflits dans vos headers HTTP ou vos redirections JavaScript.

• Vérifier les balises canonical sur un échantillon de 20-30 pages stratégiques (desktop et mobile)
• Auditer les sitemaps XML pour supprimer ou corriger les URLs mobiles en double
• Tester l'inspection d'URL dans Search Console pour confirmer que Google détecte la bonne version canonique
• Monitorer l'évolution du nombre de pages indexées sur m. vs www. via des recherches site: hebdomadaires
• Documenter les règles de génération des canonicals dans votre documentation technique pour éviter les régressions
• Si vous maintenez un sous-domaine mobile, planifier une migration vers un design responsive pour simplifier l'architecture à moyen terme