Robots.txt : le guide complet pour le configurer efficacement

Il y a quelques années, j'ai été appelé pour diagnostiquer une chute brutale de trafic sur un site e-commerce. Le propriétaire était en panique : son chiffre d'affaires avait fondu de 60 % en deux semaines. On a passé en revue les mises à jour, les pénalités possibles, les problèmes techniques… Et puis j'ai eu l'idée de regarder le fichier robots.txt. C'était lui. Un plugin de cache, censé améliorer les performances, avait réécrit le fichier lors d'une mise à jour et bloqué l'exploration de tout le site. Une seule ligne. Disallow: /. Le site entier avait été déréférencé. Cette erreur, plus fréquente qu'on ne le croit, m'avait coûté une nuit blanche.

Ce fichier paraît anodin. Un simple document texte de quelques lignes, souvent ignoré jusqu'au jour où il se retourne contre vous. Pourtant, bien configuré, il peut devenir un outil de pilotage précis de l'exploration de votre site. Mal configuré, il peut être un désastre silencieux. Voici ce que j'ai appris à force de manipuler ces fichiers pour des dizaines de projets, avec mes erreurs et mes corrections.

Comprendre le rôle du robots.txt avant de le configurer

Le robots.txt est un fichier texte placé à la racine de votre site. Son rôle : indiquer aux robots d'exploration quelles URL ils sont autorisés à parcourir. Point. Ce n'est ni un outil de sécurité, ni un moyen d'empêcher une page d'être indexée, ni une solution pour masquer un contenu confidentiel.

L'erreur la plus courante que je vois, c'est de croire que Disallow: /page-confidentielle/ va la faire disparaître de Google. Faux. La page ne sera peut-être pas explorée, mais si elle est référencée ailleurs (un lien externe, un partage sur les réseaux sociaux), Google pourra quand même l'indexer. Pire : le contenu reste accessible à tout visiteur humain qui connaît l'URL. Si vous voulez protéger une page : pas de lien vers elle, mot de passe, balise noindex. Pas ce fichier.

L'autre confusion classique concerne la performance. Beaucoup de gens pensent que bloquer l'exploration d'un site entier est un bon moyen de réduire la charge serveur. Dans certains cas extrêmes, peut-être. Mais une règle Disallow: / est risquée : elle peut avoir des conséquences désastreuses sur la visibilité et le trafic si elle persiste. En vingt ans de pratique, je n'ai jamais vu un site dont la survie dépendait d'un robots.txt bloquant.

Enfin, un point que j'ignorais moi-même à mes débuts : le robots.txt n'est qu'une série de règles, pas une programmation. Les robots bien élevés (Googlebot, Bingbot) les respectent. Les autres, non. C'est une convention, pas une loi. Un robot malveillant, s'il est déterminé, peut ignorer vos directives et explorer tout ce qu'il veut, mot de passe ou pas.

Robots.txt, c'est quoi pour un non-technicien ?

Le fichier robots.txt est un document texte qui se trouve à la racine de votre site, par exemple www.monsite.fr/robots.txt. C'est un standard du web, inventé en 1994 pour réguler les débuts du bourrage d'exploration. Sa fonction première est de signaler aux robots automatiques les zones du site qu'ils ne doivent pas visiter. C'est un ensemble de règles simples, écrites en clair, que les moteurs de recherche consultent avant de parcourir votre site.

Pour vérifier la présence de ce fichier sur un site, tapez simplement son URL dans un navigateur. S'il existe, vous verrez son contenu s'afficher comme un document texte.

La structure de base d'un fichier robots.txt : règles simples et pièges

Un fichier robots.txt se compose de groupes de règles. Chaque groupe commence par la mention d'un user-agent (le robot concerné) et se poursuit par des directives. La syntaxe de base est simple :

• User-agent : le nom du robot (Googlebot, Bingbot, etc.). L'astérisque (*) désigne tous les robots.
• Disallow : l'URL ou le chemin à interdire d'exploration. Une ligne vide signifie aucune restriction.
• Allow : l'URL ou le chemin à autoriser, même si un Disallow englobant l'interdit.
• Sitemap : l'adresse de votre fichier sitemap.xml, qui aide les moteurs à découvrir vos pages.
• Crawl-delay : parfois reconnu, le délai entre deux explorations. Google l'ignore.

Exemple de fichier de base, celui que je mets en place pour la plupart de mes clients :

User-agent: *
Disallow: /admin/
Disallow: /private/

Sitemap: https://www.monsite.fr/sitemap.xml

