C'est la question qu'on me pose à chaque audit, sans exception. Un client m'envoie son URL, je jette un œil au fichier robots.txt, et là, deux cas de figure. Soit il n'existe pas. Soit il existe et il bloque la moitié du site sans que personne ne s'en soit rendu compte. La deuxième situation est de loin la plus fréquente, et c'est aussi la plus coûteuse.
Un robots.txt n'est pas un document technique réservé aux développeurs. C'est une consigne que vous laissez aux robots d'exploration à l'entrée de chez vous. Mal écrite, elle fait fuir les visiteurs que vous vouliez justement accueillir.
Points clés à retenir
- Le robots.txt se place à la racine du domaine, jamais dans un sous-dossier.
- Il contrôle l'exploration, pas l'indexation. Ce sont deux choses distinctes.
- Un Disallow: / accidentel peut sortir un site entier de Google en quelques jours.
- Les robots respectent le fichier volontairement. Aucune loi ne les y oblige.
- La casse compte : Disallow s'écrit avec une majuscule, la valeur après les deux-points non.
- Un robots.txt en 404 n'arrête rien, mais prive Google de vos consignes.
Robots.txt, c'est quoi exactement ?
Concrètement, c'est un fichier texte brut, sans balise, sans mise en forme, posé à l'adresse votredomaine.fr/robots.txt. Un robot qui arrive sur votre site commence presque toujours par lire ce fichier avant de décider quoi explorer.
Le principe remonte à une convention des années 1990. Aucun texte de loi n'impose à un crawler de la respecter. Google, Bing et la plupart des moteurs le font parce que tout le monde y a intérêt. Un scraper mal intentionné, lui, s'en moque royalement.
Exploration ou indexation : la confusion qui coûte cher
Voici l'erreur numéro un. Bloquer une URL dans le robots.txt empêche le robot de la lire. Cela ne l'empêche pas de l'afficher dans les résultats de recherche.
Comment est-ce possible ? Parce qu'une page bloquée peut quand même être indexée si un lien externe pointe vers elle. Google connaît son existence, il ne peut juste pas en lire le contenu. Résultat : un titre, une URL, et rien d'autre dans les résultats.
Je l'ai vu sur un site e-commerce il y a quelques mois. Le responsable avait bloqué ses pages de catégorie pour économiser du budget de crawl. Trois semaines plus tard, ses catégories apparaissaient dans Google avec des descriptions vides et un aperçu de texte absurde. Il a fallu tout débloquer, attendre la réexploration, puis nettoyer les balises noindex mal posées en parallèle. Deux mois perdus.
Pour empêcher l'indexation, la bonne arme est la balise <meta name="robots" content="noindex"> ou un en-tête HTTP. Pas le robots.txt.
La syntaxe des directives, sans jargon
Un robots.txt tient en quelques lignes. Voici les quatre instructions que vous utiliserez réellement.
| Directive | À quoi elle sert | Exemple |
|---|---|---|
User-agent | Désigne le robot visé. * signifie « tous ». | User-agent: Googlebot |
Disallow | Interdit l'exploration d'un chemin. | Disallow: /admin/ |
Allow | Autorise explicitement un chemin, même si le parent est bloqué. | Allow: /admin/public/ |
Sitemap | Indique l'adresse de votre plan de site. | Sitemap: https://site.fr/sitemap.xml |
Deux caractères spéciaux valent la peine d'être connus. L'astérisque remplace n'importe quelle suite de caractères, et le symbole $ marque la fin d'une URL. La ligne Disallow: /.pdf$ bloque ainsi tous les PDF, quelle que soit leur position dans le site.
Un exemple de fichier robots.txt prêt à copier
Voici la structure que je pose par défaut, avant de l'adapter :
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /panier/
Disallow: /*?s=
Disallow: /*.pdf$
Sitemap: https://votresite.fr/sitemap.xmlChaque ligne répond à un besoin précis. Le dossier d'administration WordPress n'a rien à faire dans un index. La page de panier génère des milliers d'URLs quasi identiques. Les résultats de recherche internes créent du contenu dupliqué à l'infini. Et les PDF, s'ils sont nombreux, gaspillent le budget d'exploration pour un bénéfice souvent nul.
Un point que peu de gens vérifient : la ligne Allow placée après un Disallow plus large. Quand deux règles se contredisent, c'est la plus spécifique qui gagne. Cette subtilité sauve régulièrement le fichier admin-ajax.php, indispensable au fonctionnement de bien des extensions WordPress.
Comment trouver le robots.txt d'un site
Tapez simplement l'adresse du domaine suivi de /robots.txt dans votre navigateur. C'est tout. Pas de panneau d'administration, pas d'outil.
Trois résultats possibles s'affichent, et chacun raconte une histoire différente.
- Le fichier s'affiche. Vous lisez les consignes en clair. Normal.
- Erreur 404. Aucun fichier n'existe. Les robots explorent tout, sans restriction. Ce n'est pas dramatique, mais vous perdez la main.
- Erreur 500 ou 503. Le serveur répond mal. Selon les cas, les moteurs peuvent suspendre l'exploration pendant un moment.
Il m'arrive d'utiliser cette vérification comme premier réflexe lors d'un audit. Un concurrent qui bloque son propre sitemap, un site vitrine dont le dossier d'images est fermé alors que ces images sont visibles dans Google Images : ces incohérences se repèrent en dix secondes.
Comment tester un fichier robots.txt
Écrire le fichier est une chose. Vérifier son effet en est une autre. Les Search Console de Google et Bing disposent d'un outil de test qui simule le passage d'un robot sur une URL donnée. Vous saisissez l'adresse, l'outil vous dit si elle est bloquée, autorisée, et par quelle règle exactement.
Franchement, cet outil m'a évité plus d'une bourde. Sur un projet, une ligne Disallow: /* ajoutée par erreur bloquait tout le site. La simulation l'a affichée en rouge immédiatement. Sans ce test, je l'aurais découverte des semaines plus tard, une fois les positions perdues.
Pour aller plus vite sur un fichier long, un éditeur avec coloration syntaxique aide à repérer les valeurs oubliées après les deux-points. Une directive sans valeur est ignorée par la plupart des robots.
Robots.txt et WordPress
WordPress génère un robots.txt virtuel par défaut. Vous ne le voyez pas dans vos fichiers, il est fabriqué à la volée. Conséquence directe : si vous créez un vrai fichier robots.txt à la racine par FTP, il remplace le virtuel. Les deux ne cohabitent pas.
Plusieurs options s'offrent à vous, et le choix dépend de votre confort technique.
- Éditer le fichier physique par FTP ou via le gestionnaire de fichiers de l'hébergeur.
- Utiliser une extension SEO qui propose un éditeur dédié (Yoast, Rank Math) et qui écrit le fichier à votre place.
- Ajouter un filtre dans le thème enfant pour modifier le contenu généré sans toucher aux fichiers.
Mon avis, tranché : pour un site que vous gérez seul, l'extension suffit largement. Pour un site à fort trafic, préférez le fichier physique. Il survit aux mises à jour, aux changements de thème et aux extensions désactivées par erreur.
Faut-il des consignes différentes selon les robots ?
Oui, et c'est un point que l'on néglige souvent. Chaque robot a son identifiant. Googlebot pour Google, Bingbot pour Microsoft, et une série d'autres pour les aspirateurs de contenu qui alimentent les modèles d'intelligence artificielle.
Vous pouvez bloquer un seul d'entre eux sans toucher aux autres :
User-agent: [
Disallow: /
User-agent: *
Allow: /Attention toutefois. Bloquer un crawler d'IA n'a rien d'anodin en 2026. Cela réduit aussi votre visibilité dans les réponses générées par ces outils, qui citent de plus en plus souvent des sources web directement. C'est un arbitrage, pas une évidence. J'ai vu des sites gagner en trafic en s'ouvrant à ces robots, et d'autres perdre en contrôle éditorial en le faisant. À vous de trancher selon votre modèle.
Les erreurs qui font mal
Un Disallow: / isolé, sans rien d'autre, ferme tout le site. Une seule ligne. Le temps que quelqu'un s'en aperçoive, les pages disparaissent progressivement des résultats. Le délai de réaction compte plus que la gravité de l'erreur.
Autre piège : la casse. user-agent en minuscules n'est pas reconnu de la même manière que User-agent. disallow non plus. Les noms de directives sont sensibles à la casse pour la plupart des robots, contrairement aux valeurs qui les suivent. Une majuscule mal placée et votre règle tombe à l'eau, silencieusement.
Le fichier placé au mauvais endroit arrive aussi. Dans un sous-dossier, dans le dossier du thème, à la racine d'un sous-domaine au lieu du domaine principal. Un robots.txt qui n'est pas à la racine n'existe pas aux yeux des robots.
Et puis il y a la ligne oubliée après les deux-points. Disallow: sans valeur signifie « tout est autorisé ». Certains y voient une façon élégante de ne rien bloquer. Je préfère ne pas écrire la ligne du tout, c'est plus lisible.
Que faire si vous avez bloqué votre site par erreur
Corrigez le fichier immédiatement, puis déclenchez une réexploration depuis la Search Console. Ne comptez pas sur une remise en ligne automatique : il faut donner le signal.
Si le blocage a duré plus de quelques jours, attendez-vous à un délai avant que les positions ne reviennent. Les robots réévaluent, mais ils le font à leur rythme. Sur un site de taille moyenne, comptez plusieurs semaines pour un retour à la normale. Sur un gros site, davantage.
Le vrai remède est en amont : un système de sauvegarde du fichier, et une alerte quand son contenu change. Un simple contrôle mensuel de l'empreinte du fichier suffit. Je l'ai mis en place après ma propre bourde, et je n'ai plus jamais revécu ce moment de panique.
Ce qu'il faut vraiment retenir
Un robots.txt bien écrit ne fait pas monter un site dans les résultats. Il empêche simplement qu'il en disparaisse.
La prochaine fois que vous ouvrez le vôtre, posez-vous une seule question : chaque ligne bloquée correspond-elle à une vraie raison ? Si la réponse est non, supprimez-la. Un fichier court et lisible protège mieux qu'une liste longue dont personne ne se souvient de l'origine.
Et si vous héritez d'un site dont le robots.txt ressemble à une archive de décisions prises par cinq personnes différentes sur trois ans, ne cherchez pas à comprendre. Repartez de zéro. Vous gagnerez du temps.
