Crawlers d’entraînement IA vs crawlers de recherche IA
La plupart des erreurs de configuration viennent d’une confusion : traiter tous les crawlers IA comme s’ils avaient la même finalité.
Un crawler associé à l’entraînement de modèles n’est pas un crawler de recherche IA. Un agent déclenché par un utilisateur n’est pas un crawler automatisé classique. Un jeton comme Google-Extended n’est pas Googlebot.
La matrice utile
| Finalité | Sens pratique | Décision typique |
|---|---|---|
| Entraînement | Le contenu peut contribuer à des usages de développement de modèles. | Restreindre ou encadrer. |
| Recherche IA | Le contenu peut être découvert, résumé, cité ou lié dans une expérience IA. | Souvent autoriser si la visibilité compte. |
| Récupération utilisateur | Un utilisateur demande explicitement à un agent d’aller chercher une URL. | À traiter séparément. |
| Search classique | Googlebot, Bingbot et le référencement traditionnel. | À préserver sauf site privé. |
Exemple de posture
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /Cette posture dit : le site veut rester visible dans ChatGPT Search, mais souhaite restreindre le crawler d’entraînement documenté par OpenAI.
Pourquoi c’est important
Une règle trop large peut supprimer la visibilité Search et IA. Une règle trop vague ne documente rien. Le bon fichier sépare les finalités, puis relie les règles à une politique claire.
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.