Cet exemple laisse l'exploration libre, sauf pour deux répertoires. Il annonce aussi où trouver mon sitemap. Simple, propre. Pourquoi ne pas bloquer tout ce qui est inutile ? On y vient.

La vie serait belle si ça s'arrêtait là. Mais j'ai vu passer des fichiers d'une complexité absurde, avec des dizaines de règles qui se chevauchent, des chemins incorrects, des doublons. Parmi les pièges les plus fréquents :

• La distinction entre slash en début et fin de ligne. Disallow: /admin/ bloque le répertoire admin. Disallow: admin (sans slash) bloque toute URL contenant "admin" où qu'elle soit. Deux résultats très différents.
• La sensibilité à la casse. /Admin/ n'est pas /admin/. Sur certains serveurs, c'est pareil, mais pas sur tous.
• Le blocage accidentel de fichiers indispensables. JavaScript et CSS sont nécessaires pour que Google voie votre page comme un utilisateur la voit. Les bloquer, c'est rendre votre site quasiment invisible pour le rendu.

Prenons un exemple concret. Un client avait un fichier robots.txt pensé pour "nettoyer" l'exploration :

User-agent: *
Disallow: /js/
Disallow: /css/
Disallow: /images/

Résultat : le site était correctement indexé, mais son rendu avait chuté dans les résultats. Les pages s'affichaient par à-coups, sans style, avec des blocs d'erreurs. J'ai remonté le problème en quelques heures : les règles bloquaient le CSS et le JS, donc Googlebot ne voyait qu'une page blanche ou mal structurée. La correction a été immédiate : suppression de ces lignes. L'exploration a repris son cours normal et le trafic organique a fini par se rétablir. Une erreur de débutant qui a pourtant été faite par un développeur expérimenté.

Comment créer un fichier robots.txt simple en trois minutes

Pour créer un fichier robots.txt, ouvrez un éditeur de texte brut et écrivez vos règles. Enregistrez le fichier sous le nom exact robots.txt. Ensuite, déposez-le à la racine de votre site, là où vous mettez vos autres fichiers publics. L'adresse doit être accessible via votredomaine.com/robots.txt. C'est la localisation qui importe : il ne fonctionne que s'il est à la racine, pas dans un sous-dossier.

Si vous utilisez WordPress, un plugin de référencement (comme Yoast SEO ou Rank Math) peut générer ce fichier pour vous ou vous permettre de modifier le contenu existant via une interface. Attention aux plugins : certains réécrivent le fichier à chaque mise à jour, avec les conséquences que j'ai décrites. Vérifiez toujours après une mise à jour.

Configurer le robots.txt pour WordPress : les règles que j'applique

WordPress est le système de gestion de contenu que je rencontre le plus souvent. Voici le fichier de base recommandé par la majorité des experts, celui que j'utilise en fonction des besoins :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /cgi-bin/

Sitemap: https://www.monsite.fr/sitemap.xml

Ce fichier bloque les répertoires techniques que les visiteurs ne doivent pas voir, mais autorise un fichier spécifique dans /wp-admin/ : admin-ajax.php, souvent nécessaire pour le fonctionnement de certaines fonctions.

L'erreur que je commettais au début : bloquer /wp-includes/ et /wp-content/ par réflexe. Le premier est raisonnable (sauf pour certains fichiers JS). Le second est une catastrophe. Le répertoire /wp-content/ contient les images, les feuilles de style et les scripts de votre thème et de vos plugins. Le bloquer revient à cacher à Google l'essentiel du rendu de vos pages. Les images disparaîtraient des résultats de recherche.

Autre règle que j'applique : quand un site utilise un cache de pages (c'est le cas de la plupart), je n'ajoute aucune règle liée au cache. Les robots qui explorent voient la version en cache, ce qui est généralement ce que l'on veut. Les règles qui bloquent l'exploration après une mise en cache ne font qu'empêcher Google de voir les mises à jour.

Les directives avancées et les pièges à éviter à tout prix

Passons à des choses plus subtiles. Un jour, un de mes clients se plaignait que ses pages de recherche interne étaient indexées, ce qui polluait son index. Des centaines d'URL du type /recherche/?q=mot-clé apparaissaient. La solution simple : bloquer l'exploration des paramètres d'URL. Avec le robots.txt, on peut utiliser un caractère générique, l'astérisque :

Disallow: /recherche/

Cette règle bloque tout le répertoire. Mais dans certains cas, le paramètre est utilisé sur la page d'accueil ou sur des pages importantes. On peut alors utiliser une règle plus ciblée :

