Robots.txt :
guider les robots et optimiser ton crawl

Le fichier robots.txt doit obligatoirement se situer à la racine de ton domaine, c’est-à-dire à l’adresse ton-site.fr/robots.txt. C’est une convention stricte et universelle : tous les robots des moteurs de recherche vont chercher le fichier exactement à cet endroit et nulle part ailleurs. Si tu le places dans un sous-dossier comme ton-site.fr/blog/robots.txt, il sera totalement ignoré, car les robots ne le trouveront jamais.

Concrètement, sur un site WordPress hébergé chez un prestataire comme O2Switch, tu peux gérer ce fichier via un plugin SEO qui l’édite pour toi, ou le déposer directement à la racine de ton dossier public via le gestionnaire de fichiers ou en FTP. Une fois en place, vérifie toujours qu’il est accessible en tapant son URL complète dans ton navigateur : tu dois voir son contenu texte s’afficher directement. Si tu obtiens une erreur 404, c’est que le fichier n’est pas au bon endroit, et les robots ne pourront pas lire tes instructions.

Non, et c’est la confusion la plus répandue à son sujet. Le robots.txt gère uniquement le crawl, c’est-à-dire l’exploration de tes pages par les robots. Il ne gère pas l’indexation, c’est-à-dire leur présence dans les résultats de recherche. Bloquer une page dans le robots.txt empêche Google de lire son contenu, mais si d’autres sites font un lien vers cette page, Google peut malgré tout l’afficher dans ses résultats, généralement en montrant seulement son URL sans description.

Pire encore, il y a un effet pervers à connaître. Si tu bloques une page dans le robots.txt et que cette page contient par ailleurs une balise noindex, Google ne pourra jamais lire cette balise noindex, puisqu’il n’a pas le droit de crawler la page. Le noindex devient donc inopérant. La règle claire que je donne toujours : pour retirer réellement une page de Google, utilise une balise noindex et laisse la page accessible au crawl. Réserve le robots.txt à l’optimisation du budget crawl sur des zones sans intérêt, jamais à la désindexation.

Le budget de crawl représente le temps et les ressources que Google consacre à explorer ton site. Ce budget est limité, surtout si tu as un site volumineux avec des milliers de pages. Le problème, c’est que les robots peuvent gaspiller ce budget précieux à explorer des pages sans aucune valeur SEO : les résultats de recherche interne, les pages générées par des filtres, les URL avec des paramètres, ou les zones d’administration.

En bloquant l’accès à ces zones inutiles dans ton robots.txt, tu empêches les robots d’y perdre du temps. Résultat, ils concentrent leur exploration sur tes vraies pages de contenu, celles que tu veux voir bien indexées et positionnées. Ces pages importantes sont alors crawlées plus fréquemment, ce qui améliore la fraîcheur de leur indexation. Sur un gros site, c’est un levier d’optimisation majeur que j’active systématiquement. Sur un petit site vitrine, l’impact est plus modeste, car le budget crawl y est rarement un facteur limitant. C’est donc une optimisation à prioriser selon la taille de ton site.

La différence est essentielle et touche à deux étapes distinctes du travail des moteurs. Le robots.txt intervient au niveau du crawl : il dit aux robots quelles parties de ton site ils ont le droit d’explorer. La balise noindex intervient au niveau de l’indexation : elle dit à Google de ne pas afficher une page précise dans ses résultats de recherche, même s’il a le droit de la crawler.

Concrètement, si tu veux économiser du budget crawl en empêchant les robots d’explorer une grande zone sans valeur, tu utilises le robots.txt. Si tu veux qu’une page précise, comme une page de remerciement après un achat ou une page de mentions légales, n’apparaisse pas dans Google tout en restant accessible aux visiteurs, tu utilises une balise noindex placée dans le code de cette page. Le piège à éviter absolument est de vouloir désindexer une page en la bloquant dans le robots.txt : ça ne fonctionne pas, car Google ne pourra pas lire l’instruction de désindexation. Chaque outil a son rôle, et les mélanger crée des problèmes.

Oui, absolument, et c’est le risque le plus sérieux avec ce fichier. L’erreur la plus grave est une directive Disallow suivie d’un simple slash, qui interdit l’exploration de l’intégralité de ton site à tous les robots. Cette erreur arrive typiquement lors d’une mise en ligne : pendant le développement, on bloque volontairement le site pour éviter qu’il soit indexé trop tôt, et on oublie de retirer ce blocage au moment de la mise en production. Le site devient alors invisible pour Google.

