OAI-SearchBot : le robot dédié à la recherche
OpenAI documente OAI-SearchBot comme le robot utilisé pour faire apparaître des sites dans les fonctionnalités de recherche de ChatGPT.
Un site peut contrôler ce robot dans robots.txt et doit également laisser passer les requêtes provenant des plages IP publiées lorsqu’il souhaite permettre cette exploration.
GPTBot : un usage distinct lié aux modèles
GPTBot est documenté comme le robot qui explore du contenu susceptible d’être utilisé pour améliorer et entraîner les modèles génératifs fondamentaux d’OpenAI.
Bloquer GPTBot indique que le contenu du site ne doit pas être utilisé pour cet usage. Cela ne constitue pas la même décision que bloquer OAI-SearchBot.
Les deux contrôles sont indépendants
OpenAI précise qu’un éditeur peut autoriser OAI-SearchBot pour les usages de recherche tout en refusant GPTBot pour l’entraînement. L’inverse peut également être configuré.
Cette séparation est importante pour éviter de présenter un simple Allow ou Disallow comme une préférence générale et unique vis-à-vis de tous les usages OpenAI.
Autoriser un robot ne garantit pas une citation
L’accès technique constitue une condition possible de découverte, pas une promesse de visibilité. OpenAI ne garantit pas qu’une page autorisée apparaîtra dans une réponse, ni qu’elle sera citée pour une requête donnée.
Le diagnostic GEO doit donc séparer accessibilité technique, qualité du contenu, présence observée et citations réellement mesurées.
Traiter GPTBot et OAI-SearchBot comme deux décisions distinctes
Les deux user-agents répondent à des usages documentés différents par OpenAI. OAI-SearchBot est associé aux usages de recherche et à la possibilité pour le contenu d’être découvert et présenté dans les fonctionnalités de recherche. GPTBot correspond au signal permettant notamment à un éditeur de refuser l’utilisation de pages pour certains usages liés à l’amélioration et à l’entraînement des modèles.
Un éditeur peut donc décider d’autoriser l’un et de refuser l’autre. L’audit ne doit pas réduire cette politique à un simple autoriser OpenAI ou bloquer OpenAI.
Lire robots.txt dans son ensemble
Une règle dédiée à un user-agent doit être interprétée dans le contexte du fichier réellement servi. Plusieurs groupes, chemins et règles génériques peuvent coexister, et différents sous-domaines peuvent exposer des fichiers robots.txt différents. Une vérification portant uniquement sur deux lignes copiées hors contexte n’est donc pas suffisante.
Récupérez la version publique sur l’hôte concerné et comparez-la à la politique voulue. Cette étape permet aussi de détecter un fichier ancien servi par un CDN ou une configuration différente de celle présente dans le dépôt.
Vérifier également les protections situées devant le site
Une autorisation dans robots.txt ne suffit pas toujours lorsqu’un WAF, un CDN, une protection anti-bot, une authentification ou une limitation de débit refuse ensuite les requêtes automatisées. Le diagnostic GEO doit donc distinguer l’autorisation déclarée et la capacité réelle du crawler à atteindre les pages.
Lorsque des logs ou des outils de protection sont disponibles, ils peuvent aider à identifier des réponses 403, 429 ou d’autres blocages. Cette analyse reste technique : elle ne permet pas à elle seule de conclure qu’une page sera utilisée ou citée.
Ne pas confondre accessibilité et visibilité
Autoriser OAI-SearchBot rend possible l’accès selon la politique du site, mais ne garantit pas qu’une URL sera sélectionnée comme source pour une requête précise. La découverte technique, la présence dans une réponse, l’attribution comme source et le trafic reçu sont des phénomènes distincts.
Le rapport GEO doit donc présenter ces étapes séparément. Une configuration correcte de robots.txt est un contrôle technique utile, pas une promesse de visibilité dans ChatGPT.
Maintenir une politique de fraîcheur élevée
Les crawlers, leurs plages d’adresses, leur documentation et leurs usages peuvent évoluer. Une page qui décrit ces mécanismes doit donc être révisée plus fréquemment qu’un concept SEO stable. Conservez la date de dernière vérification et privilégiez les sources officielles actuelles plutôt qu’une capture ancienne ou une liste copiée depuis un article tiers.
Cette discipline évite qu’une recommandation techniquement correcte au moment de sa rédaction reste publiée après une évolution de la documentation.
Formaliser la décision de l’éditeur
Une règle robots.txt devrait correspondre à une décision documentée : autoriser l’usage de recherche, refuser certains usages liés aux modèles ou appliquer une autre politique. Cette trace est utile lorsqu’une future équipe trouve une règle inhabituelle et envisage de la supprimer sans connaître sa raison.
Lors d’une revue, comparez d’abord cette décision avec la documentation officielle actuelle, puis vérifiez la configuration publique.
- Politique définie par user-agent.
- robots.txt public vérifié.
- Protections CDN/WAF contrôlées.
- Documentation officielle récente.
- Aucune promesse de citation.
Sources officielles utiles
Ces références servent à vérifier les mécanismes décrits. Elles ne garantissent ni positionnement, ni indexation, ni citation par un moteur ou une IA.
Passer du diagnostic à l’action
Un audit GEO peut aider à vérifier les signaux techniques et éditoriaux observables de votre site, sans promettre qu’une IA le citera. Lancer un audit GEO.