Fichier robots.txt : bonnes pratiques et erreurs à éviter

Un fichier robots.txt, c'est une ligne de texte. Deux, trois au maximum. Et pourtant, une seule de ces lignes mal placée peut vous coûter des semaines de trafic.

Je l'ai vécu. Pas en théorie : sur un site client, en pleine mise en production un vendredi après-midi. Le développeur avait copié le fichier du serveur de préproduction pour gagner du temps. Le lundi matin, Google avait commencé à désindexer. Deux semaines plus tard, on avait perdu près de 40 % des sessions organiques et il a fallu attendre presque deux mois pour retrouver le niveau de départ.

Le fichier robots.txt fait partie de ces éléments qu'on configure une fois puis qu'on oublie — jusqu'au jour où il casse quelque chose. Voici ce que j'ai appris à force de le manipuler, les bonnes pratiques qui tiennent vraiment, et les erreurs que je vois encore commises en 2026 sur des sites pourtant bien tenus.

À quoi sert vraiment le fichier robots.txt (et à quoi il ne sert pas)

Le principe est simple : un fichier texte déposé à la racine du domaine, qui donne des consignes aux robots d'exploration. Vous le trouverez toujours à la même adresse — votredomaine.com/robots.txt. Pas dans un sous-dossier, pas renommé robot.txt au singulier. À la racine, et nulle part ailleurs.

Ce que beaucoup découvrent trop tard, c'est la distinction entre explorer et indexer. Le robots.txt dit à Googlebot : « ne va pas voir cette URL ». Il ne dit pas : « ne l'affiche pas dans les résultats ». Nuance énorme.

Exploration et indexation : deux mécanismes distincts

Si vous bloquez une page via Disallow, Google ne la lit pas. Mais s'il trouve un lien vers elle ailleurs, il peut quand même l'indexer — sans contenu, juste l'URL — parce qu'il n'a pas pu voir le noindex que vous aviez placé dans le code. Résultat : une page vide dans les résultats, ce qui est souvent pire que tout.

La règle que je répète à chaque audit :

• Vous ne voulez pas qu'un robot explore une zone (panier, recherche interne, filtres à l'infini) → Disallow.
• Vous ne voulez pas qu'une page apparaisse dans les résultats → balise noindex ou en-tête X-Robots-Tag.
• Vous voulez les deux ? Alors laissez la page accessible à l'exploration, le temps que le noindex soit lu, puis seulement ensuite envisagez le blocage.

Franchement, c'est la confusion la plus coûteuse du domaine. J'ai vu des équipes passer des semaines à chercher pourquoi une page « bloquée » continuait à recevoir des clics depuis Google.

Un robots.txt n'est pas une serrure

Autre point qu'on m'oppose souvent en réunion : « mais on a mis un robots.txt, donc c'est protégé ». Non. Un robots.txt est une convention, pas un mécanisme de sécurité. Les moteurs légitimes le respectent ; les aspirateurs de contenu, les scrapers et les robots d'IA peu scrupuleux peuvent très bien l'ignorer.

Une page confidentielle, un espace d'administration, un document en préparation : protégez-les par mot de passe ou par restriction d'accès serveur. Le robots.txt reste une politesse technique, pas un verrou.

Les bonnes pratiques de rédaction d'un robots.txt

La syntaxe est minimaliste. Quelques directives, un format de chemins, et c'est tout. Mais les détails comptent.

La syntaxe de base, sans fioritures

Un fichier typique ressemble à ceci :

User-agent: *
Disallow: /panier/
Disallow: /recherche/
Allow: /panier/confirmation

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

Trois choses à retenir sur cette structure. D'abord, User-agent: * s'applique à tous les robots ; vous pouvez cibler un robot précis en le nommant (par exemple User-agent: Googlebot). Ensuite, chaque groupe de directives doit être séparé par une ligne vide — coller deux User-agent sans séparation produit un comportement que vous ne voulez pas. Enfin, la directive Sitemap n'appartient à aucun groupe : elle se place n'importe où, généralement en fin de fichier.

