Faut-il vraiment rediriger les mobiles vers l'accueil quand la page n'existe pas en responsive ?

Pourquoi Google insiste sur ce point apparemment évident ?

La situation visée est celle des sites à double configuration : une version desktop (www.site.com) et une version mobile distincte (m.site.com). Quand un utilisateur mobile arrive sur une URL desktop dont l'équivalent mobile n'existe pas, certains sites redirigent automatiquement vers la home mobile.

Ce reflexe, apparemment logique, crée une rupture de parcours brutale. L'utilisateur cherche un produit précis, clique sur un résultat, et atterrit sur l'accueil. Il doit recommencer sa navigation depuis zéro. Google considère cette expérience comme suffisamment problématique pour la déconseiller officiellement.

L'alternative recommandée consiste à servir la version desktop telle quelle aux mobiles. Certes, l'ergonomie ne sera pas optimale — texte petit, navigation inadaptée, possibilité de zoom manuel — mais l'utilisateur accède au contenu qu'il cherchait.

Que se passe-t-il côté crawl et indexation ?

Googlebot mobile suit les redirections comme un utilisateur réel. Si chaque URL desktop spécifique redirige vers la home mobile, le bot constate une incohérence structurelle : des dizaines ou centaines d'URLs pointent toutes vers la même destination.

Ce pattern ressemble à un défaut technique ou, pire, à une tentative de masquer du contenu. Le moteur peut alors dévaluer le site mobile ou ignorer certaines annotations rel="alternate". La cohérence entre versions desktop et mobile devient opaque.

Dans quel contexte technique cette recommandation s'applique-t-elle encore ?

Parlons franchement : les sites M-dot (m.site.com) sont en voie d'extinction. Le responsive design a remplacé cette architecture bicéphale depuis des années. Mais Google continue de publier des guidelines sur le sujet parce que des milliers de sites legacy tournent encore sur ce modèle.

Si vous gérez un site récent, cette recommandation ne vous concerne probablement pas. Par contre, si vous héritez d'un vieux site e-commerce ou d'un portail média lancé avant 2015, vous risquez de tomber sur cette configuration. Les redirections automatiques vers la home mobile sont souvent codées en dur dans le .htaccess ou dans un middleware.

• Architecture M-dot : deux sites distincts, deux arborescences, gestion manuelle des équivalences URL
• Redirections par défaut : quand l'URL mobile n'existe pas, redirection automatique vers m.site.com
• Signal UX négatif : l'utilisateur perd le contenu cherché, taux de rebond immédiat
• Alternative Google : afficher la version desktop non responsive plutôt que rediriger
• Cas limite : si la page desktop est complètement inutilisable sur mobile (Flash, PDF lourd), la redirection vers une page explicative reste préférable à un écran vide

Cette déclaration reflète-t-elle vraiment les pratiques terrain observées ?

Oui, et c'est même une règle que Google applique avec cohérence depuis des années. Les audits de sites M-dot montrent systématiquement que les redirections massives vers la home mobile dégradent les performances dans la Search Console : taux de clics en baisse, pages mobiles non indexées, erreurs de correspondance entre annotations.

Ce qui est plus subtil, c'est que Google ne pénalise pas directement ces redirections. Le moteur constate simplement une rupture d'expérience utilisateur mesurable : temps passé faible, retour immédiat aux SERP, absence d'interaction. Ces signaux comportementaux suffisent à déclasser le site sans qu'aucun filtre manuel n'intervienne.

Quelles nuances faut-il apporter dans des cas réels ?

La recommandation de Google suppose que la version desktop reste fonctionnellement utilisable sur mobile. Si votre page desktop contient du Flash, des menus déroulants incompatibles tactile, ou charge 8 Mo de ressources, afficher cette version à un utilisateur 4G est pire qu'une redirection.

Dans ces cas limites, mieux vaut créer une page mobile interstitielle expliquant que le contenu n'est pas disponible en version mobile et proposant un lien vers la version desktop. Cette approche transparente vaut mieux qu'un atterrissage brutal sur l'accueil. [A vérifier] : Google n'a jamais publié de données chiffrées sur l'impact réel de ces redirections vs. affichage desktop sur le ranking mobile.

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

Si votre site est en responsive design (une seule URL, adaptation CSS/JS selon viewport), cette problématique n'existe tout simplement pas. L'URL est identique quel que soit l'appareil, donc aucune redirection possible.

Idem pour les sites en Dynamic Serving (même URL, contenu HTML différent selon User-Agent) : c'est le serveur qui choisit quoi afficher, pas de redirection côté client. La recommandation Google ne concerne strictement que les architectures M-dot avec URLs distinctes.

Que faire si mon site est encore en architecture M-dot ?

Première étape : auditer les redirections existantes. Prenez 50 URLs desktop aléatoires, testez-les avec un User-Agent mobile (Chrome DevTools, mode responsive). Si plus de 10% redirigent vers la home mobile, vous avez un problème.

Ensuite, modifiez la logique de redirection. La règle doit être : si équivalent mobile existe, rediriger vers lui ; sinon, servir la version desktop telle quelle. Techniquement, cela implique de maintenir un mapping URL desktop ↔ URL mobile à jour, ou de désactiver complètement la redirection par défaut.

Quelles erreurs critiques éviter pendant la correction ?

Ne mettez pas en place une redirection conditionnelle complexe qui teste l'existence de la page mobile en temps réel. Cela ajoute de la latence serveur et peut créer des timeouts. Mieux vaut générer un fichier statique de correspondances et le consulter en mémoire.

Évitez aussi de simplement retirer toutes les redirections sans prévenir : si des URLs mobiles existent et fonctionnent, les supprimer casse l'expérience des utilisateurs qui ont bookmarké m.site.com. La solution propre est une migration complète vers le responsive, pas un bricolage de règles .htaccess.

Comment vérifier que la configuration est correcte après correction ?

Utilisez la Search Console, section Couverture mobile. Google signale explicitement les redirections mobiles problématiques et les pages desktop servies aux mobiles. Si vous voyez des avertissements "Redirect erroné" ou "Page non disponible sur mobile", c'est là.

Testez aussi avec un crawler mobile (Screaming Frog configuré en Googlebot Smartphone). Vérifiez que les URLs desktop sans équivalent mobile retournent un code 200 (pas 302 ou 301) quand crawlées avec un User-Agent mobile. Le contenu HTML doit être celui de la version desktop, éventuellement avec un viewport meta tag pour améliorer le rendu.

• Auditer les redirections mobiles actuelles sur un échantillon représentatif d'URLs
• Désactiver les redirections par défaut vers la home mobile si aucun équivalent n'existe
• Maintenir un mapping précis des correspondances desktop ↔ mobile
• Vérifier les codes HTTP retournés pour User-Agent mobile (200 attendu, pas 301/302)
• Contrôler la Search Console pour identifier les erreurs de redirection signalées par Google
• Planifier une migration vers responsive design si le site M-dot devient ingérable