Disallow: /recherche?*

Ou, pour les sites de commerce avec des filtres :

Disallow: /boutique?*
Disallow: /*?sort=

L'astérisque est un caractère générique très utile, mais il faut savoir que certaines directives ne sont pas prises en charge de la même manière par tous les moteurs de recherche. Google et Bing, par exemple, ne supportent pas tous les caractères génériques dans la directive Disallow de la même façon. Il est prudent de tester.

Le piège le plus dangereux, celui qui m'a coûté cette nuit blanche évoquée plus haut, c'est la directive Disallow: /. Cette règle bloque l'exploration de tout le site. Une seule ligne à garder en tête pour ne jamais l'écrire sans réflexion. Si vous voulez mettre votre site en maintenance pour quelques heures et que vous ne voulez pas le voir indexé, c'est tentant. Résistez. Utilisez la maintenance à la place.

Autre piège : inclure des URL complètes dans les directives au lieu de chemins relatifs. Par exemple :

Disallow: https://www.monsite.fr/page-privee/

C'est une erreur. Le robots.txt attend des chemins, pas des URL complètes. La règle correcte est :

Disallow: /page-privee/

Mon client avait fait l'inverse. Googlebot ignorait la règle, et la page confidentielle était indexée en dépit du fichier. Il y a des recherches de fuite qui m'ont pris des jours.

Tester et valider son fichier robots.txt

Après toute modification, une étape s'impose : tester. Mon outil de référence est le testeur de robots.txt de Google Search Console (ou l'outil d'inspection d'URL). Il permet de simuler l'exploration d'une URL par Googlebot et de voir si elle est autorisée ou bloquée.

La procédure que je recommande :

1. Ouvrez le testeur de robots.txt (via l'Ancienne Search Console ou le nouveau rapport).
2. Collez l'URL que vous voulez vérifier.
3. Choisissez le user-agent (Googlebot ou Googlebot-Image, etc.).
4. Cliquez sur "Tester". L'outil affichera si l'URL est accessible, bloquée ou si Google ne peut pas la trouver.

Cet outil m'a souvent sauvé de catastrophes. Par exemple, pour un site de location de vacances, j'avais mis une règle Disallow: /calendrier/ pour éviter d'indexer les pages de calendrier de disponibilité. Le test a montré que la page /calendrier/maison-de-village/ était bloquée, mais que /calendrier/ (la page principale) l'était aussi. Or, cette page principale contenait des informations importantes que je voulais voir indexées. Un ajustement rapide a résolu le problème.

Autre point crucial : après toute mise à jour d'un plugin de cache ou de sécurité, ou après une restauration de site, vérifiez le fichier robots.txt. Je l'ai déjà dit, je le répète : c'est là que j'ai vu les erreurs les plus dévastatrices. Un plugin de référencement peut réécrire le fichier à votre place, ou un plugin de cache peut restaurer une version obsolète. Une vérification systématique après une mise à jour majeure évite des semaines de tracas.

Comment trouver le fichier robots.txt d'un site, et pourquoi c'est utile

Trouvez le fichier robots.txt d'un site est aussi simple que de taper son URL : https://www.le-site-en-question.com/robots.txt. Le navigateur affichera le contenu s'il existe. Pour mon propre site, je le vérifie régulièrement après chaque mise à jour. Pour un site concurrent, cela peut être une mine d'informations sur sa stratégie d'exploration.

J'ai passé beaucoup de temps à analyser les fichiers robots.txt de sites concurrents dans le secteur du voyage. C'était révélateur : l'un bloquait l'exploration de tous ses paramètres de recherche, un autre autorisait l'exploration de ses pages d'avis clients, un troisième ne bloquait rien du tout. J'ai pu ajuster mes propres stratégies en conséquence.

Le role du fichier dans le budget d'exploration

Pour les grands sites, le robots.txt joue un rôle dans la gestion du budget d'exploration, c'est-à-dire le nombre de pages que Googlebot va explorer sur votre site à chaque passage. Ce budget est limité. Il dépend de la popularité de votre site et de sa santé technique, mais il n'est pas infini. Un site qui perd son budget à explorer des pages de recherche interne ou des doublons verra ses pages importantes moins fréquemment explorées, ce qui peut ralentir leur indexation et leurs mises à jour.

C'est là que le robots.txt devient un outil de pilotage fin. Bloquer les URL de faible valeur (/recherche/, certains paramètres de filtre, les archives de tags qui créent du contenu dupliqué) permet de concentrer l'exploration sur les pages importantes. Voici un exemple concret : un site de recettes que j'ai optimisé avait des milliers de pages créées par des combinaisons de filtres (type de plat, temps de cuisson, saison, etc.). Chaque combinaison générait une URL unique /recettes/?type=gâteau&temps=30min, et chaque URL était explorée. En bloquant tous les paramètres de recherche dans le robots.txt, j'ai réduit l'exploration inutile de près de 30 %, respectant ainsi le budget d'exploration pour les pages de recettes elles-mêmes. Résultat : les nouvelles recettes étaient indexées en quelques heures au lieu de plusieurs jours.

Attention, je ne dis pas que le robots.txt est la seule solution pour ce problème. Les balises meta robots ou les paramètres dans Google Search Console peuvent être plus adaptés. Mais c'est un levier parmi d'autres, non négligeable.

Pour mesurer l'impact d'une modification de robots.txt sur l'exploration, je surveille, dans Google Search Console, le rapport de couverture et l'outil d'analyse des statistiques d'exploration (dans la version ancienne de l'outil). Ces rapports montrent le nombre de pages explorées par Googlebot sur votre site et le volume de données téléchargées. Si ces chiffres chutent après une modification, c'est peut-être que vous bloquez trop de choses.

Les limites du fichier robots.txt et les alternatives à connaître

Le robots.txt a des limites, et il faut les connaître pour ne pas en attendre l'impossible. J'en ai parlé, mais un récapitulatif ne fait pas de mal :

• Il ne garantit pas la confidentialité. Un contenu privé ne doit jamais être protégé par ce fichier.
• Il ne contrôle pas l'indexation. C'est la balise noindex qui est la référence dans ce domaine.
• Il peut être ignoré par des robots mal configurés ou malveillants.
• Il n'empêche pas la mise en cache des URL par Google.

Quand faut-il utiliser d'autres mécanismes que le robots.txt ? La réponse est simple. Si l'objectif est d'empêcher qu'une page soit dans l'index de Google, ne touchez pas au robots.txt. Utilisez une balise meta robots avec la directive noindex sur la page en question. Si l'objectif est de vous prémunir contre l'indexation d'un contenu dupliqué, envisagez le rel="canonical" vers la page d'origine, un outil souvent plus efficace. Si l'objectif est de limiter l'exploration, le robots.txt fonctionne. Si l'objectif est de bloquer l'accès à une ressource (un PDF, une archive, un fichier), utilisez un mot de passe ou les permissions du serveur.

Bien sûr, ces solutions se complètent souvent. Un fichier robots.txt bien construit, des balises meta noindex sur les pages sensibles et un fichier sitemap à jour forment un trio solide. Mais il faut savoir à quel moment utiliser chaque outil.

Configurer un robots.txt WordPress : pourquoi certaines règles échouent

Sur WordPress, il y a une spécificité qui explique pourquoi les règles d'un fichier robots.txt échouent parfois. Certains plugins de référencement proposent une interface pour éditer le robots.txt, mais ils appliquent leurs propres règles par-dessus les vôtres. Par exemple, un plugin de référencement peut ajouter des règles que vous n'avez pas écrites, ou supprimer celles que vous avez ajoutées, selon ses réglages internes.

Mon conseil : vérifiez toujours le contenu du fichier à la racine, via votre navigateur, après avoir modifié les réglages d'un plugin. Les plugins de cache, comme je l'ai dit, sont les pires ennemis du robots.txt : ils le réécrivent parfois à chaque purge du cache. C'est une leçon que j'ai apprise à mes dépens, et qui me rend paranoïaque à chaque mise à jour de plugin sur les sites que je gère.

Votre fichier robots.txt n'est pas un script

Une dernière chose, une idée qui me semble essentielle : le robots.txt n'est pas un langage de programmation. Il ne comporte pas de conditions, pas de boucles. C'est une série de règles simples, et il fonctionne mieux quand il reste simple. Les fichiers sophistiqués avec des dizaines de directives sont une source d'erreurs potentielle. Un fichier clair, commenté, qui ne bloque que ce qui doit l'être, est plus efficace.

Pour terminer, posez-vous une question. Quand vous avez rédigé ou modifié votre fichier robots.txt, avez-vous pris le temps de le tester ? Sur les dizaines de sites que j'ai audités, rares sont ceux où le fichier n'avait pas été modifié sans vérification. Cette petite vérification de deux minutes peut vous épargner une nuit blanche, une chute de trafic et un client en larmes. Je parle d'expérience.