Comment tenir un fichier robots.txt sur un site volumineux ?

Le fichier robots.txt passe pour l'élément le plus simple du référencement technique, et c'est vrai tant qu'il compte cinq lignes. Sur un site de plusieurs milliers d'adresses, avec des filtres, une recherche interne, des exports et une dizaine de robots à distinguer, il devient un objet à part entière, que plus personne n'ose modifier parce que personne ne sait plus ce que chaque ligne bloque. Tenir un fichier robots.txt à l'échelle demande de connaître précisément les règles de correspondance, qui ne sont pas celles qu'on imagine, et d'accepter une discipline d'écriture qui rende le fichier relisible dans deux ans.

Ce que le fichier fait, et ce qu'il ne fait pas

La moitié des erreurs vient d'une confusion sur la nature même du dispositif. Le fichier contrôle l'exploration, pas l'indexation, et cette distinction a des conséquences très concrètes. Elle constitue un des points que nous vérifions en premier dans nos audits de la rubrique référencement naturel.

Interdire l'exploration n'empêche pas l'indexation

Une adresse bloquée peut parfaitement apparaître dans les résultats de recherche si d'autres pages pointent vers elle, avec un extrait absent et une mention indiquant que le contenu n'a pas pu être récupéré. C'est la conséquence directe du mécanisme : le robot ne peut pas lire la page, donc il ne peut pas y voir une directive de non indexation. Pour empêcher l'indexation, il faut laisser l'exploration possible et poser une directive dans la page ou dans les en têtes de réponse.

Les directives d'indexation n'ont rien à faire ici

Certaines lignes que l'on rencontre dans des fichiers anciens, prétendant interdire l'indexation directement depuis le robots.txt, ne sont plus prises en charge par Google, qui l'a annoncé explicitement lors de la formalisation du protocole (documentation Google Search Central). Elles sont simplement ignorées, ce qui laisse croire à une protection qui n'existe pas. Leur présence est un bon indicateur de l'âge du fichier et de la nécessité de le reprendre.

Aucune protection, aucune confidentialité

Le fichier est public et lisible par n'importe qui. Y déclarer les chemins d'une zone d'administration, d'un espace de préproduction ou d'un dossier de sauvegardes revient à publier une liste d'endroits intéressants. Une zone sensible se protège par une authentification, jamais par une interdiction dans un fichier que l'on invite tout le monde à lire. Les collecteurs les plus rudimentaires commencent d'ailleurs leur travail par la lecture de ce fichier, précisément pour y trouver ces indications.

Les robots qui l'ignorent

Le protocole repose sur la bonne volonté. Les grands moteurs le respectent, les aspirateurs de contenu et les collecteurs agressifs ne le respectent pas, et déclarer une interdiction ne changera rien à leur comportement. Le blocage réel de ces robots relève de la configuration du serveur ou d'un service de filtrage, pas de ce fichier, et confondre les deux fait perdre du temps sur un problème de charge serveur.

Un fichier par hôte

Chaque combinaison de protocole, de sous domaine et de port a son propre fichier, et celui du domaine principal ne s'applique pas aux sous domaines. Un site qui sert ses images depuis un sous domaine dédié doit donc y disposer de son propre fichier, faute de quoi aucune règle ne s'y applique. C'est un oubli courant lors de la mise en place d'un service de distribution de contenus. La déclaration du plan de site, en revanche, s'écrit en adresse absolue et peut désigner un autre hôte, ce qui en fait le seul élément du fichier qui franchisse cette frontière.

Ne jamais bloquer les ressources de rendu

Une pratique héritée des années deux mille dix consistait à interdire les dossiers contenant les feuilles de style, les scripts et les images, au motif qu'ils encombraient l'exploration. C'est aujourd'hui l'une des configurations les plus dommageables qui soient : le moteur rend les pages pour les évaluer, et une page rendue sans sa mise en forme ni ses images ressemble à un document cassé. Les conséquences vont d'une mauvaise appréciation de l'adaptation aux petits écrans à des contenus jugés absents parce qu'ils étaient chargés par un script bloqué. La règle est donc simple : tout ce qui est nécessaire à l'affichage doit rester accessible, y compris les ressources hébergées sur un sous domaine ou un service tiers, ce qui suppose de vérifier aussi le fichier de ces hôtes.

Les règles de correspondance, précisément

C'est le cœur du sujet, et l'endroit où l'intuition trompe le plus. Les règles ne sont ni évaluées dans l'ordre du fichier, ni cumulatives comme dans une configuration de serveur, ce qui surprend ceux qui abordent le sujet depuis la logique des redirections décrite dans notre article sur la manière de détecter les chaînes de redirections.

La règle la plus spécifique gagne

