Pourquoi Google affiche-t-il parfois des URLs M-Dot dans les résultats desktop ?

Qu'est-ce que l'indexation mobile-first change concrètement ?

L'indexation mobile-first signifie que Googlebot crawle et indexe prioritairement la version mobile de votre site, même pour établir le classement dans les résultats desktop. Si vous utilisez une architecture M-Dot (versions mobile et desktop séparées sur des sous-domaines différents), Google découvre et indexe d'abord vos URLs m.exemple.com.

Le problème surgit quand vos redirections ne fonctionnent que dans un sens. Vous avez peut-être configuré une redirection desktop → mobile pour les utilisateurs mobiles, mais oublié l'inverse. Résultat : Google indexe m.exemple.com, et quand un utilisateur desktop clique, il atterrit sur la version mobile parce que le serveur ne renvoie pas de redirection 302 vers www.exemple.com.

Pourquoi Google n'utilise-t-il pas systématiquement l'URL desktop ?

Soyons honnêtes : Google affiche l'URL qu'il a indexée. Avec mobile-first, c'est souvent la version M-Dot. Si vos annotations rel=alternate/canonical sont correctes mais que vos redirections serveur sont absentes ou mal paramétrées, Google fait confiance à ce qu'il crawle réellement.

Le moteur ne va pas deviner qu'une version desktop existe ailleurs si votre serveur ne renvoie pas les signaux appropriés. C'est particulièrement problématique parce que l'URL affichée dans les SERPs devient celle que les utilisateurs voient et partagent, créant un effet domino de dilution de signaux.

Quels sont les signaux que Google attend pour éviter ce problème ?

Google attend une cohérence complète entre annotations HTML et comportement serveur. Côté HTML, vos pages desktop doivent pointer vers mobile via rel=alternate, et vos pages mobile doivent pointer vers desktop via rel=canonical. Mais ça ne suffit pas.

Côté serveur, vous devez implémenter des redirections 302 bidirectionnelles basées sur le user-agent. Desktop sur m.exemple.com ? Redirection 302 vers www.exemple.com. Mobile sur www.exemple.com ? Redirection 302 vers m.exemple.com. Sans cette couche serveur, les annotations HTML restent des suggestions que Google peut ignorer.

• Redirections 302 bidirectionnelles selon le user-agent (pas de 301, car temporaires par nature)
• Annotations rel=alternate sur desktop pointant vers la version mobile
• Canonical sur mobile pointant vers la version desktop
• Test avec différents user-agents pour vérifier le comportement réel du serveur
• Vérification dans Search Console que Google indexe bien les URLs desktop pour les requêtes desktop

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

Absolument. J'ai vu ce scénario se produire sur des dizaines de sites M-Dot mal configurés depuis le déploiement complet du mobile-first indexing. Le pattern est toujours le même : des développeurs qui pensent que les balises link rel suffisent, et qui découvrent trois mois plus tard que leurs URLs mobile squattent les SERPs desktop.

Ce qui est frustrant, c'est que Google ne signale pas ce problème clairement dans Search Console. Vous ne recevez pas d'alerte « Attention, vos URLs M-Dot apparaissent en desktop ». Il faut activement monitorer vos SERPs ou analyser les URLs indexées pour détecter le souci. Et c'est là que ça coince.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller parle de redirections « pas correctement implémentées », mais il faut être précis : le problème survient quand les redirections serveur sont absentes ou asymétriques. Si vous redirigez desktop→mobile mais pas mobile→desktop, Google indexera mobile et l'affichera partout.

Autre nuance : ce problème est spécifique aux architectures M-Dot. Si vous utilisez un responsive design ou du dynamic serving, vous n'êtes pas concerné — vous servez la même URL à tout le monde. C'est d'ailleurs une raison majeure pour laquelle Google pousse vers le responsive depuis des années. [A vérifier] : dans quelle mesure Google tente-t-il de « corriger » ce problème automatiquement s'il détecte une incohérence entre annotations et comportement serveur ? La documentation reste floue.

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

Si vous utilisez un responsive design ou du dynamic serving, vous êtes immunisé contre ce problème. Même URL, même HTML de base (avec adaptation CSS ou serveur), donc pas de risque de voir une version mobile squatter les résultats desktop.

Également, si vous avez migré d'une architecture M-Dot vers responsive mais que Google n'a pas encore recrawlé l'ensemble de votre site, vous pouvez temporairement voir des URLs M-Dot persister dans l'index. Dans ce cas, forcez le recrawl via Search Console et vérifiez que vos anciennes URLs M-Dot renvoient bien des 301 permanentes vers les versions unifiées.

Que faut-il faire concrètement pour éviter ce problème ?

Première action : tester vos redirections avec différents user-agents. Utilisez curl ou un outil comme Screaming Frog en mode custom user-agent. Visitez m.exemple.com avec un user-agent desktop (Chrome, Firefox) et vérifiez que le serveur renvoie une 302 vers www.exemple.com. Puis faites l'inverse : www.exemple.com avec un user-agent mobile doit rediriger vers m.exemple.com.

Deuxième action : auditer vos annotations HTML. Chaque page desktop doit contenir un <link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.exemple.com/page">. Chaque page mobile doit contenir un <link rel="canonical" href="http://www.exemple.com/page">. Aucune incohérence tolérée.

Comment vérifier que Google indexe les bonnes URLs ?

Utilisez la Search Console et filtrez par type d'appareil. Dans le rapport de couverture, vérifiez que les URLs indexées pour desktop correspondent bien à www.exemple.com et non à m.exemple.com. Si vous voyez des URLs M-Dot indexées, c'est un signal d'alarme immédiat.

Complétez avec une recherche site:m.exemple.com sur Google en mode desktop. Si des résultats apparaissent, c'est que Google indexe et affiche vos URLs mobile en contexte desktop. Inversement, testez site:www.exemple.com en mode mobile pour vérifier la cohérence inverse. Ces tests manuels sont rapides et révèlent immédiatement les failles.

Quelle stratégie adopter si vous êtes déjà en situation de crise ?

Si Google affiche déjà vos URLs M-Dot dans les SERPs desktop, ne paniquez pas et n'implémentez pas de 301 permanentes sur m.exemple.com vers www.exemple.com. Vous avez besoin de redirections 302 temporaires basées sur le user-agent, pas d'une redirection brutale qui casserait l'expérience mobile.

Implémentez les redirections bidirectionnelles, soumettez vos sitemaps desktop et mobile dans Search Console, puis demandez un recrawl des pages stratégiques. Surveillez l'évolution sur 2-3 semaines. Si Google persiste à afficher les URLs M-Dot, vérifiez vos logs serveur pour confirmer que Googlebot reçoit bien les redirections 302. Ces optimisations techniques peuvent être complexes à mettre en œuvre seul, surtout si votre infrastructure serveur implique plusieurs couches de cache ou de CDN. Dans ce contexte, faire appel à une agence SEO spécialisée peut vous éviter des erreurs coûteuses et accélérer la résolution du problème avec un accompagnement personnalisé sur votre stack technique spécifique.

• Tester les redirections 302 bidirectionnelles avec curl ou Screaming Frog (user-agents desktop et mobile)
• Vérifier la présence et cohérence des balises rel=alternate (desktop) et rel=canonical (mobile)
• Auditer Search Console pour identifier les URLs M-Dot indexées en contexte desktop
• Effectuer des recherches site: manuelles pour détecter les incohérences d'indexation
• Monitorer les logs serveur pour confirmer que Googlebot reçoit les bonnes redirections
• Soumettre les sitemaps desktop et mobile séparément dans Search Console