Gérer le fichier robots.txt correctement : le guide qui évite le chaos SEO

Un client m'appelle en panique un mardi matin : son site a disparu de Google du jour au lendemain. Pas une pénalité, pas de message dans la Search Console. Rien. Après vingt minutes à fouiller, je trouve la cause : une ligne Disallow: / ajoutée la veille par un développeur qui voulait "empêcher les robots de voir la préprod". Sauf qu'il l'a poussée en production. Trois jours de trafic envolés, et une bonne suée pour tout le monde.

Le fichier robots.txt, c'est ce petit document texte à la racine de votre site dont tout le monde parle et que presque personne ne vérifie vraiment. Bien géré, il guide les crawlers vers vos pages utiles. Mal géré, il peut couper votre référencement en deux heures. Voici comment le maîtriser sans y passer vos nuits.

Robots.txt, c'est quoi exactement ?

Un fichier texte brut, accessible à l'adresse votredomaine.com/robots.txt, qui donne des instructions aux robots d'exploration (Googlebot, Bingbot, et une flopée d'autres). Il indique quelles parties du site un crawler peut visiter, et lesquelles il doit laisser tranquilles.

Deux choses à comprendre tout de suite, parce que c'est là que 90 % des erreurs naissent.

Ce n'est pas un outil d'indexation

Bloquer une URL dans le robots.txt empêche le robot de lire la page. Ça ne l'empêche pas de l'indexer si d'autres sites la lient. Google peut afficher une URL dans ses résultats avec un titre et un extrait fabriqués à partir des liens entrants. Résultat : une page moche dans les résultats, alors que vous pensiez l'avoir cachée.

Pour exclure une page des résultats, la bonne réponse est une balise noindex ou une protection par mot de passe. Et attention au piège : si vous bloquez le crawl et posez un noindex, le robot ne pourra pas lire le noindex. La page restera indexée. C'est l'erreur classique du développeur pressé.

Un robot peut vous ignorer

Le fichier est une convention, pas une loi. Les crawlers des grands moteurs le respectent. Les scrapers, les outils d'IA sauvages et les aspirateurs de contenu, beaucoup moins. Si vous voulez vraiment protéger une zone, ça passe par de l'authentification côté serveur, pas par une ligne de texte.

La syntaxe, avec un exemple de fichier robots txt qui marche

Le langage est simple, mais il tolère mal l'à-peu-près. Un espace mal placé, une casse fantaisiste, et la directive est ignorée sans prévenir.

Voici un fichier que j'utilise comme base sur la plupart des sites que je gère :

User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /*?s=
Allow: /wp-admin/admin-ajax.php
Allow: /wp-content/uploads/

Sitemap: https://exemple.com/sitemap_index.xml

Les règles à connaître :

• User-agent cible un robot précis (* = tous).
• Disallow bloque un chemin. Disallow: / bloque tout le site.
• Allow rouvre une exception dans une zone bloquée. Toujours plus spécifique que le Disallow, sinon il ne sert à rien.
• Sitemap pointe vers votre plan de site. Une seule URL par ligne.
• Crawl-delay existe encore, mais Google l'ignore depuis des années. Bing le prend en compte. Ne comptez pas dessus pour ralentir un bot.

Les wildcards * (n'importe quelle chaîne) et $ (fin d'URL) sont acceptés par les grands moteurs. En revanche, ne mélangez pas plusieurs User-agent dans le même bloc : chaque bloc commence par une ligne User-agent et se termine à la suivante.

Les erreurs que je vois le plus souvent (et que j'ai commises)

Sur les trente derniers audits que j'ai menés, j'ai trouvé un problème de robots.txt sur sept sites. Pas des cas exotiques : les mêmes trois erreurs, en boucle.

Le Disallow global laissé en prod

L'histoire du début. Un site en préproduction bloqué intégralement, puis déployé tel quel. Ça arrive tellement souvent que je vérifie désormais systématiquement ce fichier avant chaque mise en ligne. Une commande, une minute, et vous évitez des jours de perte.

Bloquer les ressources dont Google a besoin

Bloquer /wp-content/ ou /assets/ est une tentation fréquente pour "économiser du crawl". Sauf que Googlebot a besoin de charger CSS et JavaScript pour comprendre la page. Si vous les bloquez, il voit une page amputée et rend un mauvais verdict de qualité.

Oublier les paramètres d'URL

Les sites e-commerce avec filtres génèrent des milliers d'URL à paramètres. Sans directive, le robot s'y engouffre. Sur une boutique que j'ai suivie l'an dernier, le crawl passait à 60 % du budget dans des pages de filtres sans intérêt. Une ligne Disallow: /*?filter= a ramené ce chiffre à 15 % en trois semaines. Les pages produits ont gagné en fraîcheur.

Comment tester et vérifier votre fichier

Ne déployez jamais une modification du robots.txt sans l'avoir testée. C'est mon seul dogme.

L'outil de test de la Search Console

Dans la Search Console, un outil dédié permet de coller une URL et de voir si Googlebot peut la crawler. Il affiche quelles règles s'appliquent, et signale les erreurs de syntaxe. Gratuit. Utilisez-le. Systématiquement.

Ce que les codes d'erreur serveur changent

Un point que peu de guides abordent, et qui compte : si votre robots.txt renvoie une erreur 5xx, Google considère qu'elle est temporaire et revient plus tard. Mais si le fichier est inaccessible de façon prolongée, ça peut finir par bloquer le crawl. À l'inverse, un 404 signifie "pas de fichier" : Google crawle tout, sans restriction. Si vous voulez interdire une zone, un 404 ne suffit donc pas.

Comment trouver le robot.txt d'un site

Il suffit de taper l'URL racine suivie de /robots.txt. Par exemple https://le-site-en-question.com/robots.txt. Réflexe utile pour analyser la stratégie d'un concurrent ou vérifier qu'une page est bien accessible. Attention à la faute fréquente : c'est robots, au pluriel, jamais "robot.txt".

Le cas WordPress

WordPress gère un robots.txt virtuel par défaut. Tant que vous ne créez pas de fichier physique à la racine, le CMS en génère un. Pratique, mais parfois gênant.

Par défaut, le fichier virtuel règle Disallow: /wp-admin/ avec une exception pour admin-ajax.php, et autorise le reste. Dans les réglages de lecture, vous pouvez cocher l'option pour décourager les moteurs d'indexer le site — utile quand vous construisez en local ou en préprod, dangereux si vous oubliez de la décocher.

Les plugins SEO et le fichier physique

Les plugins SEO type Yoast ou Rank Math proposent une interface pour éditer le contenu du robots.txt. Attention : si un plugin le gère, il prend la main sur le fichier virtuel. Créer en parallèle un fichier physique à la racine crée un conflit, et vous ne savez plus lequel s'applique. Choisissez une méthode et tenez-vous-y.

Robots.txt, noindex, sitemap : qui fait quoi

La confusion entre ces trois outils est la source d'erreurs la plus fréquente. Un tableau vaut mieux qu'un long discours.

Outil	Rôle	Effet sur l'indexation
robots.txt	Dirige le crawl	Indirect : une page non crawlé n'est pas lue, mais peut être indexée autrement
Meta robots noindex	Exclut des résultats	Direct : la page disparaît des résultats (une fois lue)
X-Robots-Tag (HTTP)	Équivalent du noindex, envoyé dans l'entête	Direct : utile pour les PDF et fichiers non-HTML
Sitemap	Liste les URLs à crawler	Aucun : facilite la découverte, pas l'indexation

Ma règle simple : le robots.txt sert à réduire le gaspillage de crawl et à cacher des zones sans intérêt (paniers, recherche interne, préprod). Le noindex sert à retirer une page des résultats. Mélanger les deux est le meilleur moyen de se retrouver avec une page bloquée au crawl et présente dans les résultats.

Créer un fichier robots.txt propre

Si vous partez de zéro, l'ordre des opérations compte.

1. Vérifiez qu'aucun fichier robots.txt n'existe déjà à la racine.
2. Rédigez vos directives en commençant par les chemins les plus critiques (admin, panier, paramètres).
3. Déclarez votre sitemap en pied de fichier.
4. Testez dans la Search Console avant publication.
5. Surveillez la couverture d'indexation dans les semaines qui suivent.

Un dernier détail souvent oublié : les commentaires. Une ligne # préprod à côté d'un Disallow vous évitera peut-être de reproduire l'incident du début. Les commentaires ne sont pas lus par les robots, mais par les humains qui vont repasser derrière vous.

Et si vous hébergez plusieurs environnements, n'utilisez jamais le même fichier pour la prod et la préprod. Un fichier par environnement, avec des directives différentes. Séparez physiquement les deux et vous aurez éliminé la moitié des accidents.

Un fichier, pas une politique

Le robots.txt est un contrat de politesse. Il dit ce que vous voulez bien laisser passer, et ce que vous préférez garder pour vous. Il ne fait pas le tri à votre place, il ne remplace pas une authentification, et il ne vous protège pas d'un scrapers mal intentionné. Ce qu'il fait bien, en revanche : économiser votre budget de crawl, éviter l'exploration de pages inutiles, et orienter les moteurs vers le contenu qui compte.

La prochaine fois que vous poussez une mise en ligne, tapez votre URL racine suivie de /robots.txt. Prenez trente secondes pour relire les directives. La panique de mon client un mardi matin n'arrivera peut-être pas à votre porte.