← Le journal

Votre robots.txt est une liste d'autorisation de moteurs

Une règle WAF oubliée peut vous rayer d'un moteur IA. Chaque directive de votre robots.txt est une décision commerciale déguisée en configuration technique.

Votre robots.txt est une liste d'autorisation de moteurs
GEODonnées anonymisées

Une agence audite un client absent de Perplexity depuis des mois. La cause n'est pas éditoriale : une règle WAF héritée, posée deux ans plus tôt pour « bloquer les bots », renvoie du 403 à PerplexityBot. Personne n'a jamais décidé de sortir la marque d'un moteur entier — c'est arrivé par défaut, silencieusement.

Chaque directive robots.txt et chaque règle CDN/WAF est une décision commerciale déguisée en configuration technique. Autoriser ou bloquer un user-agent, c'est choisir d'exister ou non dans un moteur. L'audit GEO doit impérativement valider cette couche réseau avant même d'analyser la sémantique.

Le blocage qu'on n'a jamais décidé — WAF/CDN et robots.txt hérités

Les configurations serveur vivent souvent plus longtemps que les stratégies d'acquisition. Lorsqu'une équipe technique déploie une règle anti-bot stricte sur Cloudflare, Akamai ou Fastly, l'objectif initial est de limiter le scraping sauvage, de prévenir les attaques DDoS ou d'alléger la charge serveur. Le dommage collatéral se chiffre en visibilité perdue. Un blocage WAF agit comme une porte blindée : le contenu a beau être parfaitement optimisé pour l'entité cible, le crawler ne l'atteindra jamais.

Le problème majeur réside dans l'invisibilité de ces règles pour les équipes marketing. Le SEO ou le responsable de l'acquisition continue de produire du contenu, ignorant que le blocage vit dans le CDN, pas dans robots.txt. Sortir d'un moteur génératif ne résulte presque jamais d'un arbitrage assumé par la direction, mais d'une case cochée par défaut dans une interface de sécurité technique des mois auparavant.

Auditer l'héritage technique permet de récupérer instantanément une part de voix perdue sur les moteurs génératifs sans écrire la moindre ligne de contenu.

Trois usages, un seul user-agent mal compris — Entraînement vs index vs fetch temps-réel

Le malentendu fondamental réside dans la nature même des crawlers IA. La méthodologie LIMEN/Sonar identifie trois fonctions distinctes associées au passage d'un bot : aspirer massivement des données pour l'entraînement d'un modèle de fondation, indexer des pages pour alimenter un moteur de recherche génératif, ou effectuer un fetch en temps réel pour répondre à la requête immédiate d'un utilisateur.

Confondre ces trois usages conduit à une erreur stratégique sévère. De nombreuses marques, souhaitant légitimement protéger leur propriété intellectuelle contre l'entraînement des LLMs, déploient des blocages génériques. Elles ignorent que bloquer GPTBot ne vous sort pas de ChatGPT si l'intention était d'empêcher l'entraînement, mais que bloquer OAI-SearchBot détruit leur capacité à être cité en temps réel par SearchGPT.

Segmenter techniquement les autorisations par usage garantit la protection de vos données propriétaires tout en maintenant votre présence active dans les réponses conversationnelles.

Cartographier qui a le droit d'entrer — Inventaire des user-agents IA et de leur statut réel par domaine

La première étape d'une mise en conformité GEO consiste à dresser l'inventaire exhaustif des portes d'entrée. Il ne suffit pas de lire le fichier texte à la racine du site. L'approche rigoureuse exige de simuler le passage de chaque user-agent IA majeur (OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended) et de relever le code HTTP réellement renvoyé par l'infrastructure.

Tableau de bord croisant les user-agents IA et les codes HTTP renvoyés par l'infrastructure
Carte des user-agents IA et de leur code de réponse réel (200/403/429) par surface.Données anonymisées

L'analyse doit révéler la réalité du terrain. Un affichage correct dans le navigateur de l'auditeur cache souvent le 200 qui ment, c'est-à-dire un 403 ou un timeout silencieux infligé spécifiquement au bot par un pare-feu applicatif. Seule une analyse croisée des logs serveur permet de certifier qu'un crawler a pu accéder à la ressource et extraire le contenu.

Une cartographie exhaustive des codes de réponse transforme une boîte noire réseau en un tableau de bord lisible et actionnable pour les décideurs.

Décider en connaissance : la matrice d'autorisation — Assumer chaque ligne comme un choix

Notre table GEO-readiness croise systématiquement les crawlers IA avec les trois fonctions évoquées (entraînement, indexation, fetch). Cette matrice force l'entreprise à se positionner : autoriser PerplexityBot à indexer, mais refuser CCBot pour l'entraînement. Accepter Google-Extended pour les AI Overviews, mais filtrer Anthropic si l'audience cible n'utilise pas Claude.

Le filtrage réseau ne doit jamais être une configuration par défaut, mais l'exécution stricte d'une matrice d'autorisation d'affaires.

La décision d'ouverture ou de fermeture doit être arbitrée par le marketing et la direction, car elle impacte directement la part de marché numérique. C'est en analysant vos logs, seule vérité sur les bots IA, que l'on vérifie si ces choix stratégiques sont effectivement traduits dans l'infrastructure technique.

Formaliser ces choix dans une matrice d'autorisation aligne définitivement la configuration serveur avec les objectifs d'acquisition et de revenus de l'entreprise.

Vérifier côté serveur, pas seulement dans le fichier — robots.txt propre mais WAF qui bloque

Le fichier robots.txt n'est qu'une déclaration d'intention polie. La réalité de l'accès se joue exclusivement sur l'infrastructure. Un fichier parfaitement configuré, autorisant explicitement les crawlers des moteurs génératifs, sera totalement inutile si une règle de sécurité rejette l'empreinte TLS du bot, filtre son ASN (Autonomous System Number) ou le bloque sur un test de challenge JavaScript.

Comparaison de visibilité avant et après la suppression d'une règle WAF bloquante
Avant/après : contenu identique, une règle WAF retirée → réapparition dans le moteur.Données anonymisées

Le contrôle de l'accessibilité doit s'effectuer en conditions réelles. Il faut forger des requêtes qui imitent scrupuleusement la signature du crawler cible pour s'assurer que le pare-feu laisse passer la requête et que le rendu final est exploitable, car fetchable n'est pas lisible. Un blocage à ce niveau annule 100 % des efforts sémantiques déployés en aval.

Valider la réponse serveur de bout en bout sécurise l'indexation de vos contenus et garantit que vos efforts éditoriaux atteindront effectivement les modèles ciblés.