Un client m'appelle un mardi matin, paniqué : depuis trois jours, son site de e-commerce a disparu de Google. Pas une pénalité, pas un message dans la Search Console. Juste... plus rien. Vingt minutes plus tard, on trouve. La stagiaire avait voulu bloquer une page de test, écrit une ligne dans le fichier robots.txt, et cette ligne disait Disallow: /. Tout le site. Un seul caractère de trop, et quatre mois de SEO partis en fumée.
J'ai vu cette erreur au moins six fois en agence. Je l'ai faite aussi, une fois, sur mon propre blog — une soirée entière à chercher pourquoi mes nouvelles publications ne se faisaient plus indexer. Le fichier robots.txt, c'est cette petite chose de rien du tout qui vit à la racine de votre site et que personne ne lit jamais. Sauf Googlebot. Et quand il tombe sur une bêtise, il ne prévient personne.
Points clés à retenir
- Le robots.txt contrôle ce que les crawlers peuvent explorer, pas ce qui apparaît dans les résultats de recherche.
- Un
Disallow: /mal placé peut exclure un site entier de l'index en quelques jours. - Le fichier doit se trouver à la racine exacte du domaine :
https://votresite.com/robots.txt. - Wildcards (
*et$) sont supportés par les robots majeurs, mais lus différemment selon les crawlers. - Bloquer une page via robots.txt ne la retire jamais des résultats si elle est déjà indexée.
- Préproduction et production doivent avoir des fichiers distincts — c'est la première cause de catastrophe.
Fichier robots.txt : les bonnes pratiques qu'on apprend après avoir tout cassé
Commençons par ce qui fâche. La plupart des guides vous expliquent la syntaxe. Moi, je vais vous expliquer pourquoi votre syntaxe parfaite ne vous protégera de rien, et ce qu'il faut faire à la place.
À quoi sert vraiment ce fichier
Le robots.txt est un protocole de politesse, pas un mur. Vous dites aux robots d'exploration ce qu'ils sont autorisés à parcourir, et eux décident d'obéir — ou pas. Googlebot suit les règles. Le crawler d'un scraper douteux s'en moque royalement. Ne comptez jamais sur ce fichier pour protéger des données sensibles. Un /admin/ planqué derrière un Disallow reste accessible à quiconque tape l'URL. Pour vraiment fermer la porte, c'est un mot de passe, pas une ligne de texte.
Ce que le fichier fait très bien, en revanche, c'est économiser votre budget de crawl. Sur un site de 40 000 pages, laisser Googlebot gaspiller son temps sur des filtres à facettes, des paramètres de tri et des pages de recherche internes, c'est autant de moins pour vos pages qui rapportent. Sur un ancien projet, j'ai nettoyé le robots.txt et bloqué une dizaine de familles d'URL paramétrées. En six semaines, la part de pages "Explorées, actuellement non indexées" a chuté — pas parce que Google aimait plus le site, mais parce qu'il visitait enfin les bonnes pages.
La syntaxe qui marche vraiment
Quatre directives suffisent dans 95 % des cas. Voici ce qu'un fichier propre ressemble à :
User-agent: *— la cible, ici tous les robotsDisallow: /panier/— à ne pas explorerAllow: /panier/vide/— l'exception qui passe avant le blocage, car la règle la plus spécifique l'emporteSitemap: https://votresite.com/sitemap.xml— l'emplacement de votre plan de site
L'ordre des lignes Allow et Disallow n'a aucune importance. Ce qui compte, c'est la longueur du chemin : la règle la plus longue gagne. C'est ce que la majorité des gens ratent, et ça produit des blocages involontaires.
Pour les motifs, deux symboles. L'astérisque remplace n'importe quelle séquence. Le dollar $ marque la fin de l'URL. Disallow: /?sort= bloque toutes les URL contenant ce paramètre ; Disallow: /*.pdf$ bloque les fichiers PDF, sans toucher à une page dont le nom contiendrait "pdf" au milieu. Franchement, ces deux-là couvrent presque tous mes besoins.
Et le Crawl-delay ? Oubliez. Googlebot l'ignore depuis des années — c'est le réglage de fréquence d'exploration dans la Search Console qui fait ce travail. Bingbot, lui, le respecte encore. Si vous le mettez, sachez qu'il ne s'applique qu'à une partie de vos visiteurs.
Le piège classique : un fichier vide bloque tout. Un Disallow: sans valeur autorise tout. Retenez la nuance, elle m'a coûté une après-midi.
Les erreurs qui coûtent cher (et comment les repérer avant qu'il ne soit trop tard)
Une ligne erronée se voit rarement. Elle se déduit. Quand le trafic organique chute d'un coup sec, la question à se poser n'est pas "quelle pénalité ?" mais "qu'est-ce qu'on a touché cette semaine ?".
Le naufrage silencieux du Disallow racine
Quatre mille pages désindexées en une semaine après un déploiement raté. Le développeur avait livré un gabarit de robots.txt de préproduction — celui qui bloque tout pour éviter que le site de test soit indexé — directement en production. Googlebot a obéi. Poliment. Le site a mis près de deux mois à revenir à son niveau antérieur.
La parade est simple : deux fichiers, deux environnements. Un robots.txt de prod qui n'a jamais de Disallow: /, et un pour la préproduction, protégé en plus par une authentification basique. Le jour où j'ai systématisé ce double fichier, on n'a plus jamais revu ce type d'incident.
Le fichier qui renvoie un 404 ou un 503
Si votre robots.txt renvoie une erreur 404, les crawlers considèrent qu'aucune restriction n'existe et explorent tout. Ce n'est pas dramatique, mais ce n'est pas l'intention. Le cas sérieux, c'est le 503 : pendant une maintenance ou un problème serveur, si votre fichier répond 503, les robots majeurs peuvent mettre en pause l'exploration. Attention — un 503 qui dure se traduit aussi par une désindexation progressive. À utiliser pour une maintenance planifiée courte, pas comme bouclier permanent.
Robots.txt et noindex : la confusion mortelle
Celle-ci revient à chaque audit. Un client veut retirer des pages de l'index. Il les bloque dans le robots.txt. Résultat : Google ne peut plus explorer ces pages, donc ne voit plus la balise noindex qu'elles contiennent, donc... les garde dans l'index. Cercle vicieux parfait.
| Objectif | Outil correct | Ce qui ne marche pas |
|---|---|---|
| Économiser le budget de crawl | Disallow ciblé dans le robots.txt | La balise noindex seule |
| Retirer une page de l'index | Balise noindex ou en-tête X-Robots-Tag | Blocage via robots.txt |
| Protéger une zone privée | Authentification serveur | Toute règle de robots.txt |
| Diriger vers la bonne version | URL canonique | Le robots.txt |
La règle est limpide : pour retirer, on laisse explorer et on dit noindex. Pour économiser, on bloque. Ne mélangez jamais les deux intentions.
Tester, vérifier, surveiller : le réflexe qui sauve
Il existe un testeur intégré à la Search Console — le rapport "Fichier robots.txt" — qui vous dit en direct si une URL est bloquée et par quelle règle précise. C'est l'outil que j'ouvre systématiquement après chaque modification. Trente secondes, et on évite le drame.
Comment trouver le robots.txt d'un site
Il est toujours au même endroit : la racine du domaine, nommé exactement robots.txt, tout en minuscules. Tapez simplement https://nimportequel-site.com/robots.txt dans votre navigateur. S'il ne s'affiche pas, il n'existe pas — ce qui signifie que tout est explorable. Je le fais souvent pour comprendre la stratégie d'un concurrent : ses lignes Disallow racontent ce qu'il juge sans valeur ou ce qu'il veut cacher.
Générateur de robots.txt : utile ou piège ?
Les générateurs en ligne sont pratiques pour poser une base quand on découvre la syntaxe. Je les déconseille pourtant pour tout site un peu établi. Ils produisent des fichiers génériques, bourrés de directives inutiles, et surtout — vous ne comprenez pas ce que vous collez. Or, la seule compétence qui compte ici, c'est de savoir lire ces cinq lignes. Un fichier de dix directives bien comprises vaut mieux qu'un fichier de quarante copié-collé.
Mon conseil, après avoir vu tant de dégâts : écrivez-le à la main. Cinq minutes. Puis testez-le.
Robots IA, environnements multiples : les cas qu'on ne voit nulle part
Une question m'arrive de plus en plus souvent en consultation : "et les robots des IA, on les bloque ?" Des crawlers comme GPTBot, ClaudeBot ou PerplexityBot sont apparus et aspirent le contenu à grande échelle. Techniquement, vous pouvez les exclure avec une règle User-agent dédiée.
Faut-il le faire ? Ça dépend entièrement de votre modèle. Un éditeur de presse qui vend des abonnements a tout intérêt à se protéger. Un site qui vit de sa visibilité a peut-être intérêt à être cité par ces outils plutôt qu'ignoré. Je n'ai pas de réponse universelle, et méfiez-vous de quiconque prétend le contraire. Ce que je sais, c'est que cette décision mérite d'être prise consciemment, pas par défaut.
Un dernier point technique qui m'a valu des sueurs : les sous-domaines. Chaque sous-domaine possède son propre robots.txt. Si votre site vit sur www et que vos images sont servies depuis un sous-domaine dédié, il vous faut un fichier sur les deux. J'ai déjà vu un blocage global sur un sous-domaine d'assets couper net l'affichage des visuels dans les résultats de recherche.
Le fichier robots.txt ne vous fera jamais monter dans les résultats. Il ne peut que vous faire descendre, et vite, quand il est mal écrit. C'est un outil défensif, pas offensif. Alors traitez-le comme un câble électrique : indispensable, puissant, et dangereux dès qu'on bricole sans regarder. La prochaine fois que quelqu'un vous propose de "juste ajouter une ligne pour bloquer ça", demandez-lui de tester dans la Search Console avant de déployer. Cette petite vérification a sauvé bien plus de sites que n'importe quelle astuce SEO.
