Comment configurer correctement les balises canonical et alternate pour un site m-dot ?

Pourquoi Google maintient-il encore cette configuration en 2023 ?

Parce que des milliers de sites utilisent encore une architecture séparée m-dot, même si le responsive et le mobile-first indexing dominent désormais. Cette déclaration de John Mueller rappelle les fondamentaux d'une config qui, bien que datée, reste active sur de nombreux sites legacy.

La logique est simple : Google doit comprendre que desktop.example.com et m.example.com sont deux versions du même contenu, et que la version desktop est la référence canonique. Sans cette configuration, risque de duplication, de cannibalisation et de dilution du signal SEO.

Quelle est la différence entre canonical et alternate dans ce contexte ?

Le rel canonical indique l'URL de référence à indexer. Le rel alternate signale l'existence d'une version alternative pour un contexte différent (ici, mobile).

Sur la version desktop, le canonical pointe vers lui-même (autodéclaration), tandis que l'alternate pointe vers m-dot. Sur m-dot, seul le canonical pointant vers desktop suffit — pas besoin d'alternate inverse, Google comprend le lien bidirectionnel.

Cette configuration est-elle encore pertinente aujourd'hui ?

Honnêtement ? Non, pour la plupart des projets modernes. Le responsive design avec mobile-first indexing a rendu cette architecture largement obsolète. Google crawle et indexe la version mobile d'un site responsive unique.

Mais si vous héritez d'un site m-dot — migration coûteuse, contraintes techniques, legacy lourd — cette config reste la référence officielle. Ignorer ces règles sur un site m-dot existant, c'est jouer avec la duplication.

• La version desktop est toujours la canonique dans une architecture m-dot
• Desktop porte rel="canonical" vers lui-même ET rel="alternate" media="only screen and (max-width: 640px)" vers m-dot
• M-dot porte uniquement rel="canonical" vers desktop
• Pas de rel alternate inverse sur m-dot — Google déduit la relation
• Cette configuration est obsolète pour les nouveaux projets (privilégier responsive)

Cette règle est-elle toujours appliquée par Google en pratique ?

Oui, et c'est vérifiable. Les sites m-dot qui respectent cette config voient leurs deux versions correctement traitées dans Search Console — desktop indexé, m-dot servi aux mobiles. Les erreurs de configuration (canonical manquant, alternate mal formé) génèrent encore des alertes dans la section "Couverture".

Cela dit, Google tolère certaines approximations. Un site m-dot sans alternate peut fonctionner si le canonical est propre et que les contenus sont suffisamment différenciés. Mais c'est du bricolage — autant faire les choses correctement si on reste sur cette archi.

Pourquoi Google ne recommande-t-il pas de migrer vers le responsive ?

Parce que Mueller répond ici à une question technique spécifique, pas à une stratégie globale. Google recommande évidemment le responsive ailleurs dans sa doc. Mais migrer un gros site m-dot coûte cher, prend du temps, comporte des risques.

Cette déclaration assume que certains sites restent en m-dot pour des raisons business légitimes. Ce n'est pas un blanc-seing pour maintenir une archi dépassée — c'est un mode d'emploi pour ceux qui n'ont pas le choix à court terme.

Quelles erreurs observe-t-on le plus souvent sur le terrain ?

La plus fréquente : un canonical croisé mal configuré. Desktop qui pointe vers m-dot au lieu de lui-même, ou m-dot qui s'autodéclare canonical. Résultat : Google indexe la mauvaise version, ou pire, oscille entre les deux.

Autre classique : l'attribut media oublié ou mal formé dans le rel alternate. Google peut alors ignorer l'indication et traiter les deux versions comme du contenu dupliqué distinct. [A vérifier] : certains sites avec alternate mal configuré semblent pourtant bien indexés, probablement grâce à d'autres signaux (sitemaps séparés, hreflang, user-agent detection).

Que faut-il vérifier sur un site m-dot existant ?

Commence par crawler les deux versions — desktop et m-dot — avec Screaming Frog ou un outil équivalent. Vérifie la cohérence des balises canonical et alternate sur un échantillon représentatif de pages : homepage, catégories, fiches produits, articles.

Checke ensuite Search Console : regarde quelle version Google indexe réellement, et si des erreurs de couverture apparaissent. Compare les sitemaps desktop et mobile — ils doivent lister les bonnes URLs respectives.

Comment corriger une configuration incorrecte ?

Si desktop pointe vers m-dot en canonical, inverse immédiatement. Desktop doit s'autodéclarer canonical. Si m-dot porte un alternate vers desktop, retire-le — seul le canonical suffit.

Assure-toi que l'attribut media="only screen and (max-width: 640px)" (ou équivalent) est présent sur le rel alternate côté desktop. Sans ça, Google peut ignorer l'indication.

Déploie les corrections par vagues si le site est gros — teste d'abord sur une section isolée, monitore l'indexation dans Search Console, puis généralise.

Faut-il envisager une migration vers responsive ?

Si le site m-dot fonctionne correctement, qu'il génère du trafic et des conversions, une migration n'est pas urgente. Mais si vous prévoyez une refonte — design, CMS, plateforme — c'est le moment idéal pour passer au responsive.

Le mobile-first indexing rend le m-dot de moins en moins pertinent. Google crawle et indexe la version mobile d'un site responsive, ce qui simplifie radicalement la gestion SEO : un seul contenu, une seule URL, une seule config.

• Crawler desktop et m-dot pour vérifier canonical/alternate sur toutes les typologies de pages
• Vérifier dans Search Console quelle version est indexée et si des erreurs apparaissent
• Corriger desktop : rel canonical vers lui-même + rel alternate media vers m-dot
• Corriger m-dot : rel canonical vers desktop uniquement
• Tester les corrections sur une section isolée avant déploiement global
• Monitorer l'indexation pendant 2-4 semaines après correction
• Évaluer l'opportunité d'une migration responsive lors de la prochaine refonte