Un point que je vois souvent mal compris : les chemins sont sensibles à la casse. /Panier/ et /panier/ sont deux adresses différentes. Si votre CMS génère des URL en minuscules, n'écrivez pas la directive en majuscules en pensant couvrir les deux.

Un exemple de fichier robots.txt réaliste

Pour un site e-commerce classique, voilà ce que je recommande généralement :

User-agent: *
Disallow: /admin/
Disallow: /checkout/
Disallow: /panier/
Disallow: /*?tri=
Disallow: /*?filtre=
Allow: /produits/

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

Notez l'usage des jokers * pour cibler des paramètres d'URL qui génèrent des pages en pagination infinie. C'est un gain de crawl considérable : au lieu d'explorer des milliers de combinaisons de filtres, le robot se concentre sur les pages qui comptent. Sur un site que j'ai repris l'an dernier, ce simple bloc a fait baisser de près d'un tiers le nombre d'URL explorées par jour, tout en augmentant la fréquence de passage sur les fiches produit.

Les erreurs qui font vraiment mal

Toutes les erreurs de robots.txt ne se valent pas. Certaines sont cosmétiques. D'autres coûtent des mois.

L'erreur n°1 : le Disallow: / oublié après les tests

Vous préparez un nouveau site sur un serveur de préproduction. Pour éviter que Google n'indexe les pages en cours, vous ajoutez Disallow: / — la directive qui bloque tout le site. Le lancement arrive. Vous déplacez les fichiers. Le robots.txt suit. Et personne ne pense à retirer la ligne.

Le site est en ligne, il est beau, il est rapide, et Google refuse de l'explorer. Le trafic reste à zéro pendant des jours, parfois des semaines, avant que quelqu'un ne pense à vérifier.

Ce cas m'est arrivé une fois, en 2023, sur un lancement que je supervisais de loin. Il a fallu dix jours pour identifier la cause, puis trois semaines de plus pour que le crawl reprenne un rythme normal. Le coût ? Une perte estimée à plusieurs milliers d'euros de chiffre d'affaires, et une relation client sérieusement écornée.

La leçon que j'en ai tirée : ne jamais réutiliser un fichier de préproduction en production. Jamais. On repart d'un fichier vierge, rédigé pour l'environnement de production, et on le vérifie avant la mise en ligne.

Le fichier mal placé ou mal nommé

Le robots.txt doit être accessible à https://votredomaine.com/robots.txt, en HTTP 200. Si votre CMS le place dans un sous-dossier, s'il renvoie une erreur 404, s'il redirige vers une page de connexion — les moteurs l'ignorent. Et ils ne vous préviennent pas.

Sur WordPress, le fichier est virtuel par défaut : il est généré dynamiquement et n'existe pas physiquement sur le serveur. C'est pratique, mais cela signifie qu'on ne le trouve pas par FTP. Il faut passer par les réglages de lecture du site, un plugin dédié, ou un filtre dans le thème. Et là, surprise : certains plugins SEO écrasent silencieusement le fichier personnalisé, ce qui peut réintroduire des directives oubliées.

Les erreurs de syntaxe silencieuses

Une ligne mal écrite est ignorée sans message d'erreur. Les cas les plus fréquents que je rencontre :

• Disallow /panier/ sans les deux-points — la directive est purement et simplement ignorée.
• User-agent: googlebot en minuscules alors que le robot s'appelle Googlebot — la casse du nom de robot peut importer selon l'implémentation.
• Allow placé avant Disallow dans le même groupe — l'ordre des directives n'a pas d'importance en soi, mais la règle la plus spécifique l'emporte, ce qui piège ceux qui comptent sur l'ordre.
• Des commentaires mal fermés ou des caractères accentués dans les chemins.

Pour vérifier, il existe un test simple : l'inspection d'URL dans la Search Console de Google affiche le contenu du robots.txt tel que le moteur le voit. Si ce que vous voyez ne correspond pas à ce que vous avez écrit, vous savez qu'il y a un problème.

La vérification après déploiement : l'étape que tout le monde saute

C'est le point sur lequel j'insiste le plus en audit, et c'est systématiquement celui qui manque dans les procédures d'équipe. On rédige le fichier, on le déploie, on passe à autre chose. Grave erreur.

Une procédure de contrôle en quatre étapes

Voici ce que je fais désormais systématiquement, quel que soit le site :

1. Avant la mise en ligne, ouvrez l'URL /robots.txt en navigation privée sur l'environnement de préproduction. Vérifiez que le fichier s'affiche bien, en texte brut, sans redirection.
2. Après le déploiement en production, refaites exactement la même vérification. La page doit s'afficher à l'identique.
3. Passez par l'inspection d'URL de la Search Console pour confirmer que Google lit bien votre version. C'est la seule façon de voir ce que le moteur voit réellement.
4. Consignez le contenu du fichier quelque part — dans un ticket, dans un document d'équipe. Cela vous servira de référence si quelque chose change sans explication.

Quatre étapes. Quinze minutes. Et pourtant, sur les six derniers audits que j'ai menés, quatre sites sur six présentaient un robots.txt qui ne correspondait pas à ce que l'équipe pensait avoir déployé. Un plugin, un cache, une mise à jour de thème : les causes sont variées.

Comment trouver le fichier robots.txt d'un site

La méthode la plus directe : tapez l'adresse du site suivie de /robots.txt dans votre navigateur. Si le fichier existe et est accessible, il s'affiche en texte brut. Si vous obtenez une erreur 404, c'est qu'il n'y en a pas — ce qui n'est pas dramatique en soi, mais empêche de poser des règles fines.

Pour aller plus loin, certains outils d'analyse SEO permettent de voir la dernière version du fichier mise en cache par un moteur, ce qui est utile pour détecter un changement discret. Et pour vérifier qu'un robot particulier respecte bien vos directives, rien ne vaut un examen des logs serveur : vous verrez quelles URL ont été demandées, et par qui.

Robots.txt, meta robots, X-Robots-Tag : qui fait quoi

Trois mécanismes, trois usages. Les confondre mène aux erreurs décrites plus haut. Voici comment je les articule :

Mécanisme	Portée	Quand l'utiliser
robots.txt	Tout le site, par robot	Bloquer l'exploration de zones entières (admin, panier, recherche interne)
Meta robots (balise noindex)	Une page précise	Retirer une page des résultats tout en la laissant accessible aux robots
En-tête X-Robots-Tag	Une ressource non HTML (PDF, images)	Empêcher l'indexation de fichiers où l'on ne peut pas insérer de balise

Le point délicat : ces mécanismes ne se combinent pas toujours bien. Un noindex derrière un Disallow est invisible pour le robot, qui ne pourra donc jamais lire la consigne d'exclusion — et la page pourra rester indexée sans contenu. J'ai vu ce cas précis sur un site qui avait bloqué ses pages de tags en croyant qu'elles disparaîtraient des résultats. Elles y étaient toujours, un an plus tard, avec des titres vides.

Faut-il passer par un générateur de robots.txt ?

Les générateurs en ligne existent et dépannent. Ils posent quelques questions, cochent des cases, produisent un fichier prêt à copier. Pour quelqu'un qui n'a jamais écrit une directive, ça évite les erreurs de syntaxe basiques.

Mais franchement, pour un fichier de dix lignes, je trouve ça contre-productif. Le générateur produit des directives génériques qui ne correspondent pas à votre arborescence réelle. Vous allez devoir les adapter, donc comprendre la syntaxe de toute façon. Autant l'écrire directement, en regardant les zones de votre site que vous voulez réellement exclure.

Ce que je recommande à la place : un fichier écrit à la main, court, commenté, et vérifié. Cinq lignes bien pensées valent mieux que trente générées au hasard.

Une dernière chose. Ne cherchez pas à faire de votre robots.txt un outil de classement. Il n'améliore rien. Son seul rôle est de canaliser le budget d'exploration vers les pages qui méritent l'attention des moteurs. C'est déjà beaucoup. Et c'est précisément pour cette raison qu'une erreur dedans fait si mal : elle ne se contente pas de gêner, elle détourne les robots de ce qui compte.

Alors la prochaine fois que vous déployez, ouvrez ce fichier. Une ligne, deux minutes, et vous dormirez mieux.