Robots.txt pour débutants : le guide pas à pas pour bien le configurer

Vous avez peut-être déjà entendu dire que le fichier robots.txt est indispensable pour le référencement naturel. Ou bien, à l'inverse, que c'est un outil risqué qui peut faire plus de mal que de bien. Franchement, les deux sont vrais. C'est un fichier minuscule, d'une simplicité déconcertante, et pourtant, une seule ligne mal placée peut faire disparaître des pages entières de Google. J'ai vu ça arriver, et pas seulement chez les autres. Il y a quelques années, j'ai bloqué par erreur l'intégralité de mon dossier d'images. Le site marchait, mais tout le design était cassé. Une journée de débogage pour un caractère de trop. Voici comment éviter ces pièges, pas à pas.

Pourquoi le robots.txt ne sert pas à cacher des pages

Avant de parler configuration, il faut dissiper un malentendu majeur. Beaucoup de débutants croient que le robots.txt sert à empêcher Google d'afficher une page dans ses résultats. C'est faux. Pour ça, il faut un noindex dans les balises meta ou dans l'en-tête HTTP. Le robots.txt, lui, indique aux robots d'exploration quelles URL ils ne sont pas censés visiter pour économiser les ressources du serveur. C'est une simple recommandation, pas une interdiction absolue. Et certains robots, peu scrupuleux, l'ignorent purement et simplement.

L'analogie qui m'a aidé à comprendre, c'est celle du gardien de musée. Le gardien peut vous dire de ne pas entrer dans une salle, mais il ne peut pas vous empêcher de regarder par la fenêtre. Si vous voulez vraiment cacher un tableau, il faut un rideau opaque. Pour les pages web, le rideau, c'est le meta robots noindex. La salle, c'est le fichier lui-même.

La différence subtile entre "crawler" et "indexer"

Un robot explore (crawl) votre site en suivant les liens et en consultant ce fichier. S'il voit une URL interdite, il ne la visite pas. Résultat : il ne voit pas le contenu, donc il ne peut pas l'indexer. Mais si d'autres sites pointent vers cette URL, Google peut toujours la découvrir et l'indexer sans même visiter la page, en se basant sur les signaux externes. C'est pour ça que des pages bloquées par robots.txt peuvent parfois apparaître dans les résultats, avec un simple titre, sans description. Ça m'est arrivé, et j'ai dû débloquer la page puis demander une ré-indexation manuelle pour corriger le tir.

En clair : ce fichier ne sert pas à gérer votre visibilité. Il sert à gérer le trafic des robots sur votre serveur. C'est une distinction qui change tout.

Créer un robots.txt : syntaxe, directives et cas pratiques

La création est simple : un fichier texte nommé robots.txt, placé à la racine du site (par exemple, www.monsite.fr/robots.txt). Il n'y a pas de format secret. Juste des lignes de texte. Chaque « groupe » de règles commence par un User-agent suivi de directives Disallow ou Allow. Un * signifie « tous les robots ». C'est la base.

