robots.txt : fonctionnement et limites
Auteur : Rédaction Domeny.ForSale Publié le
En bref : robots.txt est un fichier texte public qui indique aux robots web quelles parties du site ils peuvent récupérer et lesquelles ils doivent éviter. Il aide à gérer l’exploration du site, mais ne protège pas les données et ne garantit pas la suppression d’une adresse des résultats de recherche. Ses règles ne s’appliquent qu’aux robots qui les respectent.
Où se trouve robots.txt et comment fonctionne-t-il ?
Le fichier robots.txt se place à la racine du site, à une adresse telle que https://example.com/robots.txt. Un robot, c’est-à-dire un programme qui visite automatiquement les pages, peut le lire avant de récupérer leur contenu. Les règles lui permettent de déterminer les chemins auxquels il peut accéder.
Les règles concernent un protocole, un hôte et un port précis. Le fichier accessible sur https://example.com ne régit pas automatiquement le comportement des robots sur https://boutique.example.com ni sur la version HTTP. Un sous-domaine qui nécessite ses propres restrictions doit avoir une configuration distincte.
L’absence du fichier, signalée par un code HTTP 404, soit « introuvable », signifie généralement qu’aucune restriction issue de robots.txt ne s’applique. Ce cas diffère d’une panne du serveur : des erreurs serveur lors de la récupération du fichier peuvent temporairement limiter l’exploration du site. Le traitement précis de ces erreurs dépend du robot.
Comment lire et rédiger les règles ?
Les directives de base forment un groupe : elles désignent un robot, puis définissent les chemins autorisés ou interdits. Voici un exemple de fichier :
User-agent: *
Disallow: /recherche/
Disallow: /travail/
Allow: /travail/exemple-public.html
Sitemap: https://example.com/sitemap.xml
Les différents éléments désignent :
User-agent— le nom du robot auquel les règles s’appliquent ; l’astérisque*désigne le groupe général.Disallow— un chemin dont le robot ne doit pas récupérer le contenu.Allow— un chemin autorisé, notamment pour définir une exception à un blocage plus large.Sitemap— l’adresse complète du plan du site, un fichier contenant la liste des adresses que vous souhaitez signaler au moteur de recherche.
Dans cet exemple, les robots doivent éviter les adresses commençant par /recherche/ et /travail/, mais peuvent récupérer le fichier public indiqué dans le répertoire de travail. Lorsque les règles Allow et Disallow se chevauchent, la norme donne la priorité à la correspondance la plus précise. Les chemins sont sensibles à la casse.
La directive Disallow: / bloque l’exploration de l’ensemble du site par les robots concernés par ce groupe. Une directive vide Disallow: n’instaure pas ce blocage. Cette petite différence provoque souvent de graves erreurs lors de la mise en ligne d’un site.
Si vous ajoutez un groupe pour un robot précis, consultez sa documentation pour connaître les règles de sélection des groupes. Ne supposez pas que ce groupe hérite automatiquement de toutes les restrictions définies sous User-agent: *.
Bloquer l’exploration ne signifie pas interdire l’indexation
La récupération des pages par un robot, aussi appelée exploration ou crawling, et l’indexation sont deux processus distincts. L’indexation consiste à analyser une page et à enregistrer des informations à son sujet dans la base du moteur de recherche, qui sert à produire les résultats de recherche.
Une adresse bloquée dans robots.txt peut tout de même apparaître dans les résultats, par exemple si le moteur la découvre grâce à des liens présents sur d’autres sites. Le robot n’a pas besoin de récupérer le contenu pour apprendre que l’adresse existe.
Lorsqu’une page accessible au public ne doit pas apparaître dans les résultats, on utilise généralement la directive noindex : une instruction placée dans une balise meta de la page ou dans l’en-tête HTTP X-Robots-Tag. Le robot doit pouvoir récupérer la réponse pour lire noindex. Un blocage simultané dans robots.txt peut l’en empêcher. Inscrire Noindex directement dans robots.txt n’est pas une méthode valide pour exclure des pages de Google.
Par exemple, une page de remerciement affichée après l’envoi d’un formulaire peut rester accessible aux utilisateurs et recevoir la directive noindex. En revanche, une interface contenant des données clients doit exiger une authentification et un contrôle des droits d’accès : une simple interdiction destinée aux robots ne protège pas son contenu.
Quand utiliser robots.txt ou une autre solution ?
Robots.txt peut être utile pour limiter l’exploration de résultats volumineux issus du moteur de recherche interne ou de nombreuses variantes de filtres. Il faut toutefois déterminer au préalable si ces adresses doivent apparaître dans les résultats de recherche et si les robots doivent y lire d’autres instructions.
Ne bloquez pas sans analyse les fichiers CSS et JavaScript nécessaires à l’affichage des pages. S’ils sont inaccessibles, le moteur de recherche peut avoir du mal à restituer correctement l’apparence et le contenu du site. Réduire le nombre de visites du robot ne suffit pas à améliorer la visibilité du site.
Le fichier robots.txt est public : n’y placez donc ni mots de passe, ni jetons, ni listes de ressources confidentielles. Pour protéger un environnement de test, utilisez une authentification ou des restrictions réseau. Un robot malveillant peut ignorer entièrement les interdictions publiées.
Comment déployer et vérifier le fichier en toute sécurité ?
Avant de modifier robots.txt, conservez une copie de la version actuelle. Effectuez ensuite ces quelques vérifications :
- Ouvrez
/robots.txtsur le domaine concerné et vérifiez que le serveur renvoie du texte brut, et non une page d’erreur ou un formulaire de connexion. - Préparez des adresses représentatives : la page d’accueil, une page produit, un article et un chemin à bloquer.
- Vérifiez quelles règles s’appliquent à ces adresses pour le robot concerné. Confirmez la syntaxe prise en charge dans la documentation officielle du moteur de recherche.
- Après la mise en ligne, contrôlez l’état du fichier dans les outils destinés aux propriétaires de sites, par exemple Google Search Console. Les robots peuvent en conserver une copie : une modification n’est donc pas toujours prise en compte immédiatement.
Si le site utilise un CMS ou une extension qui génère robots.txt, modifiez la configuration à sa source. Un fichier envoyé manuellement peut être écrasé ou remplacer la version générée automatiquement. Avant d’enregistrer les modifications, définissez précisément votre objectif : limiter l’exploration, exclure des pages des résultats ou protéger les données. Chacun nécessite un outil différent.
Voir aussi : Qu’est-ce que la 2FA ?
