Le fichier robots.txt dans WordPress : rôle, configuration et erreurs à éviter

Votre site n’ap­pa­raît pas dans Google, ou au contraire cer­taines zones que vous ne sou­hai­tez pas voir explo­rées sont par­cou­rues par les moteurs de recherche. Le fichier robots.txt est par­fois en cause. Pour­tant, il reste l’un des élé­ments les moins com­pris dans l’é­co­sys­tème WordPress.

Ce fichier joue un rôle pré­cis dans la façon dont les robots explorent votre site. Mal confi­gu­ré, il peut per­tur­ber l’ex­plo­ra­tion de vos conte­nus sans que vous vous en ren­diez compte. Bien confi­gu­ré, il per­met d’o­rien­ter uti­le­ment les robots vers les zones qui comptent vraiment.

Dans cet article, vous allez com­prendre à quoi sert réel­le­ment ce fichier, com­ment Word­Press le gère, com­ment fil­trer cer­tains robots d’in­tel­li­gence arti­fi­cielle, et com­ment construire une confi­gu­ra­tion de base adap­tée à un site vitrine.

À quoi sert le fichier robots.txt ?

Le fichier robots.txt est un fichier texte pla­cé à la racine de votre site. Son rôle est d’in­di­quer aux robots d’ex­plo­ra­tion, comme Goo­gle­bot (Google) ou Bing­bot (Micro­soft), quelles par­ties de votre site ils peuvent par­cou­rir et les­quelles ils doivent éviter.

Il repose sur le pro­to­cole d’ex­clu­sion des robots, une conven­tion adop­tée par les prin­ci­paux moteurs de recherche. Ce n’est pas un méca­nisme de blo­cage tech­nique : un robot mal inten­tion­né peut par­fai­te­ment l’i­gno­rer. Les robots des moteurs de recherche sérieux le res­pectent, mais rien ne les y oblige techniquement.

Ce que fait robots.txt

• Il indique aux robots quelles zones explo­rer et les­quelles igno­rer. Cela per­met d’é­vi­ter qu’ils par­courent des zones inutiles ou indé­si­rables : pages d’ad­mi­nis­tra­tion, résul­tats de recherche interne, pages de filtres géné­rées automatiquement.

• Il aide aus­si à ne pas gas­piller ce que Google appelle le crawl bud­get, c’est-à-dire le nombre de pages qu’il accepte d’ex­plo­rer sur votre site dans un laps de temps don­né. Sur un petit site, l’im­pact reste sou­vent limi­té. Sur un site volu­mi­neux, orien­ter l’ex­plo­ra­tion devient plus pertinent.

Ce que ne fait pas robots.txt

• Il ne contrôle pas l’in­dexa­tion à lui seul. Une page peut être indexée par Google sans avoir été explo­rée direc­te­ment, par exemple si d’autres sites pointent vers elle.

• Il ne pro­tège pas le conte­nu. Une règle Disallow n’empêche pas un visi­teur d’ac­cé­der à une URL s’il la connaît.

WordPress génère un robots.txt virtuel

Par défaut, Word­Press ne crée pas de fichier robots.txt phy­sique sur votre ser­veur. Le conte­nu est géné­ré dyna­mi­que­ment lors­qu’une requête est faite sur l’URL https://monsite.fr/robots.txt. Si vous consul­tez cette adresse, vous obte­nez bien une réponse, mais aucun fichier cor­res­pon­dant n’existe for­cé­ment à la racine de votre site.

Ce méca­nisme repose sur une règle de réécri­ture d’URL. Lorsque cette requête arrive, le ser­veur web la fait trai­ter par Word­Press, qui génère la réponse à la volée. Les exten­sions SEO comme Yoast SEO, Rank Math ou SEO­Press s’ap­puient sur ce même méca­nisme pour vous per­mettre de per­son­na­li­ser le conte­nu du fichier depuis l’in­ter­face d’administration.

Par défaut, Word­Press génère un robots.txt mini­mal qui res­semble à ceci :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Atten­tion au fichier phy­sique : si un fichier robots.txt existe réel­le­ment à la racine de votre site, le ser­veur web le sert direc­te­ment sans pas­ser par Word­Press. La ver­sion vir­tuelle ne fonc­tionne donc que s’il n’existe pas déjà un fichier physique.

Les robots d’intelligence artificielle et le robots.txt

