Comment déclarer une canonique pour un fichier non HTML ?

Un catalogue au format PDF se positionne sur les mêmes expressions que la page qui le présente, et finit par la remplacer dans les résultats. Le visiteur atterrit alors sur un document sans navigation, sans formulaire de contact et sans possibilité d'achat. Le réflexe consiste à chercher où placer une balise canonique, sauf qu'un PDF n'a pas de section d'en-tête HTML où l'écrire. La solution existe depuis longtemps et reste largement ignorée : la même déclaration peut voyager dans un en-tête HTTP, envoyé par le serveur avec le fichier, et les moteurs la traitent exactement comme son équivalent HTML. La mise en place tient en quelques lignes de configuration.

Pourquoi une canonique hors HTML

Le problème est mal connu parce que les fichiers échappent à la plupart des outils d'analyse, qui se concentrent sur les pages. Ils sont pourtant explorés, indexés et classés comme le reste. Le principe général de cette déclaration est expliqué dans notre article sur la balise rel=canonical comme solution anti-duplication.

Les fichiers qui s'indexent

Les moteurs indexent les documents PDF, les fichiers de traitement de texte, les tableurs, les présentations et une partie des formats d'archive dont ils savent extraire du texte. Un document déposé dans un répertoire accessible et lié depuis une seule page sera trouvé, exploré, puis proposé en résultat s'il répond à une intention. Il concurrence alors les pages du site sur les mêmes expressions, sans qu'aucune décision éditoriale n'ait été prise en ce sens, et souvent sans que personne ne s'en aperçoive avant plusieurs mois. Le repérage se fait en interrogeant le moteur avec une restriction sur le domaine et sur le type de fichier, manipulation qui prend trente secondes et révèle régulièrement plusieurs dizaines de documents dont personne ne soupçonnait la présence dans l'index.

Le cas des PDF dupliqués

La situation la plus fréquente est celle du document qui reprend intégralement le contenu d'une page : fiche technique, tarif, plaquette de présentation, notice. Les deux versions se disputent le même positionnement, et le moteur choisit celle qu'il juge la plus pertinente, souvent le document plutôt que la page. Ce choix est mauvais pour l'entreprise : le document ne convertit pas, il ne porte aucun élément de réassurance et son taux de rebond est par nature de cent pour cent, faute de tout lien de continuation. S'y ajoute un effet plus insidieux : le document ne porte aucune mention de date ni de mise à jour visible, si bien qu'un tarif périmé continue de circuler et d'être opposé par des clients longtemps après avoir été remplacé sur le site.

Les images et les documents bureautiques

Les images ne sont pas indexées pour leur texte mais apparaissent dans la recherche visuelle, où la page de rattachement compte. Les documents bureautiques, eux, sont pleinement indexés et posent souvent un problème supplémentaire : ils contiennent parfois des informations internes non destinées à la publication, dans les propriétés du fichier ou dans des zones masquées. La déclaration d'une canonique ne résout pas ce second point, qui relève d'un contrôle avant publication, mais elle traite au moins la concurrence de positionnement.

Ce que la balise HTML ne peut pas faire

La balise canonique est un élément de la section d'en-tête d'un document HTML. Elle n'existe donc pas dans un fichier binaire, et aucune propriété interne d'un PDF ne joue ce rôle, malgré ce que l'on lit parfois. Les métadonnées d'un document peuvent contenir une adresse, mais les moteurs ne les interprètent pas comme une déclaration de canonique. Toute solution passant par la modification du fichier lui même est donc vouée à l'échec, ce qui explique le nombre de tentatives infructueuses sur ce sujet.

L'en-tête comme équivalent exact

La spécification prévoit que les relations entre ressources puissent être exprimées dans un en-tête de réponse plutôt que dans le corps du document. Les moteurs traitent cette déclaration comme strictement équivalente à la balise, avec les mêmes règles de consolidation et les mêmes conditions de prise en compte. Elle fonctionne pour n'importe quel type de contenu, y compris pour les pages HTML, ce qui offre d'ailleurs une solution élégante lorsqu'on ne peut pas modifier le gabarit d'un site. Lorsque les deux déclarations coexistent sur une même page HTML et désignent des adresses différentes, le comportement n'est pas garanti, et il vaut mieux considérer cette situation comme une erreur de configuration à corriger plutôt que chercher laquelle des deux l'emporte.

Écrire l'en-tête correctement

La syntaxe est courte mais peu tolérante, et une déclaration mal formée est purement et simplement ignorée, sans aucun message d'erreur. Elle cohabite avec d'autres directives, notamment celle décrite dans notre article sur l'en-tête HTTP X-Robots-Tag.

La syntaxe attendue

