Le blocage vit dans le CDN, pas dans robots.txt
Votre robots.txt autorise tout, mais les bots IA reçoivent un 403. Le vrai blocage se joue dans l'edge : auditez votre CDN avant de valider votre readiness.
Le fichier innocent — Pourquoi un robots.txt permissif endort l'audit
L'audit technique standard commence et s'arrête souvent à la racine du domaine. Le consultant ouvre le fichier texte, constate l'absence de directives restrictives ou la présence d'un rassurant « User-agent: * Allow: / », et valide l'accessibilité. C'est le piège classique de l'analyse déclarative. Un fichier permissif offre une fausse sécurité lorsque l'infrastructure réseau est complexe.
Le problème n'est pas ce que le fichier dit, mais le fait qu'il ne soit jamais lu. Le crawler n'atteint jamais le serveur d'origine. Il s'écrase sur une barrière invisible dressée bien en amont. En se fiant uniquement à cette liste d'autorisation de moteurs, l'agence valide une infrastructure qui reste en réalité totalement bloquée pour les modèles génératifs.
Diagnostiquer l'accessibilité au-delà du fichier évite de livrer un audit positif sur un site techniquement aveugle aux crawlers IA.
La couche qui décide vraiment — Bot-management, WAF, règles héritées : l'edge tranche avant robots
Entre le crawler et le serveur d'origine, l'edge network agit en videur intransigeant. Les pare-feux applicatifs (WAF) et les modules de bot-management sont souvent activés par défaut lors du déploiement du CDN. Personne dans l'équipe SEO n'a configuré ces règles, et souvent, l'équipe infrastructure les a simplement héritées d'un template de sécurité générique visant à réduire la charge serveur.
Ces systèmes ne lisent pas les directives SEO. Ils analysent des signatures de trafic, des ASN, des comportements de requêtes et des user-agents spécifiques aux scrapers. Si PerplexityBot ou OAI-SearchBot déclenche un score de menace trop élevé, la requête est tuée dans l'œuf. Le serveur d'origine n'en garde aucune trace, et l'investigation classique tourne à vide.
Auditer un fichier texte sans tester les règles de l'edge, c'est certifier l'ouverture d'une porte située derrière un mur de briques.
Cartographier l'architecture réseau permet d'identifier l'acteur qui détient le véritable pouvoir de blocage et d'orienter les recommandations vers la bonne équipe technique.
403, challenge, rate-limit : les formes du refus — Comment l'edge dit non sans jamais toucher au fichier
Le refus de l'edge ne prend pas toujours la forme d'une erreur franche. Le code HTTP 403 (Forbidden) est la manifestation la plus claire, mais d'autres mécanismes sont plus pernicieux. Le CDN peut imposer un challenge JavaScript ou un CAPTCHA. Mais contrairement à un Googlebot qui exécute le JS, les bots IA ne valident pas ces défis de sécurité. La requête échoue silencieusement, sans générer d'erreur fatale dans les outils de monitoring classiques.
Le rate-limiting est une autre arme de l'edge. Une règle configurée pour limiter les requêtes agressives d'outils d'extraction bloquera un bot LLM tentant de digérer un cluster entier en quelques minutes. Le résultat est un 429 (Too Many Requests) renvoyé par le proxy, jamais par le serveur web. Le monitoring côté client affichera un statut 200 de façade pour les utilisateurs humains, masquant l'hémorragie du côté des crawlers.
Comprendre la typologie des rejets CDN permet de configurer des alertes spécifiques sur les erreurs de proxy, plutôt que de chercher des anomalies inexistantes sur l'origine.
Permission déclarée vs effective — Tester la réponse réelle du CDN à chaque user-agent IA, pas le déclaratif
La méthodologie Sonar impose une distinction stricte : la permission déclarée (ce que vous demandez poliment via un fichier texte) et la permission effective (ce que l'infrastructure laisse physiquement passer). Pour mesurer cette dernière, il faut forger des requêtes HTTP complètes en usurpant les user-agents exacts des bots génératifs ciblés, en émettant depuis des adresses IP externes représentatives de leur comportement.
Il ne s'agit pas de pinger le domaine de manière générique, mais de simuler le comportement du bot face au WAF. C'est en croisant ces tests avec l'analyse des logs serveurs que la réalité de l'indexation se dessine. Si GPTBot reçoit un 403 à l'edge alors que le fichier texte l'autorise expressément, la permission effective est nulle.
Substituer l'analyse déclarative par un test de pénétration des bots transforme une supposition incertaine en certitude technique actionnable.
Auditer l'edge en premier — Faire de la vérification edge un préalable non négociable de la readiness
Inverser la chronologie de l'audit est indispensable pour garantir le succès d'une stratégie GEO. L'examen du fichier d'autorisation ne vient qu'en deuxième étape. Le prérequis absolu est de s'assurer que le portier laisse entrer les invités. Si l'edge bloque, ces deux portes en série annulent tous vos efforts : toute optimisation de contenu, de sémantique ou de maillage devient un investissement à perte.
L'agence doit exiger un accès en lecture à la configuration du CDN ou collaborer étroitement avec les équipes NetOps pour whitelister les plages IP et les ASN des moteurs IA ciblés. La GEO-readiness n'est pas un exercice de conformité SEO traditionnel, c'est un alignement rigoureux de l'infrastructure réseau sur les objectifs de visibilité dans les LLMs.
Placer la vérification du CDN en amont du projet garantit que vos recommandations sémantiques seront effectivement ingérées par les modèles, sécurisant ainsi le ROI de la prestation.