Depuis quelques années, de nou­veaux robots sont appa­rus : ceux de cer­taines pla­te­formes d’in­tel­li­gence arti­fi­cielle. GPT­Bot (Ope­nAI), Clau­de­Bot (Anthro­pic), Ama­zon­bot ou encore Bytes­pi­der (Byte­Dance) par­courent le web pour col­lec­ter des don­nées des­ti­nées à dif­fé­rents usages, dont l’en­traî­ne­ment ou l’a­li­men­ta­tion de leurs services.

Plu­sieurs de ces robots déclarent recon­naître et res­pec­ter le pro­to­cole robots.txt, comme le font les grands moteurs de recherche. En pra­tique, cela dépend tou­te­fois des acteurs et des robots concer­nés. Il reste donc pos­sible de ten­ter de les blo­quer en ajou­tant des règles spé­ci­fiques dans votre fichier.

Ce que permet le protocole

Vous pou­vez cibler un robot pré­ci­sé­ment en uti­li­sant son nom dans la direc­tive User-agent, puis lui inter­dire l’ac­cès à tout ou par­tie de votre site avec Disallow.

Par exemple, pour blo­quer GPTBot :

User-agent: GPTBot
Disallow: /

User-agent: GPTBot
Disallow: /

Ou pour blo­quer plu­sieurs robots d’IA en une fois :

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Amazonbot
User-agent: Bytespider
User-agent: PerplexityBot
User-agent: Google-Extended
Disallow: /

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Amazonbot
User-agent: Bytespider
User-agent: PerplexityBot
User-agent: Google-Extended
Disallow: /

Les limites réelles

Le pro­to­cole robots.txt repose sur le res­pect volon­taire des robots. Cer­tains grands acteurs affirment suivre ces règles. Mais tous les robots qui col­lectent des don­nées pour l’IA ne jouent pas for­cé­ment le jeu. Cer­tains peuvent igno­rer déli­bé­ré­ment le fichier, d’autres opé­rer sous des noms géné­riques dif­fi­ciles à identifier.

Mettre en place ces règles reste utile. Ce n’est sim­ple­ment pas une garan­tie absolue.

Exemple de configuration pour un site vitrine WordPress

Voi­ci une confi­gu­ra­tion de base adap­tée à un site vitrine Word­Press stan­dard : quelques pages, pas de bou­tique, pas d’es­pace membre.

L’ob­jec­tif est d’o­rien­ter les robots vers les conte­nus utiles, d’é­car­ter les zones tech­niques sans inté­rêt pour l’ex­plo­ra­tion, et de décla­rer clai­re­ment le sitemap.

# -------------------------------------------------
# Règles générales
# -------------------------------------------------

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php

# -------------------------------------------------
# Sitemap
# -------------------------------------------------

Sitemap: https://monsite.fr/sitemap_index.xml

# -------------------------------------------------
# Règles générales
# -------------------------------------------------

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php

# -------------------------------------------------
# Sitemap
# -------------------------------------------------

Sitemap: https://monsite.fr/sitemap_index.xml

Quelques précisions sur les choix faits ici

• Cette confi­gu­ra­tion reste volon­tai­re­ment simple. Elle convient à beau­coup de sites vitrines clas­siques, mais elle peut être enri­chie selon votre contexte.
• Les pages de recherche interne peuvent aus­si être exclues de l’ex­plo­ra­tion, par exemple avec une règle visant /?s=. Ce n’est pas indis­pen­sable dans tous les cas, mais cela peut être per­ti­nent selon la struc­ture du site.
• Le blo­cage des URLs à para­mètres doit être manié avec pru­dence. Une règle trop large peut empê­cher l’ex­plo­ra­tion de pages utiles. Mieux vaut l’a­jou­ter seule­ment si vous com­pre­nez pré­ci­sé­ment son effet sur votre site.
• La sec­tion dédiée aux robots d’in­tel­li­gence arti­fi­cielle est option­nelle. Si vous sou­hai­tez res­treindre leur explo­ra­tion, vous pou­vez ajou­ter un bloc spé­ci­fique pour cha­cun d’eux.
• Si ce fichier est phy­sique, il prend le des­sus sur le fichier vir­tuel géné­ré par Word­Press ou par votre exten­sion SEO. Le site­map doit donc être décla­ré expli­ci­te­ment ici, avec l’URL correcte.

Les erreurs courantes

Bloquer tout le site avec Disallow: /

C’est l’er­reur la plus grave et l’une des plus fré­quentes. Une seule ligne suf­fit à inter­dire à Google d’ex­plo­rer l’in­té­gra­li­té de votre site :

User-agent: *
Disallow: /

