Faut-il encore utiliser rel=alternate et rel=canonical pour un site mobile en sous-domaine m. ?

Pourquoi Google maintient-il cette consigne sur les sites m. alors que le mobile-first est généralisé ?

La configuration en sous-domaine m. appartient à une époque où séparer mobile et desktop était la norme. Aujourd'hui, cette architecture est considérée comme obsolète par la majorité des praticiens SEO, mais elle persiste sur des millions de sites hérités, notamment e-commerce et éditoriaux.

Google rappelle ici les fondamentaux techniques : sans rel=alternate sur les pages desktop pointant vers m., et sans rel=canonical sur m. pointant vers desktop, le moteur peut traiter les deux versions comme du contenu dupliqué. Pire, il peut indexer préférentiellement la version m. même pour les requêtes desktop si les signaux de consolidation sont absents.

La déclaration des deux propriétés dans Search Console reste obligatoire. C'est le seul moyen d'avoir une visibilité consolidée sur l'indexation, les erreurs d'exploration et les Core Web Vitals des deux environnements. Sans cette double déclaration, vous naviguez à l'aveugle.

Quels risques concrets si les balises sont mal configurées ou absentes ?

Premier cas de figure : absence totale de balises. Google va devoir deviner quelle version indexer, généralement en favorisant m. depuis le passage mobile-first. Résultat : vos pages desktop peuvent disparaître de l'index ou être considérées comme secondaires, avec perte de ranking sur certaines requêtes concurrentielles.

Deuxième scénario : balises incohérentes. Par exemple, desktop pointe vers m. en rel=alternate, mais m. pointe vers une URL desktop différente en canonical (typo, paramètre manquant, redirection intermédiaire). Google va ignorer ces signaux contradictoires et traiter les deux versions comme indépendantes. Cannibalisation assurée.

Troisième problème : balises présentes mais non réciproques. Vous mettez du canonical sur m. mais oubliez l'alternate sur desktop. Google peut comprendre la relation, mais la consolidation sera partielle, avec des métriques fragmentées dans Search Console et des fluctuations de ranking inexpliquées.

Est-ce que cette configuration fonctionne encore efficacement en production ?

Sur le papier, oui. En pratique, c'est une source constante de friction. Toute modification structurelle (refonte, nouvelle catégorie, changement d'URL) impose de maintenir la cohérence sur deux arborescences distinctes. Les oublis sont fréquents, surtout dans les équipes où dev mobile et dev desktop ne se parlent pas.

Les performances sont aussi un enjeu. Charger deux versions complètes, même avec des balises propres, double les ressources crawl mobilisées par Googlebot. Sur un gros site avec des millions de pages, ça plombe votre budget d'exploration et retarde l'indexation des nouveaux contenus.

Enfin, la maintenance long terme est un cauchemar. Dès qu'une page m. tombe en 404, dès qu'un canonical pointe vers une redirection, dès qu'un paramètre UTM casse la correspondance, vous créez des erreurs en cascade qui nécessitent des audits réguliers et coûteux en temps.

• Balises rel=alternate et rel=canonical obligatoires pour toute configuration en sous-domaine m.
• Déclaration des deux propriétés dans Search Console indispensable pour un suivi consolidé
• Réciprocité stricte : chaque page desktop doit pointer vers son équivalent m. et inversement
• Risque de contenu dupliqué et de cannibalisation en cas d'erreur ou d'incohérence
• Architecture considérée comme obsolète mais encore massivement déployée sur des sites hérités

Cette déclaration est-elle encore pertinente face aux alternatives actuelles ?

Soyons honnêtes : Google maintient cette recommandation parce qu'il doit gérer l'existant massif. Des millions de sites tournent encore en m., notamment dans l'e-commerce legacy et la presse en ligne. Abandonner ces consignes serait créer un chaos d'indexation immédiat.

Mais la pertinence technique de cette architecture est discutable. Le responsive design résout tous ces problèmes en servant une seule URL avec un layout adaptatif. Pas de canonical, pas d'alternate, pas de double déclaration Search Console. Un seul fichier CSS media queries et c'est réglé. Le dynamic serving (même HTML, CSS différent selon user-agent) reste plus complexe mais évite aussi la duplication d'URLs.

La vraie question n'est pas "est-ce que ça marche ?", mais "est-ce que ça vaut le coup ?". Et la réponse est non, sauf si vous êtes coincé avec un legacy technique où refondre en responsive coûterait plus cher que de maintenir m. encore quelques années. Même dans ce cas, planifiez la migration, parce que ce setup devient un boulet.

Dans quels cas cette configuration échoue-t-elle malgré des balises correctes ?

Premier cas critique : contenu non équivalent entre desktop et m. Google s'attend à ce que les deux versions proposent le même contenu structurel. Si m. est une version édulcorée (moins de texte, images compressées à l'extrême, sections manquantes), les signaux de consolidation seront ignorés. Le moteur va considérer qu'il s'agit de deux pages distinctes et indexer les deux, avec ranking dégradé.

Deuxième problème : redirections intermédiaires. Si votre balise canonical sur m. pointe vers une URL desktop qui redirige elle-même (301 ou 302) vers une autre URL, Google peut perdre le fil. Les chaînes de redirections cassent souvent la transmission du signal canonical, surtout si elles traversent des sous-domaines ou des protocoles (http vers https).

