OAI-SearchBot et PerplexityBot : vérifier robots.txt, le CDN et le pare-feu

OAI-SearchBot, GPTBot et ChatGPT-User n’ont pas le même rôle

Les contrôles sont indépendants ; le nom générique « robot ChatGPT » masque des usages différents.

La documentation OpenAI Crawlers décrit OAI-SearchBot comme le robot utilisé pour faire apparaître des sites dans les fonctions de recherche de ChatGPT. GPTBot explore des contenus susceptibles d’être utilisés pour rendre les modèles de fondation plus utiles et sûrs. Le propriétaire peut autoriser le premier et refuser le second dans robots.txt.

ChatGPT-User intervient pour certaines actions déclenchées par un utilisateur ou un GPT personnalisé. OpenAI précise qu’il n’est pas un robot d’exploration automatique et que robots.txt peut ne pas s’appliquer de la même manière à ces requêtes. Il ne faut donc pas utiliser son accès comme preuve de l’éligibilité à Search.

Les numéros de version dans les user-agents peuvent changer. Une règle durable vise le jeton documenté et complète le contrôle par les plages IP publiées. Copier une chaîne complète figée dans une règle de sécurité risque de bloquer une future version légitime.

PerplexityBot et Perplexity-User doivent aussi être séparés

Perplexity publie des agents, des usages et des plages IP distincts.

La documentation Perplexity Crawlers indique que PerplexityBot sert à faire émerger et lier des sites dans les résultats de recherche Perplexity. Elle précise qu’il n’est pas utilisé pour explorer du contenu destiné aux modèles de fondation.

Perplexity-User prend en charge des actions déclenchées lorsqu’un utilisateur pose une question et que le service visite une page. La documentation indique que ce type de requête peut ignorer robots.txt. Cette différence appelle une politique claire : la recherche automatisée et les visites à la demande ne se diagnostiquent pas avec un seul test.

Perplexity publie des fichiers JSON contenant les adresses de ses agents. Une règle WAF sérieuse combine le user-agent et ces plages, puis surveille les logs. Les plages peuvent changer : ne les recopiez pas pour toujours dans un document statique.

robots.txt et noindex ne répondent pas au même problème

Bloquer l’exploration peut empêcher le robot de lire la consigne qui interdit l’indexation.

robots.txt suit un protocole d’exclusion : il indique les chemins qu’un robot conforme peut ou ne peut pas explorer. Il n’est ni une protection d’accès, ni une méthode pour cacher une information sensible. Une URL publique peut être découverte par des liens même si son exploration est refusée.

La directive noindex se place dans une balise meta robots ou un en-tête HTTP X-Robots-Tag. Pour qu’un robot puisse la traiter, il doit accéder à la page. La FAQ OpenAI pour les éditeurs rappelle ce point : bloquer OAI-SearchBot empêche aussi la lecture d’une balise noindex sur la page concernée.

Pour une page privée, la vraie protection reste l’authentification et l’autorisation côté serveur. Pour une page publique exclue des résultats, utilisez une directive d’indexation adaptée. Pour une politique d’exploration, utilisez robots.txt. Mélanger ces objectifs crée souvent des états impossibles à diagnostiquer.

Écrire une règle robots.txt explicite et proportionnée

Autoriser les robots de recherche ne nécessite pas de modifier la politique GPTBot.

Pour un site qui souhaite être éligible aux recherches OpenAI et Perplexity, robots.txt peut exprimer une politique d’exploration. Cette politique ne constitue jamais une règle de sécurité et ne doit pas être transformée en exception WAF fondée sur le seul user-agent.

Relisez l’ordre et les chemins avant publication. Le protocole robots utilise le groupe correspondant au user-agent le plus spécifique. Si le groupe global autorise déjà les zones publiques et bloque les zones privées, il n’est pas nécessaire d’ajouter un bloc d’autorisation propre à un robot. Ne supprimez jamais les interdictions nécessaires pour l’administration ou les API.

