Guide du fichier robots.txt pour les débutants : maîtrisez le SEO

Un fichier robots.txt mal écrit, c'est comme un panneau "sens interdit" planté devant votre propre entrée. Vous l'avez posé pour éviter les embouteillages, et vous avez coupé la route à tout le monde. J'ai vu ça sur un site de e-commerce : quatre semaines de ventes en chute, et le responsable qui cherchait le problème du côté de Google Ads pendant que le coupable était un simple Disallow: / oublié après une mise en maintenance. Le genre d'erreur qu'on ne fait qu'une fois. Encore que.

Ce guide part du principe que vous n'avez jamais ouvert un fichier robots.txt de votre vie. On va voir ce que c'est, où il se trouve, comment l'écrire sans se tirer une balle dans le pied, et surtout comment vérifier que vous n'avez pas bloqué ce que vous vouliez indexer.

Robots.txt, c'est quoi exactement ?

Un fichier texte. Rien de plus. Pas de balise HTML, pas d'en-tête, pas de code à compiler. Vous l'ouvrez dans un éditeur basique, vous écrivez des lignes, vous le posez sur le serveur. C'est tout.

Sa fonction : dire aux robots qui viennent visiter votre site quelles parties elles peuvent parcourir et lesquelles elles doivent laisser tranquilles. C'est le portier à l'entrée d'un immeuble. Il ne bloque pas physiquement la porte, il indique où aller. Un robot poli lit le panneau et respecte. Un robot mal intentionné, ou un scraper agressif, s'en fiche complètement.

Pourquoi cette convention existe

Les robots d'exploration ne sont pas des humains. Ils lisent votre site à vitesse industrielle, page après page, en suivant chaque lien. Si vous avez un espace d'administration, un panier, une zone de recherche interne ou des milliers de combinaisons de filtres, ils peuvent y passer des heures et saturer votre serveur. Le robots.txt sert d'abord à ça : économiser votre bande passante et orienter le budget d'exploration vers ce qui compte vraiment.

Ensuite, il y a la question du contenu. Une page de connexion, un dossier de sauvegarde mal rangé, un PDF interne : vous n'avez aucune raison de les voir apparaître dans les résultats de recherche.

Ce qu'un fichier robots.txt ne fait pas

Le malentendu le plus répandu, et je le vois encore régulièrement dans des conversations avec des webmasters : "j'ai mis la page en Disallow, donc elle ne sera plus dans Google". Faux.

Si une autre page fait un lien vers votre URL bloquée, le robot ne pourra pas lire la page pour voir qu'elle contient une consigne de non-indexation... mais il connaîtra son existence grâce au lien. Résultat : une URL peut se retrouver dans les résultats avec un titre et un extrait vides ou déduits d'ailleurs. Pour empêcher véritablement l'indexation, il faut une balise noindex dans la page, ou une protection par mot de passe.

Et si l'information est vraiment sensible, aucun robot.txt ni aucune balise ne suffit. Un mot de passe, point.

Comment trouver le fichier robots.txt d'un site

Tapez l'adresse du domaine suivi de /robots.txt dans votre navigateur. Par exemple https://exemple.com/robots.txt. Si le fichier existe, il s'affiche en texte brut. S'il n'existe pas, vous tombez sur une erreur 404.

Concrètement, ça donne souvent deux situations. Sur un site bien tenu, vous voyez quelques lignes propres, un Sitemap: en bas, et c'est réglé. Sur un site abandonné, vous tombez sur un fichier de trois ans, avec un Disallow qui bloque encore le dossier /beta/ alors que la version beta est en ligne depuis longtemps. J'ai déjà trouvé un Disallow: /wp-content/ sur un site WordPress en production. Le propriétaire ne comprenait pas pourquoi ses images ne remontaient pas dans la recherche d'images. Voilà.

Pour aller plus vite, deux raccourcis utiles :

