Aller au contenu
SEO et crawlers

Comment bloquer les robots d'IA dans WordPress (sans se raconter d'histoires)

Pour empêcher GPTBot d'explorer un site WordPress, ajoutez ces lignes à votre robots.txt :

Publié

Sautez la lecture — utilisez l'outil Générateur de robots.txt Y compris les robots d'IA que personne d'autre ne vous laisse activer ou désactiver

Pour empêcher GPTBot d’explorer un site WordPress, ajoutez ces lignes à votre robots.txt :

User-agent: GPTBot
Disallow: /

Voilà tout le correctif pour les robots bien élevés. Mais soyez honnête avec vous-même sur ce que vous venez de faire : robots.txt est une requête, pas une barrière. Le GPTBot d’OpenAI récupère le fichier et le respecte. Un scraper qui ne respecte pas le standard récupère le même fichier et ignore chacune de ses lignes. Gardez cette distinction en tête avant de passer un après-midi à peaufiner ceci.

Si vous voulez couvrir les principaux robots d’IA en une seule fois, les jetons user-agent les plus courants sont :

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Bytespider
Disallow: /

GPTBot est le robot d’entraînement d’OpenAI, CCBot est celui de Common Crawl (sur lequel de nombreux modèles s’entraînent en aval), ClaudeBot est celui d’Anthropic, Google-Extended est le jeton d’entraînement IA de Google, et Bytespider est celui de ByteDance. Notez que deux d’entre eux dérogent déjà au modèle de la requête polie : Bytespider et PerplexityBot ont tous deux été documentés publiquement en train d’explorer des sites qui les interdisaient. Les lister aide quand même face aux robots honnêtes ; cela ne change rien face à ceux qui mentent déjà sur leur identité.

Comment WordPress sert réellement robots.txt

C’est ici que les modifications de la plupart des gens ne font silencieusement rien. S’il n’y a aucun fichier robots.txt physique à la racine de votre site, WordPress en génère un à la volée. La requête est traitée par do_robots() dans wp-includes/functions.php, et la sortie passe par le filtre robots_txt. La case « Demander aux moteurs de recherche de ne pas indexer ce site » sous Réglages → Lecture bascule l’option blog_public, et c’est elle qui fait émettre Disallow: / à ce fichier virtuel.

Vous pouvez donc ajouter des règles pour les robots d’IA par programmation :

add_filter( 'robots_txt', function ( $output, $public ) {
    $output .= "User-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10, 2 );

Voici le piège qui fait perdre des heures : dès qu’un fichier robots.txt statique existe à la racine de votre site, Apache ou nginx sert ce fichier directement et WordPress n’est jamais exécuté. Le filtre robots_txt, l’éditeur robots de Yoast/Rank Math, le réglage de Lecture — tout est contourné. Si vous avez modifié robots.txt dans un plugin et que le fichier en ligne n’a jamais changé, c’est presque toujours la raison. Vérifiez https://votresite.com/robots.txt dans une fenêtre privée et comparez au contenu que vous pensez avoir défini. S’il y a un vrai fichier sur le disque, modifiez ce fichier ; le filtre n’a aucune importance.

Régler le problème, dans l’ordre

D’abord, écrivez des règles propres. Obtenez la bonne syntaxe et la bonne liste de robots pour ne pas bloquer Googlebot par accident. Notre générateur de robots.txt construit le bloc pour les robots d’IA à votre place et affiche le fichier exact à coller, ce qui évite la confusion entre virtuel et physique puisque vous vous retrouvez avec un seul fichier de référence.

Ensuite, confirmez qu’il est bien en ligne. Récupérez l’URL directement. Ne faites pas confiance à l’aperçu du plugin.

Enfin, si vous avez besoin d’une véritable application des règles plutôt que d’une demande polie, remontez d’un cran dans la pile. robots.txt se situe au niveau applicatif et dépend de la bonne volonté du robot. Pour réellement refuser une connexion, bloquez par user-agent au niveau du serveur. Dans .htaccess :

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|CCBot|ClaudeBot|Bytespider) [NC]
RewriteRule .* - [F,L]
</IfModule>

Cela renvoie une erreur 403 à tout ce qui envoie ces user-agents. Notre générateur de .htaccess peut assembler cette règle. Comprenez toutefois sa limite : les user-agents se falsifient trivialement, donc cela n’arrête que les robots assez honnêtes pour s’identifier — c’est-à-dire les mêmes robots qui respectent déjà robots.txt. L’option vraiment robuste est un CDN ou un WAF qui bloque par identité de robot vérifiée ou par plage d’IP. La règle managée « Block AI Scrapers and Crawlers » en un clic de Cloudflare en est la version la moins coûteuse en effort, et elle agit en périphérie, avant même que la requête n’atteigne WordPress.

Ce qu’il ne faut pas faire

Ne bloquez pas Google-Extended en pensant que cela vous tient à l’écart des AI Overviews. C’est l’idée fausse qui mérite d’être corrigée. Google-Extended est un jeton de produit, pas un robot. Il contrôle uniquement si votre contenu sert à entraîner et à ancrer les modèles Gemini. D’après la documentation de Google elle-même, il n’a aucun effet sur la façon dont vos pages sont explorées, indexées ou classées dans Google Search. Et les AI Overviews sont construits à partir de l’index de recherche habituel qu’explore Googlebot — pas à partir de Google-Extended. Bloquer Google-Extended ne vous retirera pas des AI Overviews, et ne vous coûtera pas une seule position dans Search. Le seul moyen de rester à l’écart des AI Overviews est de bloquer Googlebot ou de mettre la page en noindex, ce qui vous supprime aussi entièrement de Search. C’est presque jamais un compromis que vous voulez faire.

Ne traitez pas robots.txt comme un contrôle de sécurité. Il est public et indicatif. Y lister /wp-admin/ ou un chemin privé revient simplement à publier une carte des endroits où fouiller. Protégez les vrais points d’accès par de l’authentification, pas par une ligne disallow.

Ne comptez pas sur les balises meta noai / noimageai. Elles ont été proposées, jamais standardisées, et seule une poignée de plateformes les respectent. Ce n’est pas une défense générale.

Ne présumez pas qu’un plugin « bloquer l’IA » ait fait plus qu’écrire robots.txt. La plupart d’entre eux écrivent les mêmes lignes que vous pourriez écrire à la main et héritent de la même limitation. Lisez ce que le plugin a réellement modifié avant de lui faire confiance.

Toujours bloqué ?

Si vos modifications n’apparaissent pas, la réponse est presque toujours un robots.txt physique égaré à la racine du site qui prend le pas sur celui, virtuel, de WordPress — récupérez l’URL directement et vérifiez. Si les robots respectueux ont disparu mais que les scrapers continuent de vous frapper, vous avez atteint le plafond de ce que robots.txt peut faire, et l’étape suivante est une règle WAF ou CDN qui bloque par identité vérifiée plutôt qu’en demandant gentiment.