- →Robots.txt contrôle l'exploration, pas l'indexation : une URL bloquée peut rester indexée, et un noindex posé sur une page bloquée ne sera jamais lu.
- →Google ne lit que quatre champs (user-agent, disallow, allow, sitemap) : crawl-delay et les noindex glissés dans le fichier sont ignorés, c'est documenté dans Search Central.
- →Avant d'acheter un lien, vérifier que la zone de publication du média est crawlable : un article sponsorisé publié sous Disallow ne transmet strictement rien.
- →Un 404 sur /robots.txt est inoffensif (tout est autorisé) ; un 5xx persistant peut suspendre l'exploration du site entier.
- →GPTBot est passé de 2,9 % à 4,5 % des requêtes de crawlers entre 2024 et 2025 et ClaudeBot a presque doublé (Web Almanac 2025) : distinguer bots d'entraînement et bots de consultation avant de bloquer.
- →Le rapport robots.txt de la Search Console montre la version que Google détient réellement, qui diverge plus souvent qu'on ne croit de celle servie par le serveur.
Ce que robots.txt contrôle vraiment : l'exploration, pas l'indexation
Le malentendu qui coûte le plus cher en audit tient en une phrase : le fichier robots.txt régit l'accès des robots d'exploration à un site, pas sa présence dans les résultats de recherche. Une URL bloquée par une directive Disallow peut parfaitement rester indexée si des liens externes pointent vers elle : Google l'affiche alors sans description, faute d'avoir pu en lire le contenu. Pour retirer une page de l'index, la mécanique est inverse : il faut laisser le moteur l'explorer pour qu'il voie la balise noindex. Confondre les deux leviers produit des situations absurdes qu'on retrouve chaque semaine en audit : des pages « bloquées » qui traînent dans l'index pendant des mois.
Techniquement, robots.txt est un simple fichier texte placé à la racine du site, accessible en HTTP à /robots.txt, et formalisé par la RFC 9309 de l'IETF en 2022 après presque trente ans d'existence comme standard de facto. Chaque hôte porte le sien : le fichier de blog.exemple.com ne régit pas www.exemple.com, et un robots.txt déposé dans un sous-répertoire n'a aucun effet. Il est aussi public par construction : n'importe qui peut le lire, vos concurrents comme les scrapers. Y lister des répertoires sensibles revient à publier la carte de ce qu'on voulait cacher.
En 2026, son rôle s'est déplacé. Search Engine Land observait en avril 2026, données Web Almanac à l'appui, que robots.txt fonctionne désormais comme un document de politique d'accès pour l'ensemble des bots, agents IA compris, bien au-delà du contrôle de crawl classique. C'est notre lecture aussi : la bonne question n'est plus « que bloquer », mais « quels agents autoriser, pour quel usage ».
Quatre champs, et rien d'autre : la syntaxe que Google lit
Google a fini par l'écrire noir sur blanc dans sa documentation Search Central : seuls quatre champs sont supportés, user-agent, disallow, allow et sitemap. Tout le reste est ignoré, crawl-delay en tête (Bing le lit encore, Google ne l'a jamais respecté). Les directives noindex glissées dans un robots.txt, qu'on croise toujours en 2026, n'ont plus aucun effet depuis 2019. Un fichier robots.txt sérieux tient donc en quelques lignes, et c'est une qualité, pas une paresse.
L'usage réel confirme cette sobriété. Gary Illyes et Martin Splitt ont passé un parseur maison sur 16 millions de fichiers robots.txt ; les résultats, relayés par StanVentures en avril 2026, montrent que user-agent, disallow et allow écrasent tout le reste, avec une chute quasi verticale après ces trois champs, même en échelle logarithmique. Le user-agent générique * domine très largement : la plupart des sites écrivent des règles globales plutôt que des groupes par crawler. L'étude a aussi exhumé une quantité de fichiers structurellement cassés, jusqu'à des pages HTML entières servies en guise de robots.txt.
La mécanique de lecture mérite d'être maîtrisée, car c'est là que naissent les accidents. Les règles se groupent par user-agent, et un crawler n'obéit qu'au groupe le plus spécifique qui le concerne : si un groupe Googlebot existe, Googlebot ignore entièrement le groupe générique. Entre deux règles en conflit, la plus longue, donc la plus spécifique, gagne ; à longueur égale, allow l'emporte chez Google. Les jokers * et $ permettent de cibler des motifs d'URL et des fins de chemin. La ligne sitemap, elle, vit hors des groupes : elle déclare simplement l'emplacement du sitemap XML pour tous les moteurs.
User-agent: *
Disallow: /admin/
Disallow: /recherche-interne/
Allow: /admin/ressources-publiques/
Sitemap: https://www.exemple.com/sitemap.xmlLe point aveugle des campagnes de liens
Un backlink n'existe pour Google que si la page qui l'héberge est explorée. Un article sponsorisé publié dans un répertoire sous Disallow, sur un site dont le robots.txt renvoie une erreur serveur persistante, ou derrière une règle mal écrite : dans les trois cas, le lien acheté ne transmet rien, puisque Googlebot ne le verra jamais. La synthèse de l'étude Google publiée par StanVentures en avril 2026 le formule sans détour : livrer des articles invités sur un site qui bloque Google, c'est brûler son investissement d'outreach. C'est pourtant une vérification que la plupart des acheteurs de liens ne font jamais.
Le réflexe avant toute commande tient en trois contrôles : lire le robots.txt du média cible, vérifier que la zone de publication (le blog, la catégorie visée) n'est pas bloquée, et contrôler le statut HTTP du fichier lui-même. Un 404 est sans gravité, Google considère alors que tout est autorisé. Un 5xx persistant est autrement plus toxique : le moteur peut suspendre l'exploration du site entier tant que le fichier ne répond pas. Les chiffres du Web Almanac 2025, rapportés par Search Engine Land en avril 2026, montrent un écosystème qui s'assainit lentement : 13 % des robots.txt renvoient un 404, contre 14 % un an plus tôt, et les réponses 5xx sont tombées autour de 0,1 %.
C'est une hygiène que nous imposons aux 50 médias que nous opérons en propre : robots.txt minimal, zones de publication ouvertes, sitemap déclaré, contrôle systématique après chaque déploiement. Quand on achète ailleurs, cette transparence doit être vérifiable avant paiement, pas découverte après : c'est précisément ce que permet un catalogue de médias dont on peut inspecter la crawlabilité avant de commander. Sur les gros sites, le même fichier sert un second objectif : préserver le budget de crawl en fermant les espaces d'URL infinis, recherche interne, filtres à facettes, paramètres de tri, pour que Googlebot passe son temps sur les pages qui portent le contenu et les liens, pas sur des combinaisons sans valeur.
Ce qu'on voit casser en audit
L'erreur canonique reste l'usage de Disallow comme outil de désindexation. Bloquer une URL déjà indexée la fige dans l'index : Google ne pouvant plus la crawler, il ne verra jamais le noindex qu'on y ajoute ensuite. La séquence correcte est l'inverse : laisser crawler, poser le noindex ou un en-tête X-Robots-Tag, attendre la désindexation effective, puis bloquer si on veut économiser du crawl. Même logique pour les contenus dupliqués : un Disallow empêche Google de lire la balise canonical qui aurait consolidé les signaux au bon endroit.
Deuxième famille : le blocage des ressources CSS et JavaScript, héritage d'une époque où l'on cachait ses assets. Google rend les pages avant de les évaluer ; lui interdire l'accès aux ressources dégrade le rendering, et les frameworks JavaScript aggravent le cas : bloquer /api/ ou les chunks d'une application React peut rendre le contenu principal invisible au rendu. Troisième famille, plus sournoise : les fichiers structurellement invalides relevés par l'étude des 16 millions de fichiers, pages HTML servies à la place du texte brut, redirections vers la page d'accueil, encodages exotiques que le parseur rejette silencieusement.
Reste le grand classique du lundi matin : le Disallow généralisé de préproduction poussé en production, qui sort un site entier de l'exploration en un seul déploiement. Le rapport robots.txt de la Search Console, dans Paramètres puis la section Exploration, est le premier écran à ouvrir en cas de doute : il montre la version du fichier que Google détient réellement, la date de récupération et les erreurs de parsing. Comparer cette version à celle du serveur évite des heures de débat interne : les deux divergent plus souvent qu'on ne croit, à cause des caches et des CDN.
Crawlers IA : le nouveau front du fichier
La croissance des agents IA a changé la charge du fichier. D'après les données Web Almanac 2025 reprises par Search Engine Land en avril 2026, GPTBot est passé de 2,9 % des requêtes de crawlers sur desktop en 2024 à 4,5 % en 2025, et ClaudeBot a presque doublé, de 1,9 % à 3,6 %. En face, la gouvernance ne suit pas : l'analyse Cloudflare relayée mi-2025 estimait qu'environ 14 % seulement des 10 000 plus gros domaines avaient des règles robots.txt spécifiques aux bots IA. Les autres prennent la décision par défaut, sans l'avoir jamais prise consciemment.
La distinction opérationnelle sépare bots d'entraînement et bots de consultation. Google-Extended en est l'exemple le plus mal compris : ce jeton ne contrôle que l'usage du contenu pour entraîner les modèles Gemini. Le bloquer ne retire rien de la recherche Google ni des AI Overviews, qui s'appuient sur le Googlebot standard, comme le précise la documentation Google. Bloquer GPTBot, à l'inverse, coupe à la fois l'entraînement et, selon les configurations, la capacité d'OpenAI à citer le site dans ses réponses.
Notre position est tranchée : pour un éditeur dont le modèle repose sur la visibilité, et c'est le cas de tout site qui monétise des emplacements, bloquer les bots de consultation revient à se retirer des interfaces où une part croissante des requêtes se joue désormais. Refuser l'entraînement est un choix défendable ; refuser la citation en est un autre, aux conséquences commerciales directes. Le robots.txt de 2026 n'est plus une formalité technique : c'est un arbitrage économique, à réviser au même rythme que sa stratégie d'acquisition.
Nautilinks opère un réseau de médias éditoriaux. Articles écrits en interne, mentions de transparence respectées, mix d'ancres calibré.
Questions fréquentes
Où se trouve le rapport robots.txt dans la Search Console ?
Dans Paramètres, section Exploration : le rapport robots.txt liste les fichiers que Google a récupérés pour vos hôtes, avec le statut HTTP, la date de dernière récupération et les erreurs de parsing éventuelles. C'est la source de vérité : il montre la version que Google détient, qui peut différer de celle servie par votre serveur à cause d'un cache ou d'un CDN. L'ancien outil de test autonome a été retiré, ce rapport le remplace.
Un Disallow suffit-il à désindexer une page ?
Non, et c'est même contre-productif. Une URL bloquée reste indexée si des liens pointent vers elle, affichée sans description. Pour désindexer proprement : laisser la page crawlable, poser un noindex en balise meta ou en X-Robots-Tag, attendre que Google repasse et retire la page, puis éventuellement bloquer ensuite pour économiser du crawl. Poser le Disallow d'abord fige la situation, puisque Google ne peut plus lire l'instruction de désindexation.
Un backlink placé sur une page bloquée par robots.txt transmet-il de l'autorité ?
Non. Googlebot n'explore jamais la page, donc n'en voit ni le contenu ni les liens sortants : le lien n'entre pas dans le graphe. C'est un contrôle à faire avant tout achat d'emplacement : vérifier que le répertoire de publication du média n'est pas sous Disallow et que /robots.txt répond en 200 ou 404, pas en 5xx. L'étude Google relayée par StanVentures en avril 2026 pointait explicitement ce risque pour les campagnes d'articles invités.
Google respecte-t-il la directive crawl-delay ?
Non, et il ne l'a jamais fait : la documentation Search Central, clarifiée récemment sur ce point, ne reconnaît que quatre champs (user-agent, disallow, allow, sitemap). Bing, lui, lit toujours crawl-delay. Pour ralentir Googlebot, il n'existe plus de réglage manuel : Google adapte sa cadence à la santé du serveur. Si le crawl pèse trop, la vraie réponse est de fermer les espaces d'URL infinis, facettes et recherche interne, plutôt que d'espérer d'une directive ignorée.
Faut-il bloquer GPTBot et les autres crawlers IA sur un site éditorial ?
Distinguez entraînement et consultation. Bloquer Google-Extended n'affecte que l'entraînement des modèles Gemini, pas la recherche ni les AI Overviews. Bloquer GPTBot coupe l'entraînement OpenAI mais peut aussi supprimer la citation du site dans les réponses. Pour un média qui vit de sa visibilité, bloquer les bots de consultation est une amputation commerciale. GPTBot est passé de 2,9 % à 4,5 % des requêtes de crawlers entre 2024 et 2025 et ClaudeBot a presque doublé selon le Web Almanac : la décision mérite mieux qu'un défaut implicite.
Que se passe-t-il si mon site n'a pas de robots.txt du tout ?
Rien de grave : un 404 sur /robots.txt signifie pour Google que tout est autorisé, et 13 % des sites mesurés par le Web Almanac 2025 sont dans ce cas. Le vrai danger est ailleurs : un 5xx persistant sur ce fichier peut suspendre l'exploration du site entier. Créer un fichier minimal, un groupe user-agent générique sans blocage plus la ligne sitemap, reste préférable : la politique d'accès devient explicite au lieu d'être déduite d'une absence.
Testez vos connaissances
Quiz : robots.txt
1/3Une URL indexée est passée sous Disallow, puis on lui ajoute une balise noindex. Que se passe-t-il ?