• Sur votre propre site, passez par votre hébergeur ou votre client FTP pour ouvrir le fichier à la racine.
• Sur un site tiers, l'outil de test d'URL d'une console de recherche affiche le contenu du fichier sans que vous ayez à le lire ligne par ligne.

Créer un fichier robots.txt : la syntaxe pas à pas

Vous n'avez besoin que de quatre directives pour couvrir 90 % des besoins. Les voici, dans l'ordre où vous les écrirez.

User-agent : à qui s'adresse la règle qui suit. L'astérisque * signifie "tous les robots". Vous pouvez aussi viser un robot précis (Googlebot, Bingbot). Attention à la casse et à l'orthographe : un nom mal écrit et la règle n'est appliquée par personne.

Disallow : ce que le robot ne doit pas parcourir. La valeur vide (Disallow:) signifie "rien n'est interdit".

Allow : une exception à un Disallow, utile quand vous bloquez un dossier entier mais voulez laisser passer une page dedans.

Sitemap : l'adresse de votre plan de site. Ce n'est pas une directive officielle du protocole, mais tout le monde la reconnaît et elle aide.

Exemple de fichier robots.txt commenté

Voici un fichier que vous pouvez copier, adapter, et utiliser tel quel. Les lignes commençant par # sont des commentaires : elles ne sont pas lues.

Autorise tous les robots par défaut
User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /recherche/
Disallow:

Laisse passer la page contact même si tout /privé/ est bloqué
User-agent: *
Allow: /prive/contact/
Disallow: /prive/

Plan de site
Sitemap: https://votresite.com/sitemap.xml

Deux remarques sur ce bloc. D'abord, Disallow: tout seul à la fin d'un groupe est redondant — c'est l'état par défaut. Je l'ai laissé parce que beaucoup de gens le trouvent rassurant, mais vous pouvez l'enlever. Ensuite, l'ordre des lignes compte peu dans un même groupe, mais la règle la plus spécifique gagne : Allow: /prive/contact/ l'emporte sur Disallow: /prive/.

Les pièges du Disallow

La ligne la plus dangereuse de tout le fichier, c'est Disallow: /. Elle bloque l'intégralité de votre site. Une seule barre oblique. C'est cette barre qui a coûté quatre semaines de trafic à mon client e-commerce.

Autre piège classique : Disallow: / suivi d'un espace. Certains robots tolèrent, d'autres interprètent la valeur comme vide, donc "tout autoriser". Résultat : votre intention de bloquer produit l'effet inverse, et vous ne le saurez qu'en testant.

Les jokers fonctionnent aussi. remplace n'importe quelle suite de caractères, $ marque la fin d'une URL. Par exemple, Disallow: /.pdf$ bloque tous les PDF du site. Pratique, mais risqué si vous avez un PDF que vous vouliez laisser indexer.

Comment tester et valider votre fichier

Ne publiez jamais un robots.txt modifié sans l'avoir testé. Deux méthodes, l'une pour le diagnostic, l'autre pour la vérification réelle.

Le testeur de robots.txt d'une console de recherche vous permet de saisir une URL précise et de voir si elle est bloquée ou autorisée par vos règles. C'est le contrôle le plus rapide pour détecter une erreur de syntaxe ou un blocage involontaire.

Ensuite, l'inspection d'URL : demandez le rendu d'une page et vérifiez que ses ressources (CSS, JS, images) ne sont pas bloquées. Beaucoup de fichiers hérités de vieilles configurations bloquent /wp-includes/ ou /assets/ pour "économiser de la bande passante". Aujourd'hui, ça brise le rendu que les moteurs utilisent pour comprendre votre page. Mauvais plan.

Erreur de syntaxe fréquente : Disallow: / avec un espace final

Selon le robot, la valeur est perçue comme vide (donc tout autorisé) ou comme la racine (donc tout bloqué). Dans les deux cas, ce n'est pas ce que vous voulez. Supprimez l'espace.

Directives contradictoires entre plusieurs groupes