Face à une adresse, le robot retient la règle dont le chemin déclaré est le plus long, indépendamment de sa position dans le fichier. Une interdiction portant sur un dossier et une autorisation portant sur un sous chemin de ce dossier cohabitent donc parfaitement, l'autorisation l'emportant sur les adresses concernées. C'est ce qui permet de bloquer une famille entière tout en gardant quelques exceptions, sans avoir à énumérer ce que l'on autorise. Cette propriété est aussi ce qui rend le fichier difficile à relire : l'effet d'une ligne dépend de toutes les autres, et il faut les considérer ensemble pour raisonner juste.

En cas d'égalité, l'autorisation l'emporte

Quand deux règles de longueur identique s'appliquent, l'une autorisant et l'autre interdisant, c'est l'autorisation qui est retenue. Cette règle de départage est rarement connue et explique certains comportements jugés incohérents. Elle invite à ne jamais compter sur une égalité pour produire un effet, et à préférer une différence de longueur explicite quand l'intention doit être sans ambiguïté. C'est aussi une raison de ne jamais laisser deux règles contradictoires de même longueur dans le fichier, même si le comportement est défini : la prochaine personne qui le lira n'aura aucune idée de l'intention.

Le préfixe, pas le motif

Un chemin déclaré correspond à toute adresse qui commence par lui, sauf si un caractère de fin de chaîne est ajouté. Interdire un dossier bloque donc aussi tout ce qui commence par le même nom, y compris des adresses qui ne sont pas dans ce dossier. C'est une source d'effets de bord réguliers, et l'ajout d'une barre oblique finale au chemin déclaré suffit à restreindre la portée à ce qu'on visait. Le cas le plus fréquent concerne un dossier dont le nom est aussi le début du nom d'une rubrique éditoriale, bloquée sans que personne ne s'en aperçoive pendant des mois.

Les deux caractères spéciaux

Seuls deux caractères ont une signification particulière, largement pris en charge par les grands moteurs : l'un remplace n'importe quelle suite de caractères, l'autre marque la fin de l'adresse. Ils permettent de cibler par extension de fichier ou par présence d'un paramètre, ce qui couvre la plupart des besoins réels. Aucune autre syntaxe d'expression régulière n'est comprise, et les tentatives d'en écrire produisent des règles qui ne correspondent à rien. Ces règles inopérantes sont particulièrement traîtresses parce qu'elles ne provoquent aucune erreur et laissent croire que la famille visée est bloquée depuis des années.

Les paramètres et la casse

La correspondance porte sur le chemin et la chaîne de requête, et elle distingue les majuscules des minuscules. Une règle écrite en minuscules ne bloquera pas une adresse comportant une majuscule, situation fréquente sur les sites migrés depuis des systèmes qui n'y étaient pas sensibles. Sur les paramètres, l'ordre compte également : bloquer une combinaison précise ne bloque pas la même combinaison écrite dans un ordre différent. La parade consiste à cibler chaque paramètre indépendamment plutôt que des combinaisons, ce qui produit moins de règles et couvre bien plus de cas.

Les paramètres de navigation, cas d'usage principal

Sur un site volumineux, l'essentiel des règles finit par porter sur les adresses générées par la navigation : tris, filtres combinés, recherche interne, comparateurs, paniers. Ce sont elles qui multiplient les adresses sans produire de contenu original, et le fichier est l'outil le plus direct pour éviter que le robot ne s'y perde. Une précaution s'impose toutefois : bloquer l'exploration de ces adresses n'empêche pas leur indexation si elles sont liées, et surtout empêche le moteur de voir la balise canonique qu'elles portent. Sur des familles peu nombreuses et bien maîtrisées, la canonique est souvent préférable ; sur des familles qui se comptent en dizaines de milliers, le blocage reste la seule réponse tenable, quitte à supprimer par ailleurs les liens internes qui y mènent. Cette dernière précaution est la plus efficace des deux, un moteur ne pouvant explorer que ce qu'il découvre.

Organiser les groupes par robot

Sur un site volumineux, le fichier comporte souvent plusieurs groupes visant des robots différents. La logique de sélection du groupe applicable est simple mais stricte, et une erreur à ce niveau annule silencieusement toutes les règles qui suivent.

Un seul groupe s'applique

Chaque robot retient le groupe qui le désigne le plus précisément, et un seul. Un robot nommé explicitement dans un groupe ignore complètement le groupe générique, y compris les interdictions qui n'y sont pas répétées. C'est l'erreur la plus coûteuse du sujet : ajouter un groupe pour un robot particulier, afin de lui interdire une seule chose, revient à lui autoriser tout le reste que le groupe générique bloquait. Le contrôle est immédiat : pour chaque robot nommé dans le fichier, il faut lire son groupe comme s'il était le seul du fichier, et vérifier qu'il se suffit à lui même.

Regrouper plutôt que dupliquer