User-agent: *
Disallow: /

Cette confi­gu­ra­tion est sou­vent mise en place pen­dant le déve­lop­pe­ment, puis oubliée au moment de la mise en ligne. Elle est par­fois confon­due avec une vraie pro­tec­tion du site : blo­quer l’ex­plo­ra­tion ne pro­tège pas l’ac­cès, et n’empêche pas for­cé­ment l’in­dexa­tion si des liens externes pointent vers vos pages. Le résul­tat est un site invi­sible dans Google, sans mes­sage d’er­reur apparent.

Google Search Console per­met de repé­rer ce type de pro­blème, ce qui sou­ligne l’in­té­rêt de la consul­ter régulièrement.

Des erreurs de syntaxe qui faussent tout

Un fichier robots.txt mal nom­mé (Robots.TXT au lieu de robots.txt), pla­cé ailleurs qu’à la racine du site, ou com­por­tant des direc­tives mal struc­tu­rées risque d’être igno­ré, tota­le­ment ou par­tiel­le­ment, par les robots.

L’ab­sence de User-agent en tête d’un bloc rend les règles qui suivent inva­lides. Des direc­tives contra­dic­toires sur une même URL peuvent aus­si être inter­pré­tées dif­fé­rem­ment selon les robots :

Disallow: /actualites/
Allow: /actualites/

Disallow: /actualites/
Allow: /actualites/

L’u­ti­li­sa­tion exces­sive de jokers peut blo­quer bien plus de pages que pré­vu. Une règle trop large peut vite pro­duire des effets indésirables.

Bloquer des ressources CSS et JavaScript

Blo­quer des réper­toires comme /wp-content/ ou /wp-includes/ peut empê­cher Google d’ac­cé­der aux feuilles de style et aux scripts de votre site. Or Google a besoin de ces res­sources pour affi­cher cor­rec­te­ment vos pages et les ana­ly­ser. Ce type de blo­cage peut dégra­der votre réfé­ren­ce­ment sans que la cause soit évidente.

Utiliser noindex dans robots.txt

La direc­tive noindex n’est pas sup­por­tée dans le fichier robots.txt. Pour empê­cher l’in­dexa­tion d’une page, il faut uti­li­ser une balise meta <meta name="robots" content="noindex">, ou pas­ser par les réglages de votre exten­sion SEO si elle per­met de l’a­jou­ter proprement.

Confondre robots.txt avec une protection d’accès

Une règle Disallow n’empêche pas un visi­teur d’ac­cé­der à une URL s’il la connaît. Elle s’a­dresse uni­que­ment aux robots qui res­pectent le pro­to­cole. Si vous devez vrai­ment pro­té­ger une zone, il faut mettre en place une authen­ti­fi­ca­tion ou un autre méca­nisme de contrôle d’accès.

Laisser des règles obsolètes

Un site qui change de struc­ture, d’ex­ten­sion SEO ou de pres­ta­taire accu­mule par­fois des règles qui ne cor­res­pondent plus à rien : réper­toires inexis­tants, para­mètres d’URL deve­nus inutiles, robots ciblés par un ancien nom. Un robots.txt non entre­te­nu peut blo­quer des zones utiles sans que per­sonne ne s’en aperçoive.

Vérifiez votre fichier robots.txt avant que Google ne le fasse à votre place

Le fichier robots.txt est court, mais son impact peut être impor­tant. Une règle mal pla­cée suf­fit à per­tur­ber l’ex­plo­ra­tion de votre site sans le moindre mes­sage d’er­reur visible.

L’es­sen­tiel à rete­nir : il oriente l’ex­plo­ra­tion, pas l’in­dexa­tion, et ne pro­tège pas le conte­nu. Dans Word­Press, il est géné­ré vir­tuel­le­ment. Si vous créez un fichier phy­sique, c’est lui qui prend le des­sus, et vous devez tout y gérer vous-même, y com­pris la décla­ra­tion du sitemap.

Pour véri­fier que votre confi­gu­ra­tion est cor­recte, Google Search Console pro­pose des outils d’ins­pec­tion utiles. Vous pou­vez notam­ment contrô­ler si une URL est explo­rée, indexée, ou blo­quée. Pour connec­ter et ajou­ter le site­map de votre site à la Google Search Console, vous pou­vez consul­ter l’ar­ticle Com­ment connec­ter la Google Search Console à votre site. Si vous avez déjà un compte Google Search Console, vous pou­vez tes­ter l’in­dexa­tion de votre fichier robots.txt à cette adresse.