Résumé

  • En février 2009, Google a permis aux sites de désigner, avec rel="canonical", l’adresse qu’ils préféraient parmi plusieurs pages presque identiques. L’annonce qualifiait cette indication de « signal fort », soumis à l’examen des autres indices. Le site proposait ; le moteur décidait.
  • Le RFC 6596, publié en 2012, a décrit le risque inverse : si la deuxième page d’un article renvoie à la première comme à sa version canonique, son texte propre peut être écarté du traitement. Une adresse bien rangée peut faire disparaître une partie du récit de l’index.

Le bulletin de vote du webmaster

Une boutique vend un seul produit, mais lui attribue plusieurs adresses. Un paramètre ajoute une catégorie, un autre suit une campagne, un identifiant suit la session. Le lecteur voit le même objet ; le moteur de recherche voit plusieurs pages. Dans son annonce du 12 février 2009, Google proposait de placer <link rel="canonical" href="..."> dans l’en-tête HTML des versions secondaires afin d’indiquer celle que le site souhaitait voir apparaître dans les résultats.

Le navigateur du lecteur n’était pas redirigé. Le message était destiné à l’index. Google expliquait que la popularité des liens et d’autres propriétés pouvaient être regroupées sur l’URL choisie. Puis venait la question décisive : ordre ou conseil ? « Un signal fort », répondait l’entreprise, examiné avec d’autres signaux. Le propriétaire connaissait les adresses produites par son site ; le moteur disposait de ses explorations, de ses liens et de ses regroupements. La déclaration donnait une voix au premier, pas le contrôle du dépouillement.

La chronologie limite également ce que l’on peut attribuer au lancement. Le texte initial permettait une désignation entre sous-domaines, mais pas entre domaines entièrement distincts. Pour une migration de domaine, il recommandait plutôt une redirection permanente. Une mise à jour datée du 17 décembre 2009 annonça ensuite la prise en charge entre domaines. Ces deux dates racontent une extension du dispositif, pas une capacité présente dès février.

La norme a défini la préférence, pas l’obéissance

En avril 2012, le RFC 6596 a décrit la relation canonical : une ressource indique une IRI préférée dont le contenu est identique ou plus complet. L’indication peut figurer dans le HTML ou dans un en-tête HTTP Link. Le document expose ce que les applications peuvent en faire : traiter uniquement la cible, lui attribuer des propriétés telles que la popularité des liens et afficher son adresse. Il définit une relation utilisable par les logiciels ; il ne leur retire pas le choix de l’appliquer.

Le cas d’un article réparti sur plusieurs pages met le danger à nu. La page deux contient un passage absent de la page un ; une version « tout lire » contient les deux. Renvoyer les pages séparées vers la version complète respecte la logique de contenu. Renvoyer la page deux vers la page un affirme une équivalence fausse. Le RFC avertit que le passage de la deuxième page risque alors d’être ignoré comme doublon. La page continue de répondre aux visiteurs, alors que sa contribution à l’index peut s’effacer.

Le même texte conseille une seule relation canonical par ressource et déconseille les cibles en erreur, en redirection permanente ou en chaîne. Face à une désignation incorrecte, l’application peut reprendre ses propres méthodes. La documentation actuelle de Google confirme que le moteur choisit un représentant d’après plusieurs signaux et peut retenir une autre URL que celle demandée par le site. Elle décrit la pratique actuelle ; l’annonce de 2009 avait déjà posé le principe de la préférence sans droit de veto.