Les conséquences sont progressives mais graves : Google cesse de crawler tes pages, elles finissent par être désindexées, et ton trafic organique s’effondre. C’est pourquoi je vérifie toujours le robots.txt en priorité quand un client subit une chute de trafic inexpliquée après une mise en ligne ou une migration. La prévention est simple : après chaque modification, teste ton fichier avec l’outil de test du robots.txt dans la Google Search Console. Il te montre exactement quelles URL sont bloquées ou autorisées, ce qui te permet d’attraper ce genre d’erreur en quelques secondes avant qu’elle ne fasse des dégâts.

Non, surtout pas, c’est une erreur classique qui date d’anciennes pratiques. Autrefois, certains bloquaient les fichiers CSS et JavaScript pour économiser du budget crawl. Aujourd’hui, c’est fortement déconseillé. Google a besoin d’accéder à ces fichiers pour afficher correctement tes pages, exactement comme le ferait un navigateur. C’est ce qu’on appelle le rendu : Google exécute ton CSS et ton JavaScript pour voir ta page telle que tes visiteurs la voient.

Si tu bloques ces ressources, Google voit une version dégradée, cassée, de ta page. Il peut alors mal évaluer ta mise en page, ne pas voir du contenu chargé en JavaScript, ou considérer que ton site n’est pas adapté au mobile. Tout cela peut nuire à ton référencement. La règle est donc claire : laisse toujours Googlebot accéder à tes fichiers CSS et JavaScript. Si tu as un doute sur ce que Google voit réellement de ta page, utilise l’outil d’inspection d’URL de la Search Console, qui te montre le rendu de ta page tel que Google le perçoit. C’est un excellent moyen de détecter un blocage accidentel de ces ressources.

Oui, c’est une bonne pratique que je recommande systématiquement. Ajouter une ligne Sitemap dans ton robots.txt, avec l’URL complète de ton fichier sitemap.xml, permet aux robots des moteurs de recherche de trouver immédiatement la liste de toutes tes URL importantes dès leur première visite. C’est un raccourci qui facilite la découverte de ton contenu, en complément de la soumission classique du sitemap dans la Search Console.

Cette indication est particulièrement utile pour les nouveaux sites ou les sites qui publient régulièrement du nouveau contenu, car elle aide les moteurs à repérer plus vite les pages à explorer. Techniquement, cette ligne peut être placée n’importe où dans le fichier robots.txt, elle est indépendante des blocs de règles User-agent. Si tu as plusieurs sitemaps, par exemple un pour les pages et un pour les articles, tu peux indiquer chacun d’eux sur une ligne distincte, ou pointer vers un fichier index de sitemaps qui les regroupe. C’est un petit ajout simple qui améliore la communication entre ton site et les moteurs de recherche.

Le meilleur outil pour ça est le testeur de robots.txt intégré à la Google Search Console. Il te permet de saisir n’importe quelle URL de ton site et de vérifier instantanément si elle est autorisée ou bloquée par tes règles actuelles, du point de vue de Googlebot. C’est indispensable après chaque modification, car il te montre précisément l’effet de tes directives et t’évite les mauvaises surprises. Je m’en sers systématiquement dans mes audits.

Tu peux aussi faire un premier contrôle simple en tapant directement l’URL ton-site.fr/robots.txt dans ton navigateur pour lire son contenu et vérifier qu’il correspond bien à ce que tu attends. Pour une analyse plus poussée sur un gros site, un outil de crawl comme Screaming Frog respecte les règles du robots.txt et te montre quelles pages sont exclues de l’exploration. En combinant ces méthodes, tu t’assures que ton fichier fait exactement ce que tu veux : bloquer les zones inutiles et laisser le champ libre à tes pages importantes. Ne modifie jamais un robots.txt sans tester le résultat juste après.

Pour un petit site vitrine de quelques pages, l’impact du robots.txt sur le budget de crawl est limité, car Google n’a aucun mal à explorer l’ensemble de tes pages sans jamais épuiser son budget. Sur ce type de site, l’optimisation du crawl n’est pas un enjeu majeur. Tu n’as donc pas besoin d’un robots.txt complexe avec de nombreuses règles de blocage.

Cela dit, avoir un robots.txt propre reste une bonne pratique même pour un petit site. Il te permet au minimum d’indiquer l’emplacement de ton sitemap et de t’assurer qu’aucune zone n’est bloquée par erreur. Sur WordPress, un plugin SEO génère automatiquement un robots.txt de base correct, ce qui suffit largement pour la plupart des sites vitrines. Le vrai enjeu du robots.txt concerne surtout les sites volumineux, les boutiques en ligne avec des milliers de pages produits et de filtres, ou les sites avec beaucoup de contenu généré. Pour un petit site, l’essentiel est simplement de vérifier qu’il ne bloque rien d’important et qu’il pointe vers ton sitemap. Ne néglige jamais ce contrôle de base, quelle que soit la taille de ton site.