Après modification, OpenAI indique qu’un ajustement peut prendre environ 24 heures. Perplexity mentionne aussi un délai possible. Attendre la propagation ne dispense pas de tester immédiatement le fichier servi et la réponse du site.

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /storage/

Tester les réponses HTTP sans surinterpréter curl

Les commandes reproduisent un en-tête user-agent ; elles ne prouvent pas l’identité réseau du demandeur.

Commence par récupérer robots.txt sans user-agent particulier, puis teste la page d’accueil et une page profonde. Utilise une limite de temps et enregistrez l’heure, le code, la chaîne de redirection et les en-têtes utiles. Une réponse 403, 429, 5xx, un reset ou un timeout orientent vers des causes différentes.

La commande -I envoie une requête HEAD. Certains serveurs traitent HEAD différemment de GET. Si le résultat paraît anormal, répétez avec une requête GET sans télécharger le corps complet, par exemple en envoyant la sortie vers /dev/null. Teste aussi depuis le réseau de production lorsque le problème n’existe pas en local.

Un test doit être reproductible : URL exacte, DNS résolu, protocole, user-agent, date, code et durée. Le socle SEO, GEO et moteurs IA explique pourquoi cette accessibilité reste un prérequis et non une garantie de citation.

curl -I https://weworkweb.fr/robots.txt
curl -I -A "OAI-SearchBot" https://weworkweb.fr/
curl -I -A "PerplexityBot" https://weworkweb.fr/
curl -I -A "Googlebot" https://weworkweb.fr/
curl -I -A "GPTBot" https://weworkweb.fr/
curl -sS -o /dev/null -D - -A "OAI-SearchBot" --max-time 20 https://weworkweb.fr/

Lire les journaux et remonter la chaîne CDN, WAF, serveur et WordPress

Le code visible par le navigateur ne révèle pas toujours la couche qui a rejeté la requête.

Cherche dans les journaux l’heure du test, le chemin, le code, l’IP, le user-agent et l’identifiant de requête du CDN. Si aucune ligne n’atteint le serveur d’origine, le refus se situe probablement en amont. Si WordPress reçoit la requête, une extension de sécurité, une règle applicative ou un code personnalisé peut intervenir.

Sur un CDN ou un WAF, examinez les règles de bot management, les défis JavaScript, les protections de débit, les règles pays, les listes IP et les exceptions. N’autorisez pas une requête sur le seul texte du user-agent : n’importe quel client peut l’usurper. Compare l’IP aux fichiers officiels d’OpenAI ou Perplexity et tenez compte des proxys de confiance.

Dans WordPress, vérifiez les extensions de sécurité, le mode maintenance, les hooks qui inspectent HTTP_USER_AGENT, les protections XML-RPC ou REST trop larges et le cache. Une correction doit rester ciblée. Désactiver tout le pare-feu pour obtenir HTTP 200 crée un risque disproportionné.

• Exporter l’événement WAF correspondant au test sans exposer de données sensibles.
• Comparer l’IP source à la liste officielle au moment du diagnostic.
• Vérifier si HEAD et GET suivent la même règle.
• Contrôler la page d’accueil, robots.txt et une URL d’article.
• Ne créer une exception que pour le chemin, l’agent et la source nécessaires.
• Surveiller les 403, 429, resets et 5xx après le changement.

Procédure de test après une modification

La recette doit prouver l’accès attendu sans affaiblir les protections privées.

1. 1. Sauvegarder l’état initialConserver robots.txt, les règles WAF concernées et un extrait de journal daté.
2. 2. Appliquer une modification minimaleChanger uniquement la règle nécessaire, sans supprimer les protections admin, API ou fichiers sensibles.
3. 3. Rejouer HEAD et GETTester robots.txt, l’accueil et une page profonde avec les agents concernés.
4. 4. Vérifier les journauxConfirmer que la requête traverse la bonne couche et que son code correspond au résultat client.
5. 5. Contrôler les régressionsTester les zones privées, la limitation de débit et les en-têtes de sécurité.
6. 6. Refaire le contrôle après propagationRépéter à 24 heures et noter le résultat ; l’audit technique WeWorkWeb peut cadrer cette vérification.