Le fichier robots.txt est un fichier texte placé à la racine d’un site web, qui indique aux robots des moteurs de recherche les parties du site qu’ils sont autorisés à parcourir. Il règle l’exploration, pas l’apparition dans les résultats de recherche : les deux se confondent souvent, à tort.
Une boutique en ligne qui vend du matériel de bricolage peut s’en servir pour écarter du crawl son dossier d’administration WordPress ou les pages générées automatiquement par chaque filtre de son catalogue (couleur, taille, prix), des adresses sans intérêt pour un client qui cherche une perceuse sur Google. Le fichier se dépose à la racine du domaine, à l’adresse exemple.fr/robots.txt : posé ailleurs, il n’est tout simplement jamais lu par les robots.
Table des matières
Ce que robots.txt ne décide pas
Bloquer une page dans ce fichier ne garantit pas son absence des résultats de recherche : c’est la balise noindex, posée sur la page elle-même, qui retire une adresse de l’index. Google le confirme dans sa documentation sur robots.txt : une page interdite d’exploration peut malgré tout être indexée si d’autres sites pointent vers elle, avec pour seule information visible son adresse et le texte des liens qui y mènent, puisque Google n’a jamais pu lire son contenu. Une page bloquée dans robots.txt n’est donc pas forcément une page invisible sur Google, ce qui surprend souvent au premier audit.
La syntaxe de base
Le fichier s’écrit en texte brut, sans mise en forme. Chaque bloc commence par une ligne User-agent: qui désigne le robot visé (* pour tous), suivie d’une ou plusieurs lignes Disallow: pour fermer un chemin et, au besoin, Allow: pour en rouvrir un à l’intérieur d’un dossier fermé. Une ligne Sitemap:, en fin de fichier, indique l’adresse complète du plan du site. Google documente cette syntaxe dans son guide de création du fichier robots.txt.
Un exemple minimal
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Sitemap: https://www.exemple.fr/sitemap.xml
Ce fichier ferme l’accès au back-office tout en laissant passer la requête technique qui fait fonctionner certains plugins WordPress, et il signale où trouver le plan du site. Pour le reste, chaque page reste ouverte par défaut : un robots.txt n’a besoin de lister que ce qu’il faut fermer.
L’erreur qui ferme tout le site
Le risque le plus fréquent se joue au moment de la mise en production. Un site en développement porte presque toujours un robots.txt qui ferme l’exploration à tous les robots, une ligne Disallow: / posée là pour que Google n’indexe pas une version de test. Quand ce fichier migre tel quel vers le site public, au lieu d’être remplacé par la version définitive, l’intégralité du site se retrouve fermée aux robots sans qu’aucune erreur ne s’affiche nulle part : les visiteurs continuent de naviguer normalement, mais Google cesse progressivement d’explorer les pages. Un robots.txt mal réglé peut donc faire disparaître un site entier des résultats de recherche sans qu’aucun message n’alerte personne, ce qui en fait un point à vérifier systématiquement après chaque mise en ligne.
robots.txt et crawlers IA
Le même fichier sert aussi à s’adresser aux robots qui nourrissent les IA génératives en explorant le web. Robots.txt y reste une demande, suivie par les robots qui respectent la norme et ignorée par les autres : pas une barrière technique. Le détail des deux approches, robots.txt pour commencer ou blocage plus strict au niveau du serveur, se trouve dans cet article dédié plutôt que repris ici.
Le fichier se vérifie en quelques secondes, à l’adresse exemple.fr/robots.txt, et mérite un œil à chaque audit SEO ou chaque changement d’hébergeur : un oubli à cet endroit coûte cher pour quelques lignes de texte brut.
Crédit photo : Pixabay / StockSnap.