Voyons un exemple complet, adapté à un site WordPress typique, avec des commentaires (les lignes commençant par #) :

Autorise tous les robots à explorer le site
User-agent: *

Bloque le dossier d'administration, le contenu n'a pas à être crawlé
Disallow: /wp-admin/
Disallow: /wp-includes/

Bloque un dossier temporaire de téléchargements
Disallow: /temp/

Indique l'emplacement du sitemap
Sitemap: https://www.monsite.fr/sitemap.xml

L'élément le plus important, c'est la ligne Sitemap. Je l'ai ajoutée après des mois sans elle, et j'ai constaté une amélioration notable de la vitesse de découverte de mes nouvelles pages. Google le trouvera de toute façon, mais lui donner directement l'itinéraire, ça simplifie la vie. Pour ce qui est de Disallow, la règle est de ne bloquer que ce qui est vraiment inutile et qui surcharge le serveur. Dans 90 % des cas, un simple fichier comme celui-ci suffit.

Bloquer un dossier sensible pour les débutants

Imaginons que vous ayez un site e-commerce avec une page de remerciement après paiement. Vous ne voulez pas que Google la garde dans son index, car elle n'a aucun intérêt pour les visiteurs. Mais attention, vous ne voulez pas non plus bloquer le crawl des pages produits. Un Disallow sur le dossier /merci/ évitera aux robots de gaspiller des requêtes. Et pour le retrait de l'index, vous ajouterez un noindex sur la page elle-même. C'est la double sécurité.

J'ai mis en place ce système après avoir vu mon site afficher des pages « panier vide » dans les résultats de recherche. Un désastre esthétique, mais aussi un gaspillage de budget de crawl. Depuis, je vérifie systématiquement les URLs avec des paramètres de session dans mon fichier. C'est le genre de petit nettoyage qui fait une différence sur le long terme.

Autoriser un seul robot : le cas Googlebot

Une question qui revient souvent : c'est possible d'autoriser un seul bot ? Oui. On peut très bien bloquer tous les robots, puis autoriser spécifiquement Googlebot. C'est utile si vous avez un site interne ou un environnement de staging que vous ne voulez pas exposer aux autres moteurs, mais que vous voulez quand même que Google analyse. La syntaxe est simple : on ajoute un bloc User-agent: Googlebot avec une règle Allow: /.

Franchement, ce cas est rare pour un site public. Bloquer des robots comme Bing ou Yandex ne vous apporte rien de bon, sauf si vous avez une raison précise (par exemple, une surcharge de requêtes provenant d'un bot en particulier). Je l'ai fait une fois pour un bot de recherche asiatique qui martelait mon serveur toutes les secondes. Le serveur a retrouvé sa stabilité, et mon trafic Google n'a pas bougé d'un iota.

Le piège, dans ce genre de configuration, c'est d'oublier des combinaisons de user-agents. Par exemple, Google News utilise un bot spécifique (Googlebot-News). Si vous bloquez tout sauf Googlebot, vous bloquez aussi Googlebot-News, et vos articles pourraient ne plus apparaître dans Google Actualités. C'est une subtilité que j'ai apprise à mes dépens, en voyant mon trafic d'actualités chuter de 40 % en une nuit. Vérifiez toujours la liste des bots officiels avant de restreindre l'accès.

Tester votre fichier et éviter les erreurs de débutant

La configuration ne s'arrête pas à la création du fichier. Le plus important, c'est de le tester. Google Search Console propose un outil dédié qui permet de vérifier la syntaxe et de voir si une URL spécifique est bloquée. C'est un outil simple d'utilisation, mais il est indispensable. J'ai personnellement pris l'habitude de le consulter après chaque modification de mon fichier. C'est devenu un réflexe, comme de vérifier que mes sauvegardes fonctionnent avant une mise à jour majeure.

Faites un test simple : copiez le contenu de votre fichier dans l'outil, collez l'URL de votre page d'accueil et cliquez sur « tester ». L'outil vous dira si la page est autorisée ou non. C'est un aller-retour de trente secondes qui vous évitera des mois de frustration. Ne le sautez jamais.

L'erreur la plus fréquente : oublier le User-agent

J'ai vu des fichiers qui contenaient uniquement des lignes Disallow: /dossier/, sans aucune ligne User-agent au-dessus. C'est invalide. La directive Disallow doit obligatoirement être précédée d'un User-agent qui indique à quel robot elle s'applique. Sans cette ligne, la règle est potentiellement ignorée, ou pire, interprétée de manière inattendue. De nombreux validateurs en ligne vous diront qu'il y a une erreur. Mon conseil : ne vous fiez jamais à un fichier que vous n'avez pas testé avec l'outil officiel.

Une autre erreur classique : mettre une ligne User-agent au milieu du fichier, après des règles Disallow. Cela crée un nouveau groupe et invalide tout ce qui précède. Chaque bloc doit être complet : un User-agent, puis ses Disallow et Allow associés, avant de passer au bloc suivant. Un espace, une ligne vide ou un caractère en trop, et tout peut s'effondrer. C'est une syntaxe qui ne pardonne pas.

Pourquoi il ne faut pas bloquer les CSS et JavaScript

C'est un vieux réflexe que j'avais moi-même : pour « alléger » le crawl, je bloquais tous les fichiers .css et .js. Grosse erreur. Depuis des années, Google utilise des versions récentes de son navigateur pour rendre les pages. S'il ne peut pas charger votre CSS, il voit une page moche, sans mise en page, et il peut considérer que l'expérience est mauvaise. Et s'il ne charge pas votre JavaScript, il ne verra peut-être que du vide, si votre site est construit en React ou Vue.js par exemple.

Le résultat ? Une chute de positionnement pour des mots-clés stratégiques, sans explication logique. J'ai passé une semaine à chercher pourquoi mon taux de clics avait chuté et pourquoi Google semblait ne pas comprendre mes pages. La solution était simple : retirer les lignes Disallow: /.js et Disallow: /.css de mon fichier. En deux jours, Google avait recrawlé mes pages, cette fois avec les fichiers de style, et les positions sont remontées. Si votre site est critique, ne bloquez jamais ces ressources.

La seule exception, c'est peut-être un fichier JavaScript externe qui n'apporte rien au contenu. Mais même là, je préfère utiliser un noindex ou le renvoyer via un domaine séparé plutôt que de le bloquer dans le robots.txt. C'est une question de propreté technique.

Cas particuliers : sous-domaines, HTTP et sitemaps

Une question que vous vous posez peut-être : un robots.txt sur un sous-domaine, ça fonctionne comment ? La réponse est simple : chaque sous-domaine est considéré comme un hôte distinct. blog.monsite.fr a son propre robots.txt, séparé de celui de monsite.fr. Si votre blog est hébergé sur un sous-domaine, il vous faudra un fichier là-bas aussi. J'ai vu des gens configurer un fichier seulement sur le domaine principal, et se demander pourquoi leur sous-domaine était indexé n'importe comment. C'est une nuance de débutant qui coûte cher.

Pour le HTTP et le HTTPS, c'est pareil. Le fichier est vérifié sur l'hôte et le protocole de l'URL. Si vous passez en HTTPS, votre fichier sur HTTP sera accessible, mais les robots le chercheront sur la version HTTPS. La règle d'or : votre fichier doit être accessible sur le même protocole que votre site, et répondre avec un code 200. S'il renvoie une erreur 404, les robots considèrent qu'il n'y a aucune restriction. C'est un détail, mais il explique pourquoi certains fichiers « disparaissent » après une migration.

Enfin, si vous avez un sitemap, indiquez son chemin directement dans le robots.txt. Ce n'est pas obligatoire, mais c'est une bonne pratique de routage. Je le répète, ça a accéléré la découverte de mes nouvelles pages. Ça réduit aussi la charge sur votre serveur, car les moteurs n'ont pas à deviner où se trouve le sitemap. Un gain de temps pour tout le monde.

Comment trouver le fichier robots.txt d'un autre site

Pour analyser la concurrence, la méthode est directe : tapez l'URL du site suivi de /robots.txt dans la barre d'adresse. Par exemple, www.concurrent.fr/robots.txt. Si le site est bien configuré, vous verrez le fichier s'afficher. S'il renvoie une erreur 404, soit le site n'en a pas, soit il est mal configuré. C'est une astuce rapide pour voir comment les gros sites structurent leurs règles. Je l'utilise encore, même après toutes ces années.

Un conseil pour l'analyse : regardez ce qu'ils bloquent, mais aussi ce qu'ils autorisent. Parfois, vous découvrirez des dossiers dont vous ignoriez l'existence sur votre propre site, juste en voyant comment un concurrent gère le même CMS. C'est un peu intrusif, mais c'est de la veille technique, et c'est totalement légal.

Le réflexe à garder : moins c'est mieux

Au final, la meilleure configuration pour un débutant, c'est souvent la plus courte. Un fichier minimal, qui bloque quelques dossiers sensibles et pointe vers le sitemap, fait largement le travail. Toute règle supplémentaire est une opportunité de se tromper. Franchement, si vous n'avez pas de problème de serveur ou des dossiers internes à protéger, vous n'avez presque rien à faire ici.

Ce que je ne soupçonnais pas au début, c'est à quel point ce petit fichier conditionne la confiance des moteurs. Un fichier propre et logique, c'est un signal technique sain. Un fichier plein d'erreurs ou trop restrictif, c'est un drapeau rouge qui peut ralentir tout votre référencement. Prenez le temps de le rédiger, de le tester, et de le garder à jour. La vérification est rapide, mais ses bénéfices sur la santé de votre site sont durables.

Alors, allez-y. Ouvrez votre éditeur de texte, créez ce fichier, testez-le. Et si vous hésitez sur une règle, souvenez-vous : vous pouvez toujours ne rien bloquer du tout. Le plus grand risque pour un site débutant, ce n'est pas de trop autoriser, c'est de trop restreindre.