Si vous avez un User-agent: * qui interdit /dossier/ et un User-agent: Googlebot qui l'autorise, c'est ce dernier qui s'applique pour Googlebot. Vérifiez toujours quel groupe un robot donné va lire, et dans quel ordre.

Robot.txt sur WordPress

Point important : WordPress génère un robots.txt virtuel. Si aucun fichier physique n'existe à la racine, le système en sert un par défaut. Dès que vous créez un vrai fichier robots.txt à la racine via FTP, ce fichier prend le dessus et le virtuel disparaît.

Beaucoup de plugins SEO permettent d'éditer ce fichier depuis l'interface d'administration. C'est plus simple à modifier, mais ça garde la configuration dans la base de données, à un endroit que vous oublierez. J'ai vu des migrations de site où le fichier ne suivait pas parce qu'il était généré dynamiquement. Le nouveau site se retrouvait sans aucune règle, ce qui n'est pas dramatique, mais laisse passer les robots sur des zones qu'on voulait calmer.

Mon avis : si vous avez des besoins simples, le fichier physique est plus lisible et plus portable. Si vous avez des règles conditionnelles selon l'environnement, le plugin est plus souple.

Robots.txt, meta robots et X-Robots-Tag : quand utiliser quoi

On confond souvent les trois. Voici le tableau qui clarifie.

Mécanisme	Où ça se pose	Effet principal	Quand l'utiliser
robots.txt	Racine du domaine	Contrôle le parcours des robots	Zones entières à ne pas explorer (admin, panier)
Meta robots	Dans la balise <head> de chaque page	Contrôle l'indexation de la page précise	Page ponctuelle à ne pas afficher dans les résultats
X-Robots-Tag	En-tête HTTP, ou dans le PDF/image	Comme meta robots, mais pour les fichiers non HTML	PDF, images, vidéos à exclure de l'index

Retenez la règle simple : le robots.txt gère le crawl, la balise meta gère l'index. Ce n'est pas la même chose, et les mélanger produit des résultats contre-intuitifs.

Faut-il bloquer les robots IA ?

Depuis quelque temps, une question revient souvent dans les discussions entre webmasters : "est-ce que je dois bloquer GPTBot, ClaudeBot et compagnie ?" La réponse honnête : ça dépend de votre stratégie.

Bloquer ces robots, c'est refuser que votre contenu alimente les modèles d'entraînement. Vous gardez le contrôle, mais vous vous privez peut-être d'une visibilité dans les moteurs de réponse qui se développent en 2026. Autoriser, c'est l'inverse : plus de visibilité potentielle, moins de contrôle.

Techniquement, ça se fait simplement en ajoutant un groupe dédié dans le fichier :

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Vous créez un groupe par agent à bloquer. Aucune astuce particulière. Le nom exact du robot est à vérifier avant publication : un nom mal orthographié laisse passer le robot comme si de rien n'était.

Mon point de vue : pour un site de contenu qui vit de son audience, je ne bloquerais pas les robots IA par réflexe. Pour un site qui vend du contenu premium, la question mérite au moins d'être posée. Mais ce n'est pas un problème résolu par un fichier texte — la plupart de ces robots collectent aussi via d'autres canaux.

Avant de mettre en ligne : la checklist

• Le fichier est bien à la racine du domaine, nommé exactement robots.txt.
• Aucune ligne Disallow: / non intentionnelle.
• Pas d'espace parasite en fin de valeur.
• Le Sitemap: pointe vers une URL valide et accessible.
• Les ressources CSS et JS nécessaire au rendu ne sont pas bloquées.
• Les noms de robots des groupes spéciaux sont exacts.
• Vous avez testé après la dernière modification, pas la veille.

Un dernier mot sur les jokers : ne les empilez pas "au cas où". Chaque joker ajouté est une chance de blocage involontaire, et ce sera toujours plus cher à diagnostiquer qu'à écrire proprement la première fois. Je ne connais pas un seul webmaster qui regrette d'avoir été conservateur sur ce fichier. J'en connais plusieurs qui regrettent le contraire.