Guide complet pour créer un fichier robots.txt efficace

Créer un fichier robots.txt efficace : le guide qui va vous éviter des erreurs coûteuses

Vous avez un site web, vous avez entendu parler de ce fichier mystérieux, et vous vous demandez s'il faut vraiment s'y attarder. La réponse courte : oui, mais pas pour les raisons qu'on vous raconte partout.

J'ai passé des années à auditer des sites, et je peux vous dire une chose : la plupart des fichiers robots.txt que je croise sont soit inutiles, soit franchement dangereux. J'ai vu des sites entiers disparaître des résultats de recherche à cause d'une seule ligne mal placée. Une ligne. Ça fait froid dans le dos, non ?

Alors posons les bases tout de suite : le fichier robots.txt ne sert pas à empêcher l'indexation. Il sert à gérer le budget de crawl des moteurs de recherche. C'est la première distinction que 90% des gens ignorent, et c'est celle qui cause le plus de dégâts.

La vraie nature du robots.txt : un outil de gestion, pas une barrière

Quand j'ai commencé dans le SEO, je pensais que le robots.txt était une sorte de barrière infranchissable. Je me trompais lourdement. C'est plutôt un panneau de signalisation : il indique aux robots où ils peuvent circuler, rien de plus.

Un robot bien élevé (comme Googlebot) lira ce fichier et évitera les zones que vous avez signalées. Un robot malveillant, lui, s'en moquera éperdument. C'est important de le comprendre : ce fichier n'est pas un outil de sécurité. Si vous voulez protéger des données sensibles, cherchez autre chose. Beaucoup d'autres choses.

La directive la plus connue est `Disallow`, mais le fichier a évolué. Aujourd'hui, on y trouve aussi la déclaration du sitemap, des règles pour les robots d'intelligence artificielle, et parfois même des directives spécifiques à certains moteurs. Le tout avec une syntaxe précise qui ne pardonne pas l'erreur.

La syntaxe de base, expliquée simplement

Le principe est simple : pour chaque groupe de robots (User-agent), vous définissez des règles. Voici la structure minimale :

User-agent: *

Disallow: /admin/

Allow: /public/

Sitemap: https://www.votre-site.fr/sitemap.xml

Trois directives essentielles. Une pour dire à qui s'adressent les règles, une pour interdire, une pour autoriser, et une pour signaler le plan du site. On peut ajouter des commentaires avec le dièse (#), ce qui est très utile pour ne pas se perdre dans un fichier complexe.

Une chose que j'ai apprise à la dure : `Disallow: /` bloque tout. Le jour où un client m'a demandé "pourquoi mon site n'apparaît plus nulle part ?" après avoir "optimisé" son robots.txt, j'ai compris l'ampleur du problème. Il avait copié une ligne trouvée sur un forum, et boum, plus de visibilité du tout.

Le piège classique : confondre exploration et indexation

C'est l'erreur numéro un. Vous pouvez empêcher Google d'explorer une page avec `Disallow`, mais cela ne veut pas dire qu'elle ne sera pas indexée. Si la page reçoit des liens entrants, Google peut quand même la référencer, mais sans le contenu. Résultat : une page indexée avec un titre vide ou une description vide, ce qui est pire que pas de page du tout.

Pour réellement empêcher l'indexation, il faut utiliser `

` dans le code HTML de la page, ou l'en-tête HTTP `X-Robots-Tag`. On combine souvent les deux approches pour être tranquille. Mais honnêtement, dans la plupart des cas, le robots.txt ne devrait pas servir à "cacher" des pages. Il devrait servir à économiser le budget de crawl.

J'ai eu un client avec un site e-commerce qui avait un stock de 50 000 produits, dont 30 000 étaient en rupture. Son crawler gaspillait un temps fou sur ces pages mortes. En bloquant les paramètres d'URL inutiles et les pages de filtres, on a réduit le budget de crawl gaspillé de près de 60%. Les pages réellement importantes ont été crawlées plus vite, et les positions ont grimpé. Voilà un cas concret où le robots.txt devient un vrai levier SEO.

Pourquoi Google ignore certains de vos ordres (et comment réagir)

Google a des règles très précises. Par exemple, il ne respecte pas la directive `Crawl-delay`, qui vise à espacer les requêtes du robot. Bing et Yandex la prennent en compte, mais pas Google. Si vous définissez un `Crawl-delay`, Googlebot l'ignorera purement et simplement.

Autre subtilité : Google tolère le blocage des fichiers CSS et JavaScript dans une certaine mesure, mais cela peut dégrader la façon dont il rend vos pages. Si vous bloquez vos assets, vous risquez de voir des pages s'afficher sans style dans Google Cache, ce qui peut nuire à la pertinence perçue. Mon conseil : ne bloquez jamais CSS, JS ou images. Les bénéfices sont minimes, les risques réels.

Et puis il y a la limite des 500 Ko. Un fichier robots.txt ne doit pas dépasser cette taille, sinon Google tronque le reste. Pour un site standard, c'est largement suffisant, mais les gros portails doivent faire attention à ne pas écrire des règles à n'en plus finir.

Gérer les robots d'intelligence artificielle : le nouveau défi

Depuis 2024, la donne a changé. Les robots d'IA comme GPTBot, ClaudeBot, Google-Extended et consorts explorent le web à grande échelle pour entraîner leurs modèles. Et là, la question se pose : faut-il les bloquer ?

Mon avis personnel : oui, dans la plupart des cas. Vos contenus, c'est votre travail. Pourquoi les donner gratuitement à des entreprises qui vont les utiliser pour créer des produits concurrents ? Vous pouvez tout à fait bloquer ces robots tout en laissant Googlebot tranquille.

La syntaxe est simple :

User-agent: GPTBot

Disallow: /

User-agent: ClaudeBot

Disallow: /

User-agent: Google-Extended

Disallow: /

Je le dis sans détour : bloquer ces robots n'aura, dans la grande majorité des cas, aucune incidence sur votre trafic ou vos positions. En revanche, cela vous protège contre l'utilisation non consentie de vos contenus. C'est une décision que j'ai appliquée sur mes propres sites, et je n'ai jamais vu le moindre impact négatif.

Tester son robots.txt : la méthode que personne n'explique

Vous avez écrit votre fichier, vous l'avez mis en ligne. Et maintenant ? Beaucoup de gens s'arrêtent là. C'est une erreur.

La première chose à faire, c'est de vérifier que le fichier est accessible à l'URL attendue : `https://www.votre-site.fr/robots.txt`. Pressez-vous, c'est la première vérification. Ensuite, vous pouvez utiliser l'outil de test robots.txt dans Google Search Console. Collez le contenu de votre fichier, saisissez une URL à tester, et l'outil vous dira si la page est explorable ou non.