L'en-tête se nomme Link et contient l'adresse cible entre chevrons, suivie d'un point virgule et de la déclaration de relation valant canonical. Les chevrons ne sont pas optionnels, l'espace après le point virgule est toléré, et la valeur de la relation peut être entourée de guillemets ou non selon les serveurs. C'est une ligne unique, sans retour, et toute variation dans la ponctuation suffit à rendre la déclaration invalide aux yeux d'un analyseur strict. Le même en-tête sert par ailleurs à déclarer d'autres relations, pagination ou versions linguistiques, ce qui autorise plusieurs déclarations séparées par des virgules, à condition qu'une seule porte la relation canonique.

L'adresse absolue obligatoire

Contrairement à la balise HTML, qui tolère les adresses relatives, l'en-tête doit contenir une adresse absolue complète, avec le protocole et le domaine. Une adresse relative y est ignorée, ce qui produit l'un des échecs les plus fréquents : la configuration paraît correcte, l'en-tête est bien présent dans la réponse, et pourtant rien n'est pris en compte. La vérification consiste simplement à s'assurer que la valeur commence par le protocole et non par une barre oblique.

Une seule cible par ressource

Déclarer deux canoniques différentes pour une même ressource annule les deux : le moteur constate la contradiction et ignore l'ensemble. Ce cas se produit lorsqu'une règle générale de configuration s'ajoute à une règle particulière sans la remplacer, ou lorsqu'un service intermédiaire ajoute son propre en-tête. La règle est donc de s'assurer qu'un seul en-tête de ce type est présent dans la réponse finale, celle que reçoit réellement le client, et non dans la configuration d'origine.

Cohabitation avec les directives d'indexation

Une ressource marquée comme non indexable et portant une canonique envoie un message contradictoire : le moteur est invité à consolider les signaux vers une autre adresse tout en étant prié de ne pas indexer celle ci. Le comportement observé est variable et peut aboutir à une désindexation de la cible dans certains cas. Il faut donc choisir : soit la ressource est canonisée vers une page, soit elle est exclue de l'index, mais jamais les deux à la fois.

Le cas des redirections

Un en-tête de canonique envoyé avec une réponse de redirection n'a aucun sens, la ressource ne contenant rien à consolider. Certaines configurations trop générales l'ajoutent pourtant à toutes les réponses, redirections comprises. Cela reste sans conséquence grave mais brouille les analyses, et cela signale généralement une règle écrite trop largement, qui mériterait d'être restreinte aux réponses en deux cents et aux seuls types de contenu réellement concernés.

Vérifier ce qui est réellement envoyé

La seule vérification qui vaut consiste à demander les en-têtes de la ressource depuis l'extérieur et à lire la réponse. Les outils en ligne de commande le font en une instruction, et les outils de développement des navigateurs affichent la même information dans l'onglet réseau. Cette vérification doit se faire sur l'adresse publique et non sur une adresse interne, un service intermédiaire pouvant ajouter, modifier ou supprimer des en-têtes sans que la configuration d'origine ne le laisse deviner. Il est également utile de refaire ce contrôle depuis un réseau extérieur à l'entreprise, certaines protections n'appliquant pas les mêmes règles selon l'adresse d'origine de la requête.

Mettre en place selon le serveur

La déclaration se pose au niveau du serveur web dans la quasi totalité des cas, ce qui la rend indépendante du système de gestion de contenu et donc très stable dans le temps.

Sur Apache

La directive d'ajout d'en-tête, encadrée par une correspondance sur l'extension de fichier, suffit à couvrir tous les documents d'un répertoire. Le module de gestion des en-têtes doit être actif, ce qui est le cas par défaut sur la plupart des hébergements. Pour une déclaration par fichier, une condition sur le nom exact permet de cibler précisément un document sans affecter les autres, méthode préférable dès que les cibles diffèrent d'un document à l'autre. Sur un hébergement mutualisé, la même directive fonctionne depuis le fichier de configuration local placé dans le répertoire concerné, sans intervention sur la configuration globale du serveur.

Sur Nginx

La déclaration se place dans un bloc de localisation ciblant les extensions concernées. Un piège classique guette ici : l'ajout d'un en-tête dans un bloc annule les en-têtes hérités du niveau supérieur, ce qui fait disparaître silencieusement des directives de sécurité mises en place ailleurs. La vérification complète des en-têtes de la réponse après modification est donc indispensable, et pas seulement celle de l'en-tête que l'on vient d'ajouter.

Depuis PHP

Lorsqu'un fichier est servi par un script, par exemple pour contrôler un accès ou compter les téléchargements, l'en-tête s'envoie avec les autres avant toute écriture dans le flux de sortie. Cette méthode offre la plus grande souplesse, la cible pouvant être calculée en fonction du document demandé. Elle suppose seulement qu'aucun caractère n'ait été émis auparavant, contrainte classique qui provoque un avertissement explicite lorsqu'elle n'est pas respectée. C'est aussi le seul montage qui permet de refuser l'accès direct au fichier tout en conservant une déclaration correcte, configuration utile pour les documents réservés à certains profils.

