Pourquoi chaque site WordPress a besoin d'un robots.txt personnalisé

WordPress génère automatiquement un fichier robots.txt pour chaque installation. Il est minimal : un agent générique, un Disallow pour /wp-admin/, et un Allow pour /wp-admin/admin-ajax.php. C'est la totalité de la politique qui gouverne l'interaction de chaque robot d'internet avec le site.

Pour un blogue fraichement créé avec dix articles, ce défaut ne cause pas de tort visible. Mais pour tout site qui a dépassé les bases — pages, produits, zones membres, fonctionnalité de recherche, types de contenu multiples — le robots.txt par défaut n'est pas juste insuffisant. C'est un passif.

Ce que WordPress expose par défaut

Une installation WordPress standard crée des dizaines de patrons d'URL qui génèrent de vraies pages mais ne livrent peu ou pas de valeur aux moteurs de recherche ou aux systèmes IA :

Les résultats de recherche internes. Chaque requête de recherche qu'un visiteur lance sur le site génère une URL comme /?s=motcle ou /search/motcle/. Ces pages sont maigres, de nature dupliquée, et ne devraient jamais être indexées. WordPress ne les bloque pas dans le robots.txt par défaut.

Les URL de flux. WordPress génère des flux RSS à /feed/, /comments/feed/, et par catégorie et par auteur. Ils sont utiles pour les lecteurs RSS mais créent des signaux de contenu dupliqué quand ils sont crawlés et indexés en parallèle des pages régulières.

Les archives d'auteurs. Sur un site à auteur unique, l'archive d'auteur est un quasi-doublon parfait de la page principale du blogue. Sur les sites multi-auteurs, les archives d'auteurs peuvent avoir de la valeur, mais elles nécessitent une gestion délibérée — pas le comportement par défaut d'être grandes ouvertes.

Les archives paginées. Les URL comme /page/2/, /page/3/ et au-delà sont générées pour chaque type d'archive. Sans traitement approprié, elles consomment du budget de crawl sur du contenu que les moteurs de recherche accèdent déjà par le sitemap et les pages d'archives principales.

Les pages de connexion et d'inscription. /wp-login.php et /wp-register.php ne devraient être crawlées par aucun robot externe. Ce sont des points de terminaison administratifs sans valeur publique et qui sont des cibles fréquentes d'attaques par force brute.

L'API REST WordPress. Le point de terminaison /wp-json/ expose des données structurées sur le site, les articles, les utilisateurs et la configuration. Bien qu'utile pour les intégrations légitimes, il laisse aussi fuiter des informations qui n'ont aucune raison d'être crawlées par des moteurs de recherche ou des robots IA.

Aucun de ces éléments n'est bloqué par le robots.txt par défaut. Chacun d'entre eux consomme du budget de crawl, crée des problèmes potentiels de contenu dupliqué, ou expose des chemins que les robots n'ont aucune raison légitime de visiter.

Le problème du budget de crawl

Le budget de crawl est le nombre de pages qu'un moteur de recherche est disposé à crawler sur un site dans une période donnée. Pour les petits sites, le budget de crawl est rarement une contrainte visible. Mais quand un site grandit — surtout avec des variations de produits WooCommerce, de la navigation à facettes ou de grandes archives de contenu — le budget de crawl devient un goulot d'étranglement.

Quand les robots de moteurs de recherche passent du temps à récupérer les résultats de recherche internes, les archives paginées et les URL de flux, ils ont moins de capacité pour crawler les pages qui comptent réellement : le contenu, les produits et les pages d'atterrissage. Un robots.txt personnalisé dirige l'attention des robots vers les pages à haute valeur et l'éloigne des points de terminaison à faible valeur.

Le problème de gouvernance IA

Le robots.txt par défaut de WordPress ne fait aucune distinction entre les robots de moteurs de recherche et les robots IA. Ce n'était pas un problème en 2020 parce que les robots IA existaient à peine. En 2026, c'est un angle mort critique.

Si le site contient du contenu original — articles, guides, travail créatif, données propriétaires — et que le robots.txt n'a pas été configuré pour adresser les robots IA spécifiquement, c'est un choix implicite : on autorise chaque robot d'entreprise IA à récupérer et potentiellement utiliser le contenu pour l'entrainement, la récupération ou la génération.

C'est peut-être exactement ce qu'on veut. Ou c'est peut-être le contraire. Dans les deux cas, la décision devrait être délibérée, pas un effet secondaire de l'utilisation du défaut WordPress.

Un robots.txt personnalisé permet de :

• Autoriser Googlebot un accès complet pour l'indexation tout en restreignant GPTBot ou ClaudeBot.
• Permettre aux robots IA d'accéder à certaines sections (comme le blogue public) tout en bloquant d'autres (comme la zone de contenu payant).
• Bloquer les robots agressifs ou non déclarés qui consomment des ressources sans fournir de valeur.

Ce qu'un robots.txt WordPress correct inclut

Un robots.txt WordPress bien configuré adresse typiquement ces catégories :

Protections de base. Bloquer /wp-admin/, /wp-login.php, /wp-register.php et les autres chemins administratifs auxquels aucun robot externe n'a besoin d'accéder.

Hygiène de crawl. Bloquer les résultats de recherche internes (/?s=), les URL de flux quand c'est approprié, et les archives paginées à faible valeur.

Artéfacts de plugins et de thèmes. Bloquer les chemins comme les répertoires /wp-content/plugins/ qui génèrent des pages administratives ou de configuration, et les sous-répertoires /wp-content/uploads/ qui créent des listages de fichiers navigables.

Gouvernance IA. Ajouter des blocs User-agent spécifiques pour les robots IA avec des règles qui correspondent à la stratégie de contenu.

Référence au sitemap. Inclure une directive Sitemap: pointant vers le plan de site XML pour que les robots aient un point d'entrée clair vers le contenu important.

Chemins WooCommerce (si applicable). Bloquer les chemins de panier, de passage en caisse, de compte et de navigation à facettes qui génèrent des nombres massifs d'URL à faible valeur.

Pourquoi un plugin est mieux qu'une modification manuelle

On peut créer un robots.txt personnalisé en plaçant un fichier physique à la racine du serveur. Mais cette approche a trois problèmes.

Premièrement, WordPress ignore un robots.txt physique si son fichier virtuel est actif, et l'interaction entre les deux crée de la confusion sur les règles réellement servies.

Deuxièmement, un fichier manuel est statique. Quand la structure du site change — nouveaux plugins, nouveaux types d'articles, nouveaux patrons d'URL — le robots.txt ne se met pas à jour automatiquement.

Troisièmement, un fichier manuel n'a pas d'étape de prévisualisation. On écrit les règles, on sauvegarde le fichier, et on espère ne pas avoir accidentellement bloqué quelque chose d'important. Il n'y a pas de validation, pas de vue comparée, et pas de moyen facile de tester le résultat.

Better Robots.txt résout ces trois problèmes : il remplace le fichier virtuel proprement, s'adapte à la configuration du site, et offre une étape de révision avant que quoi que ce soit ne soit mis en ligne.