Vous ne verrez jamais GPTBot dans Google Analytics. GA4 et la plupart des outils d’analyse tiers enregistrent une visite lorsque le navigateur exécute du JavaScript. Or GPTBot n’exécute pas de JS et ne déclenche donc aucun code de suivi. Pour prouver que le robot d’OpenAI a réellement exploré une page, savoir ce qu’il a récupéré et connaître la réponse reçue, la seule source fiable reste le log d’accès brut du serveur.
Pourquoi les logs serveur sont la seule source fiable
Les robots d’IA et les internautes suivent deux parcours différents. Une personne ouvre son navigateur, charge la page, exécute le JS et déclenche un événement GA4 : sa visite apparaît alors dans votre tableau de bord. Un robot comme GPTBot se contente d’envoyer une requête HTTP, de récupérer le HTML renvoyé, puis repart. Comme il n’exécute pas votre code de suivi, les outils d’analyse ne voient rien. Les logs serveur fonctionnent autrement : pour chaque requête entrante, qu’elle provienne d’un internaute, de Googlebot ou de GPTBot, Nginx ou Apache consigne l’adresse IP source, l’heure, le chemin demandé, le code de statut renvoyé et le User-Agent. Cette trace ne peut pas être bloquée côté front-end et ne disparaît pas sous prétexte que le visiteur n’exécute pas de JS.
Commencez par distinguer les trois robots d’OpenAI
Beaucoup pensent qu’OpenAI ne dispose que d’un seul robot et recherchent uniquement GPTBot dans leurs logs. Ils sous-estiment alors fortement leur visibilité réelle. OpenAI utilise au moins trois robots aux fonctions distinctes, chacun doté de son propre User-Agent. Analysez-les et comptabilisez-les séparément.
- GPTBot : récupère des contenus destinés à l’entraînement et à l’amélioration des modèles. Son User-Agent contient « GPTBot ». Il respecte robots.txt et ses adresses IP sources sont publiées sur openai.com/gptbot.json.
- OAI-SearchBot : constitue l’index utilisé par la fonction de recherche de ChatGPT. Son User-Agent contient « OAI-SearchBot ». C’est le robot le plus directement lié à la possibilité que votre site soit « cité » dans les réponses de ChatGPT.
- ChatGPT-User : intervient lorsqu’un utilisateur demande à ChatGPT de consulter un lien. Son User-Agent contient « ChatGPT-User ». Sa présence indique qu’une personne réelle accède à votre page par l’intermédiaire de ChatGPT.
- Pour aller plus loin : les mêmes logs contiennent généralement d’autres robots d’IA, comme PerplexityBot, ClaudeBot ou Google-Extended. La méthode d’analyse reste exactement la même.
Étape 1 : retrouver les traces de GPTBot dans les logs d’accès
Prenons le format combined de Nginx, le plus courant. Une ligne de log indique successivement l’adresse IP source, l’heure, « GET /blog/geo-audit HTTP/1.1 », le code de statut 200, le nombre d’octets renvoyés et, enfin, la chaîne User-Agent. Pour une requête de GPTBot, le User-Agent se termine par compatible; GPTBot/1.2; +https://openai.com/gptbot. Cette signature permet de faire ressortir son activité en quelques commandes.
- Retrouver toutes les requêtes de GPTBot : grep -i "GPTBot" /var/log/nginx/access.log
- Compter le nombre de passages aujourd’hui : grep -ic "GPTBot" access.log
- Afficher la répartition des codes de statut renvoyés (dans le format combined, la colonne 9 correspond au statut HTTP) : grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- Identifier les pages les plus souvent explorées (la colonne 7 correspond au chemin demandé) : grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- Comparer en une fois le volume d’exploration des trois robots : grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log
Ces résultats vous renseignent immédiatement sur trois points : la fréquence des passages — combien par jour et à quelles heures —, la couverture — vos pages produit et articles prioritaires sont-ils explorés, ou le robot se limite-t-il à la page d’accueil ? — et la qualité des réponses — les codes de statut sont-ils presque toujours 200 ? Si grep ne renvoie aucun résultat, GPTBot n’est pas passé pendant la période étudiée. Vérifiez alors si robots.txt ou votre pare-feu le bloque.
Étape 2 : vérifier qu’il s’agit bien du véritable GPTBot
Une chaîne User-Agent peut être falsifiée à volonté. N’importe quel robot, voire un trafic malveillant, peut inscrire « GPTBot » dans son en-tête pour usurper cette identité, contourner certaines règles ou consommer vos ressources. Une fois les requêtes repérées, vous devez donc en vérifier l’authenticité. Deux méthodes offrent un niveau de fiabilité élevé.
- Comparer avec les listes d’adresses IP officielles : OpenAI publie les plages d’adresses IP sources de chaque robot sur openai.com/gptbot.json, openai.com/searchbot.json et openai.com/chatgpt-user.json. Une requête ne doit être comptabilisée que si l’adresse IP relevée dans le log appartient à la plage correspondante.
- Vérifier le DNS inversé : effectuez une requête PTR avec host ou dig -x sur l’adresse IP source. Pour le véritable GPTBot, la résolution doit renvoyer vers un domaine appartenant à OpenAI. Effectuez ensuite une résolution directe de ce domaine et vérifiez qu’elle ramène à la même adresse IP — c’est le principe du forward-confirmed rDNS. La requête n’est fiable que si les deux vérifications concordent.
Étape 3 : déterminer ce que GPTBot récupère et quels codes de statut il reçoit
La présence du robot ne signifie pas nécessairement qu’il a pu récupérer vos contenus. Ce qui détermine réellement leur capacité à être référencés par ChatGPT, c’est ce que chaque requête permet d’obtenir. Quatre signaux sont à surveiller.
- Codes de statut : dans l’idéal, toutes les réponses sont en 200. Une forte proportion de 403 indique généralement que Cloudflare ou le WAF considère GPTBot comme un trafic suspect et le bloque. Des 404 signifient que votre sitemap ou vos liens internes pointent vers des URL invalides. Une série de 5xx révèle une erreur du serveur au moment du passage du robot.
- Pages couvertes : examinez les chemins explorés pour vérifier que les pages de tarifs, les pages présentant vos offres et les articles de fond les plus susceptibles d’être cités figurent bien dans la liste. Si le robot ne consulte que la page d’accueil et quelques anciens articles, vos contenus stratégiques restent invisibles pour l’IA.
- Consultation de llms.txt et robots.txt : les logs indiquent si le robot demande /llms.txt et /robots.txt. Si vous avez publié un fichier llms.txt mais qu’il n’est jamais consulté, ce robot ne tient actuellement pas compte de ce dispositif. N’en surestimez pas l’influence.
- Fréquence d’exploration et fraîcheur : comparez les dates de publication ou de mise à jour de vos articles avec les passages suivants de GPTBot. Si l’intervalle est trop long, vos nouveaux contenus mettront du temps à être intégrés dans la compréhension du modèle.
Commencez par lire les logs avant de parler d’optimisation
Avant de consacrer du temps à la rédaction de llms.txt, à l’ajout de données structurées Schema ou à la réécriture de vos contenus, prenez dix minutes pour interroger les logs d’accès avec grep. Tenten a déjà repris un dossier dans lequel le fichier llms.txt et les données structurées Schema du client étaient correctement configurés. L’analyse des logs a pourtant révélé que, pendant six mois, le WAF renvoyait systématiquement un code 403 à GPTBot : tous les efforts d’optimisation précédents avaient donc été vains. Les logs vous indiquent sans détour si GPTBot est passé, ce qu’il a tenté de récupérer et à quel endroit il a été bloqué. C’est l’étape la moins coûteuse et la plus importante de toute optimisation GEO technique. Pour identifier les lacunes de visibilité cachées dans vos logs et savoir lesquelles corriger en priorité, vous pouvez réserver un diagnostic GEO de 30 minutes. Nous examinerons directement l’état de l’exploration de votre site et vous indiquerons les actions les plus concrètes à engager.