Plusieurs lignes d'identification peuvent précéder un même ensemble de règles, ce qui permet de traiter identiquement plusieurs robots sans dupliquer les directives. Cette forme est préférable à la copie, qui finit toujours par diverger. Quand un robot doit recevoir un traitement propre, la règle d'écriture consiste à repartir du groupe générique complet et à y ajouter la spécificité, plutôt qu'à écrire un groupe minimal. Le fichier gagne aussi à commencer par le groupe générique et à placer les groupes spécifiques ensuite, ce qui n'a aucun effet technique mais rend la lecture bien plus simple.

Traiter les robots des services d'intelligence artificielle

Plusieurs éditeurs publient désormais le nom des robots qui collectent des contenus pour l'entraînement de leurs modèles, distincts de ceux qui alimentent leurs moteurs de recherche. Les autoriser ou non est une décision d'entreprise, qui n'a pas de bonne réponse générale : bloquer préserve les contenus, autoriser maintient une présence dans des interfaces de plus en plus consultées. La décision doit être prise explicitement, notée avec sa date, et revue périodiquement, la liste des robots concernés évoluant vite. Il faut aussi savoir qu'un blocage dans ce fichier n'a aucune valeur juridique et ne remplace pas une mention dans les conditions d'utilisation du site, qui reste le seul document opposable.

Le délai entre requêtes

Une directive de temporisation est comprise par certains robots et ignorée par Google, qui gère son propre rythme. L'inscrire n'est donc pas nuisible mais ne règle rien pour le moteur principal. Quand la charge d'exploration pose réellement problème, la réponse se trouve dans les paramètres proposés par le moteur lui même et dans la santé du serveur, pas dans ce fichier. Le nombre de requêtes provenant réellement de chaque robot se lit dans les journaux du serveur, et c'est cette mesure, et non une impression, qui doit déclencher une intervention.

Tenir le fichier dans la durée

Un robots.txt de quarante lignes accumulées sur huit ans finit par contenir des règles dont personne ne connaît la raison, et que personne n'ose retirer. Quelques pratiques d'écriture suffisent à éviter cette situation, dans le prolongement de ce que nous détaillons dans notre article sur la manière de configurer un fichier robots.txt.

Commenter chaque règle avec sa date et son motif

Le fichier accepte les commentaires, et les utiliser systématiquement change tout. Une ligne indiquant pourquoi une règle a été ajoutée, quand et par qui, permet une revue annuelle où l'on retire ce qui n'a plus d'objet. Sans ces commentaires, chaque revue se termine par la conclusion prudente qu'il vaut mieux ne rien toucher, ce qui garantit que le fichier ne fera que grossir. Une convention de deux lignes par bloc, un commentaire puis la règle, rend cette discipline tenable même quand plusieurs personnes interviennent.

Générer plutôt qu'éditer à la main

Sur un site où les règles dépendent de la structure, il est plus sûr de produire le fichier à partir d'une source unique, un fichier de configuration ou un module du système de gestion, que de le modifier directement sur le serveur. Cette génération permet aussi de produire un fichier différent en préproduction, où l'on interdit tout, ce qui évite le scénario classique de l'environnement de test indexé par accident. Le fichier de préproduction doit être accompagné d'une directive d'indexation dans les en têtes de réponse, l'interdiction d'exploration ne suffisant pas à empêcher l'apparition des adresses dans les résultats.

Vérifier avant et après chaque modification

Le contrôle minimal consiste à disposer d'une liste d'adresses représentatives, une par famille, et à vérifier pour chacune si elle est autorisée ou bloquée, avant et après la modification. Des bibliothèques implémentant fidèlement le protocole existent dans la plupart des langages, ce qui permet d'automatiser ce contrôle en quelques lignes et de le placer dans la chaîne d'intégration, où il tourne à chaque livraison. C'est le seul moyen de modifier ce fichier sans appréhension. Les outils de test proposés par les moteurs rendent le même service pour une vérification ponctuelle, avec l'avantage de refléter exactement leur propre implémentation.

Surveiller son accessibilité

Un fichier absent est traité comme une autorisation générale, ce qui n'est pas dramatique. Un fichier qui répond une erreur serveur est en revanche interprété comme une interdiction totale par plusieurs robots, ce qui peut arrêter l'exploration du site entier. Cette situation, provoquée par une panne ou une mauvaise configuration, doit être surveillée au même titre que la disponibilité des pages, avec une alerte immédiate en cas de réponse anormale. Le contrôle doit porter sur le code de réponse et sur le type de contenu déclaré, un fichier servi comme document HTML par une page d'erreur personnalisée n'étant pas interprété correctement. Ce contrôle se place utilement dans la même routine que la surveillance des certificats, les deux vérifications portant sur des éléments invisibles dont la défaillance ne se remarque qu'après plusieurs semaines de dégâts.