Troisième souci : temps de réponse différentiel. Si m. est ultra-rapide et desktop rame à cause d'un CMS lourd, Google peut décider d'ignorer la version desktop et de privilégier m. comme source canonique de fait, inversant votre configuration. [A vérifier] dans vos logs serveur : si Googlebot Desktop crawle moins souvent que Mobile, c'est mauvais signe.

Quelles sont les observations terrain qui contredisent cette approche ?

Les audits montrent que 80% des sites m. mal configurés ne respectent pas la réciprocité stricte des balises. Alternate présent sur desktop mais canonical absent sur m., ou inversement. Google gère ces incohérences de façon imprévisible, avec des résultats qui varient selon le secteur et la concurrence.

Autre constat : même avec une configuration parfaite, les sites en m. sous-performent souvent en SEO par rapport à leurs équivalents responsive. Pas à cause d'un malus algorithmique, mais simplement parce que la maintenance de deux versions augmente la dette technique, ralentit les déploiements de nouveaux contenus, et fragmente les efforts d'optimisation.

Enfin, Search Console ne consolide jamais vraiment les données de façon satisfaisante. Vous aurez toujours deux rapports distincts, deux graphiques de performance, deux listes d'erreurs. Impossible d'avoir une vision unifiée sans exporter et croiser manuellement les données, ce qui est absurde en production à grande échelle.

Que faut-il faire concrètement si votre site tourne encore en sous-domaine m. ?

Première action : audit exhaustif de la correspondance alternate/canonical. Crawlez les deux versions (desktop et m.) avec Screaming Frog ou équivalent, exportez les balises, croisez les données dans un tableur. Chaque URL desktop doit avoir un alternate pointant vers m., et chaque URL m. un canonical vers desktop. Zéro exception, zéro erreur. Un seul oubli sur une catégorie stratégique peut coûter 20% de trafic organique.

Deuxième chantier : vérification des deux propriétés Search Console. Déclarez explicitement www.example.com et m.example.com comme propriétés distinctes. Activez tous les rapports (indexation, Core Web Vitals, liens, sitemaps). Comparez les courbes : si m. reçoit 90% du crawl et desktop 10%, vous avez un déséquilibre qui va finir par impacter le ranking.

Troisième point : homogénéité du contenu. Passez au crible une dizaine de pages clés (homepage, tops catégories, fiches produits best-sellers). Comparez mot pour mot le contenu textuel, les balises Hn, les images, les liens internes. Si m. propose une version simplifiée, soit vous enrichissez m., soit vous préparez une migration responsive.

Quelles erreurs critiques éviter dans cette configuration ?

Erreur numéro un : canonical auto-référent sur desktop. Certains CMS ajoutent automatiquement un canonical vers soi-même sur les pages desktop, en plus de l'alternate vers m. Techniquement pas incompatible, mais ça brouille les signaux. Google préfère voir un canonical uniquement sur m., pas sur les deux versions.

Erreur numéro deux : paramètres GET non gérés. Si vos URLs contiennent des paramètres de tracking (utm_source, session_id, etc.), assurez-vous que les balises alternate et canonical pointent vers les URLs canoniques sans paramètres. Sinon, vous créez autant de couples desktop/m. que de combinaisons de paramètres, et Google va s'y perdre.

Erreur numéro trois : oublier les balises sur les paginations et filtres. Page 2, page 3 d'une catégorie ? Filtres de prix ou de couleur ? Chaque variante doit avoir son alternate/canonical. Les oublis sur les paginations sont fréquents et génèrent du contenu dupliqué massif, surtout sur les gros catalogues e-commerce.

Comment vérifier que votre implémentation fonctionne réellement ?

Première validation : Google Search Console, rapport Couverture. Filtrez par propriété (desktop vs m.), regardez les pages indexées vs exclues. Si vous avez des milliers de pages m. en "Exclue par la balise canonical", c'est bon signe : Google consolide correctement. Si elles apparaissent en "Indexée, non soumise dans le sitemap", c'est mauvais, ça signifie qu'il les traite comme indépendantes.

Deuxième test : requête site: sur Google. Tapez site:m.example.com dans la barre de recherche. Idéalement, vous devriez voir très peu de résultats, voire aucun si la consolidation fonctionne parfaitement. Si vous voyez des centaines ou milliers de pages m. indexées, votre configuration est cassée quelque part.

Troisième vérification : logs serveur. Analysez la fréquence de crawl de Googlebot Desktop vs Googlebot Mobile sur les deux versions. Un ratio équilibré (50/50 ou 60/40) indique que Google explore activement les deux pour maintenir la correspondance. Un déséquilibre extrême (10/90) signale que le moteur a décidé de privilégier une version et ignore partiellement l'autre.

• Auditer la correspondance alternate/canonical sur 100% des URLs avec un crawler professionnel
• Déclarer et monitorer les deux propriétés (desktop et m.) dans Search Console séparément
• Vérifier l'homogénéité stricte du contenu entre les deux versions (texte, Hn, liens, images)
• Exclure les paramètres GET des balises alternate/canonical ou les gérer via balise rel="prev/next"
• Tester manuellement un échantillon de pages avec l'outil d'inspection d'URL de Search Console
• Planifier une migration responsive dès que les ressources le permettent pour éliminer cette dette technique