J'ai aussi une méthode maison que j'utilise pour mes clients : je simule un crawl avec des outils comme Screaming Frog (oui, c'est un outil de crawl, mais il se comporte comme un robot). Vous configurez l'agent utilisateur, et vous lancez. Si des pages importantes apparaissent comme "bloquées" et que ce n'est pas voulu, vous avez un problème.

Une anecdote qui m'a marqué : un client avait ajouté une règle pour bloquer les paramètres de tracking, mais il avait mal formulé la règle. En testant, j'ai découvert que sa page de contact était également bloquée, depuis des mois. Sa page de contact ! Celle-là même qui recevait ses leads. Il aurait pu passer des mois sans comprendre pourquoi les soumissions baissaient.

Les erreurs les plus courantes et comment les éviter

Après des années de pratique, je peux établir une liste des erreurs les plus fréquentes. Certaines sont bénignes, d'autres peuvent être fatales.

• Disallow: / total — bloque tout, souvent copié depuis un mauvais exemple. Vérifiez toujours deux fois.
• Bloquer les fichiers CSS et JS — peut dégrader le rendu de vos pages dans Google.
• Oublier la déclaration du sitemap — c'est un signal utile pour la découverte de vos contenus.
• Utiliser des chemins relatifs au lieu d'absolus — les URLs doivent être absolues pour être correctement interprétées.
• Ignorer les robots d'IA — laisser par défaut les portes ouvertes.
• Écrire des règles en majuscules — la syntaxe est sensible à la casse pour les chemins.

WordPress : les pièges spécifiques

Si vous utilisez WordPress, vous n'avez probablement pas de fichier robots.txt par défaut. WordPress en génère un virtuellement, mais il est souvent vide ou minimaliste. La solution consiste à en créer un vrai, à la racine de votre site.

Un piège spécifique à WordPress : les dossiers `wp-admin` et `wp-includes`. Certaines sources recommandent de les bloquer, mais c'est une erreur. Le robot de Google doit explorer votre interface d'administration pour "voir" votre thème et vos fonctions. Si vous bloquez tout, vous risquez des problèmes de rendu. Mon conseil : ne touchez pas à ces dossiers, sauf cas très spécifique.

Autre point : les sites WordPress génèrent souvent des paramètres d'URL inutiles. Ajoutez des règles pour bloquer les paramètres de tri ou de pagination excessive, mais faites-le avec précaution. Je vous recommande de tester chaque règle avant de la mettre en production.

Comment hiérarchiser vos règles pour les gros sites

Pour un petit site, un simple "User-agent: *" avec deux ou trois règles suffit. Pour un site volumineux, c'est une autre histoire.

Mon approche : je classe les règles en trois groupes. Le premier groupe concerne les zones sensibles (administration, espace client, panier). Le deuxième groupe concerne les contenus techniques (paramètres d'URL, filtres de recherche). Le troisième groupe concerne les contenus légitimes mais gourmands en budget de crawl (archives, tags, pages de tri).

La priorité est donnée aux pages qui génèrent du trafic et des conversions. Tout le reste passe après. Et je réfléchis toujours à l'impact de chaque règle sur le budget de crawl : est-ce que ça vaut le coup de bloquer cette partie du site ? Est-ce que ça va libérer des ressources pour des pages plus importantes ?

Les directives avancées qu'on voit rarement

Au-delà de `User-agent`, `Disallow` et `Allow`, il existe des directives moins connues mais utiles. La directive `Sitemap` est la plus importante : elle indique aux moteurs où trouver votre sitemap XML, ce qui facilite la découverte de vos pages.

Il y a aussi `Host`, qui n'est utilisée que par Yandex, et qui indique l'URL canonique de votre site. Si vous ciblez le marché russe, vous pouvez l'ajouter. Pour Google, elle est ignorée.

Et puis, on peut spécifier des directives par robot. Par exemple, bloquer une section pour Googlebot mais pas pour Bing. C'est rarement nécessaire, mais cela existe.

Conclusion : le robots.txt n'est pas une fin en soi

J'ai vu des gens passer des heures à optimiser leur robots.txt pour gagner quelques points de crawl, alors que leur site avait des problèmes de contenu bien plus graves. Le robots.txt est un outil, pas une stratégie. Il doit être configuré proprement, testé régulièrement, puis oublié.

La vraie question que vous devez vous poser, c'est : est-ce que mes pages importantes sont explorées correctement ? Si oui, votre robots.txt fait son travail. Si non, vous avez un problème à corriger. Le reste, c'est de l'optimisation marginale.

Allez, maintenant que vous savez tout ça, mettez les mains dans le code. Et si vous faites une erreur, dites-vous qu'on en fait tous. La différence, c'est qu'on teste avant de publier.