Vérificateur WordPress robots.txt IA
WordPress crée une réalité de crawl particulière : admin, médias, flux, recherche interne, commentaires, WooCommerce, sitemaps, extensions SEO, thèmes, caches et fichiers virtuels peuvent tous influencer ce que les robots lisent.
Un vérificateur WordPress robots.txt IA doit donc aller plus loin que la simple syntaxe. Il doit déterminer si le site est visible, contrôlé, lisible par machine et corrigeable avec un outil WordPress.
Ce que l’audit WordPress cherche
| Surface | Objectif |
|---|---|
/wp-admin/ | Restreindre l’admin sans casser les besoins publics. |
| Médias et ressources | Garder les images, CSS et JavaScript publics accessibles quand ils servent au rendu. |
| Recherche interne | Réduire les URLs de faible valeur générées par la recherche WordPress. |
| Commentaires | Éviter les pièges ?replytocom=. |
| WooCommerce | Bloquer les routes panier, checkout, compte et paramètres transactionnels de faible valeur. |
| Crawlers IA | Déclarer une posture claire pour OpenAI, Anthropic, Google, Perplexity et les autres familles importantes. |
llms.txt et politique IA | Donner du contexte machine-readable sans promettre une visibilité magique. |
Pourquoi le plugin est la couche de correction
Sur WordPress, robots.txt peut être virtuel, généré par WordPress, modifié par des extensions, ou surchargé par l’hébergement. Modifier un fichier physique n’est donc pas toujours fiable.
Better Robots.txt ajoute une couche de configuration dans l’administration WordPress : choix d’un preset, réglages par familles de crawlers, options WordPress, prévisualisation, publication, puis re-scan externe.
Le bon parcours
Audit externe → diagnostic → installation → configuration guidée → prévisualisation → nouveau scanLe rapport ne doit pas seulement éduquer. Il doit amener l’utilisateur à corriger le problème proprement.
Liste de vérification d’implémentation
Utilisez l’audit comme une séquence de correction, pas seulement comme un score.
- Confirmer l’origine auditée : protocole, domaine et sous-domaine doivent correspondre au site réel.
- Préserver l’accès Search sauf si le site est volontairement privé.
- Décider si l’objectif est la visibilité IA, la restriction de l’entraînement, une posture éditoriale conservatrice ou une fermeture stricte.
- Configurer les familles de crawlers par finalité, pas par réaction globale.
- Publier une politique seulement si elle reste cohérente avec les règles actives.
- Relancer le scan après publication, car WordPress, les extensions, le cache, le serveur ou l’edge peuvent modifier la sortie réelle.
Vérification manuelle
Un reviewer technique peut vérifier les surfaces suivantes :
/robots.txt
/llms.txt
/ai-manifest.json
/.well-known/ai-governance.json
/.well-known/llm-policy.jsonLa question n’est pas seulement de savoir si les fichiers existent. Il faut vérifier s’ils racontent la même chose. Une règle robots.txt restrictive, un llms.txt permissif et une politique IA contradictoire produisent une gouvernance faible, même si chaque URL répond correctement.
Chemin de correction WordPress
Si le site est WordPress, la suite logique est une configuration dans Better Robots.txt : choisir un preset, ajuster les familles de crawlers, prévisualiser, publier, puis relancer l’audit externe. C’est ce qui transforme le scan en preuve d’amélioration.