Deux URL, un seul contenu, et un moteur qui doit choisir laquelle montrer. Le problème du canonical arrive souvent quand une version mobile et une version desktop se disputent la même requête, chacune avec ses liens et ses titres. La question que les internautes posent en premier n’est pourtant pas celle-là : ils veulent surtout savoir comment afficher la version bureau sur leur téléphone, ou l’inverse. Confondre les deux sujets mène à des arbitrages bâclés, et à une balise posée comme un pansement sur une architecture qui n’a jamais été pensée.
Le canonical tranche la référence, il ne bascule rien
Un bouton de bascule change ce que voit un visiteur. Le canonical change ce que comprend un robot. Ce sont deux gestes différents, sur deux plans différents, et les mélanger produit des sites où la version mobile déclare la version desktop comme référence alors qu’elle sert un contenu tronqué. Pour replacer la balise dans son contexte technique, les ressources de werankbox.fr détaillent les cas où l’arbitrage tourne mal, notamment quand les deux versions portent des balises title distinctes et des liens de navigation qui divergent.
L’arbitrage est éditorial avant d’être technique. Décider quelle version fait référence revient à décider quel contenu mérite d’être indexé, quel contenu porte la promesse éditoriale, quel contenu reçoit les liens externes. Si la version mobile affiche un résumé et la version desktop le texte complet, le canonical doit pointer vers celle qui offre le plus, pas vers celle qui reçoit le plus de trafic. Beaucoup de sites font l’inverse, par habitude ou par peur de perdre des positions.
Afficher la version mobile sur un ordinateur, sans se tromper
Les premiers résultats Google décrivent tous le même menu : ouvrir les outils de développement, activer l’émulation d’appareil, recharger. C’est utile pour voir le rendu, ça ne dit rien de ce que reçoit réellement un robot mobile. La différence compte, parce qu’un site peut servir un HTML différent selon l’agent qui se présente, via un redirect ou une détection côté serveur, et l’émulation du navigateur ne reproduit pas toujours cette logique.
Vérifier ce qui est vraiment servi
La méthode fiable passe par la requête elle-même. On envoie un appel HTTP avec un en-tête User-Agent mobile, puis on lit la réponse brute, sans moteur de rendu pour lisser le résultat. Ce qu’on cherche, c’est le code source initial, celui que le robot reçoit avant l’exécution du JavaScript.
- Ouvrez un terminal et lancez une requête avec un en-tête curl qui imite un iPhone récent, puis comparez la réponse à celle obtenue avec un agent desktop.
- Le code retour compte autant que le corps : un 301 vers une URL mobile signifie que la bascule est côté serveur, pas côté CSS.
- Et si les deux réponses sont identiques, que conclure ? Que le site est responsive, et que la question du canonical se pose différemment.
- Regardez ensuite la balise link rel=canonical dans chaque réponse, elle doit désigner la même URL des deux côtés.
- Un cache peut fausser la lecture, videz-le ou ajoutez un paramètre de requête pour forcer une réponse fraîche.
Cette vérification prend quelques minutes et évite des semaines de doutes. Elle montre aussi qu’un canonical incohérent entre les deux réponses est un signal de désaccord que le robot va interpréter à sa façon, souvent en ignorant la balise.
Récupérer la version bureau depuis un téléphone
Sur mobile, la bascule passe par le navigateur : un menu, une case à cocher, parfois une option cachée dans les réglages. Safari sur iOS la propose dans le menu de partage, Chrome sur Android dans les trois points. Ça marche, mais le résultat n’est pas la version desktop canonique dans tous les cas, puisque certains sites redirigent à nouveau selon la largeur de l’écran.
La vraie question derrière cette manipulation est ailleurs. Un visiteur qui force la version bureau sur son téléphone cherche souvent un contenu que la version mobile cache ou simplifie. Si ce contenu existe dans les deux versions mais disparaît sur petit écran, le canonical n’y changera rien : c’est un problème de parité de contenu, et c’est là que le référencement souffre. Un site qui sert moins de texte à un agent mobile qu’à un agent desktop crée deux pages réellement différentes, et le canonical devient une déclaration de préférence plutôt qu’une simple déduplication.
Peut-on faire confiance au canonical ?
Oui, à condition qu’il soit cohérent et qu’il ne contredise pas d’autres signaux. La balise reste un indice, pas un ordre, et les moteurs la recoupent avec le sitemap, les liens internes, le maillage externe et les redirections. Un canonical isolé, contredit par une redirection qui pointe ailleurs, sera ignoré sans prévenir.
Le doute vient souvent d’un cas mal ficelé : la version mobile se canonise elle-même, la version desktop aussi, et les deux se déclarent chacune référence. Dans ce cas, le moteur choisit seul, et son choix ne correspond pas toujours à celui qu’on espérait. Une règle simple tient en une phrase : une seule URL de référence par contenu, déclarée partout, y compris depuis les pages paginées et les versions imprimables.
La confiance se gagne aussi par la stabilité. Changer de canonical tous les mois, selon le trafic du moment, brouille le message. Et si un doute persiste sur la version servie, un outil d’inspection d’URL reste le juge de paix : il montre la version que le moteur a réellement indexée, pas celle qu’on croit avoir publiée. Franchement, ce contrôle vaut mieux que dix suppositions.
La convergence change la donne, pas la règle
Ubuntu a longtemps défendu une idée proche, avec un seul appareil qui fait tourner une interface tactile complète et une vraie expérience bureau. L’Aquaris M10 Ubuntu Edition, lancé avec le partenaire européen BQ, a été présenté comme le premier appareil entièrement convergé.
La plateforme revendiquait déjà l’expérience desktop préférée de plus de trente millions d’utilisateurs dans le monde, et Jane Silber, alors CEO de Canonical, portait ce discours. Les trois premiers modèles de téléphones Ubuntu s’étaient écoulés rapidement l’année précédente, et l’interface reposait sur des gestes du pouce depuis les quatre bords de l’écran.
Le parallèle avec le canonical saute aux yeux. Une seule source de contenu, plusieurs façons de l’afficher, et une référence unique qui doit rester la même quel que soit l’écran. Quand un site sert un contenu différent selon l’appareil, il ne converge pas, il duplique. Et c’est précisément là que la balise devient un arbitrage difficile à défendre devant un client qui voit deux designs et deux menus.
Une décision à assumer, pas à déléguer
Choisir la version de référence, c’est choisir ce que le site dit de lui-même. Le canonical n’est pas un réglage qu’on ajuste en fin de projet pour calmer une alerte de console : il fixe la version qui porte le contenu, celle que les liens externes viendront nourrir, celle que les visiteurs retrouveront dans les résultats.
Tant que cette décision reste floue, les bascules d’affichage ne feront que masquer le problème. Le jour où votre version mobile et votre version desktop racontent la même histoire, la balise cesse d’être un casse-tête et redevient une formalité. Votre référence actuelle, l’avez-vous choisie ou l’avez-vous subie ?
0 commentaire