Comment bien configurer son fichier robots.txt pour un site WordPress complexe ?

Un robots.txt WordPress générique fonctionne pour un blog de 30 articles. Sur un site complexe, boutique WooCommerce avec filtres à facettes, multisite, ou catalogue de plusieurs milliers de pages, il devient soit trop permissif et gaspille le crawl budget, soit trop strict et bloque des ressources dont Google a besoin pour bien afficher vos pages.

Robots.txt ne gère pas l’indexation, et c’est le piège numéro un

Soyons précis, parce que cette confusion coûte cher : robots.txt donne des instructions de crawl, pas d’indexation. Une page bloquée dans robots.txt peut malgré tout apparaître dans les résultats Google, sans description, si des liens externes pointent vers elle. Pour empêcher réellement l’apparition d’une page dans les résultats, il faut une balise meta noindex, ce qui suppose que Google puisse justement crawler la page pour lire cette balise. Bloquer une URL dans robots.txt tout en espérant la désindexer avec un noindex est donc contradictoire : Google ne verra jamais le noindex s’il n’a pas le droit de crawler la page.

Cette distinction est la première chose à clarifier avant de toucher au fichier, sur un blog simple comme sur une boutique à 5 000 références.

La base pour tout WordPress

Un socle commun, quelle que soit la taille du site :

Sur cette base, l’objectif principal est de gérer le crawl budget : diriger les robots vers ce qui compte, et les tenir à l’écart de ce qui ne rapporte rien en indexation, comme /wp-includes/, les dossiers de cache de plugins, ou les pages de trackback.

Ce qui change sur un site complexe

Trois configurations changent la donne par rapport à un blog simple :

WooCommerce et les filtres à facettes. Chaque combinaison de filtres (couleur, taille, prix) génère une URL avec paramètres. Sans cadrage, ces combinaisons peuvent se compter en dizaines de milliers, toutes explorables par défaut, et aucune n’apporte de valeur d’indexation propre. Bloquer les paramètres de filtre dans robots.txt (via un Disallow: /*?*filter adapté à votre structure d’URL) redirige le budget vers les vraies pages produit et catégorie.

Le multisite. Chaque sous-site d’un réseau WordPress multisite génère son propre robots.txt virtuel, mais les règles réseau peuvent l’écraser si mal configurées. Vérifiez site par site que le fichier généré correspond bien à ce sous-domaine, pas à une règle globale copiée sans adaptation.

Les environnements de staging. Un piège classique et coûteux : le robots.txt de préproduction, avec un Disallow: / qui bloque tout, migré tel quel en production lors d’une mise en ligne. Résultat, le site de production entier disparaît du crawl du jour au lendemain, sans erreur visible ailleurs que dans Search Console.

L’erreur qui peut désindexer tout le site

Une seule ligne suffit à tout bloquer :

Deux origines fréquentes : un fichier de staging jamais retiré après mise en production, ou une règle trop large pensée pour bloquer un seul dossier mais mal écrite. Dans les deux cas, le symptôme est le même : une chute progressive des pages explorées dans le rapport de couverture de Search Console, sur plusieurs jours.

Tester avant de mettre en production

1. Utiliser l’outil de test de Search ConsoleGoogle Search Console propose une validation de syntaxe et un test URL par URL avant toute publication en production.
2. Vérifier chaque type de page critiqueTestez au minimum une page produit, une page catégorie, une page filtrée et la page d’accueil : chacune doit rester accessible aux robots.
3. Comparer avec le sitemap XMLAucune URL présente dans le sitemap ne doit être bloquée par robots.txt : la contradiction envoie un signal confus à Google.
4. Surveiller le rapport de couverture après mise à jourUn pic de pages « exclues » ou « bloquées par robots.txt » dans les jours suivants signale une règle trop large à corriger vite.

Checklist de configuration

Sur un catalogue volumineux ou une architecture multisite, la configuration de robots.txt se fait rarement en une seule passe : elle demande d’observer le comportement réel de Googlebot sur plusieurs semaines. C’est un chantier qu’un expert SEO WordPress pilote généralement en parallèle de l’audit du crawl budget et des logs serveur.

Robots.txt fait partie des mêmes pièges natifs que le fichier .htaccess ou les pages d’attachment mal indexées : des réglages serveur ou de crawl qui, livrés par défaut, ne conviennent jamais totalement à un site qui grandit.

En résumé

Un robots.txt WordPress complexe se pense en fonction du volume de pages généré par vos filtres, de votre architecture multisite le cas échéant, et de la frontière stricte entre staging et production. Le fichier ne gère jamais l’indexation à lui seul : il oriente le crawl, rien de plus, rien de moins.