Derrière un service de diffusion

Un réseau de diffusion de contenus met en cache les réponses avec leurs en-têtes. Une modification de la configuration d'origine reste donc invisible tant que le cache n'a pas été vidé, ce qui explique bien des diagnostics erronés. Certains services permettent en outre d'ajouter ou de réécrire des en-têtes en périphérie, solution pratique lorsque l'accès au serveur d'origine est limité, à condition de documenter cette règle qui vit ailleurs que le reste de la configuration.

Sur un stockage objet

Les fichiers déposés sur un stockage objet portent leurs propres métadonnées de réponse, définies à l'envoi. L'en-tête doit donc être positionné fichier par fichier, au moment du dépôt, et il est perdu si le fichier est remplacé sans que la métadonnée soit reprise. Automatiser ce point dans le script de dépôt est la seule façon de garantir que la déclaration survive aux mises à jour de documents, qui sont fréquentes sur les catalogues et les tarifs. Un contrôle périodique comparant la liste des fichiers présents à celle des fichiers portant la métadonnée attendue permet de détecter les oublis sans avoir à faire confiance à la procédure.

Les décisions éditoriales à prendre

La technique est simple, l'arbitrage l'est moins. Chaque document mérite une décision explicite, et la canonique n'est pas toujours la bonne réponse.

Canoniser ou désindexer

Canoniser consolide les signaux vers la page cible et convient quand le document double un contenu existant. Désindexer retire simplement la ressource des résultats et convient quand elle n'a aucune valeur de recherche, comme un formulaire administratif ou une archive technique. Le critère de choix est simple : existe t il une page à laquelle rattacher ce document. Si oui, canonique. Si non, exclusion de l'index, éventuellement complétée par une restriction d'exploration. Attention toutefois à l'ordre des opérations : un fichier bloqué à l'exploration ne peut plus être lu, donc sa directive de non indexation ne sera jamais vue, et il peut rester dans les résultats sans description. La restriction d'exploration ne se pose donc qu'une fois la désindexation constatée.

Le document qui double une page

C'est le cas d'école : une fiche technique reprenant le contenu de la fiche produit doit pointer vers celle ci. Le document reste accessible et téléchargeable, il continue de servir les visiteurs, mais il cesse de concurrencer la page dans les résultats. Cette configuration est presque toujours la bonne pour les plaquettes commerciales, les tarifs et les notices, qui ont vocation à être consultés après avoir trouvé la page, et non à la place.

Le document sans équivalent

Un rapport, une étude ou un document de référence qui n'existe sous aucune autre forme n'a pas à être canonisé, puisqu'il n'y a rien vers quoi consolider. Il mérite en revanche une page de présentation qui le décrit, le contextualise et propose son téléchargement, page qui deviendra alors la cible naturelle. Cette page apporte du contexte, permet un suivi des téléchargements et donne un point d'entrée bien plus utile qu'un fichier isolé dans les résultats.

Les versions successives d'un document

Les documents datés, tarifs annuels, conditions générales, rapports périodiques, posent un problème particulier : les anciennes versions restent en ligne pour des raisons légales ou d'archivage tout en concurrençant la version courante. La canonique doit alors pointer de chaque version vers la page qui présente la version en vigueur, et non d'une version vers une autre. Chaîner les canoniques entre versions successives produit des consolidations imprévisibles et doit être évité.

Les fichiers joints aux articles

Sur un site de contenu, les documents joints aux articles gagnent presque toujours à être canonisés vers l'article qui les accompagne. La règle peut être posée une fois pour toutes au niveau du répertoire de téléversement, à condition que la structure permette de retrouver l'article de rattachement. Lorsque ce n'est pas le cas, une exclusion générale de l'index pour ce répertoire constitue une solution acceptable, et souvent préférable à une canonique approximative. Ce raisonnement rejoint celui que nous développons sur les fiches techniques PDF et leur optimisation.

Suivre l'effet

La prise en compte n'est pas immédiate : le moteur doit réexplorer chaque fichier, ce qui prend d'autant plus de temps que les documents sont rarement visités. Le suivi se fait en surveillant la disparition progressive des documents dans les rapports de couverture et leur remplacement par les pages cibles dans les résultats. Un délai de plusieurs semaines est normal, et il ne faut surtout pas conclure à un échec avant d'avoir vérifié que les fichiers ont bien été réexplorés depuis la modification. Le contrôle se fait dans le rapport de couverture, en filtrant sur le type de fichier concerné, et il vaut mieux noter la date de la modification pour savoir à partir de quand la lecture devient significative.