Robots d'IA

Le suivi des robots d'IA montre quels moteurs IA visitent réellement votre site : GPTBot, ClaudeBot, PerplexityBot, Bingbot et d'autres. Il complète les audits GEO : les audits disent si les bots peuvent atteindre une page ; le suivi dit s'ils le font.

Pourquoi une capture côté serveur

Les robots d'entraînement IA n'exécutent pas JavaScript : un pixel Google Tag Manager ou JavaScript ne voit jamais GPTBot ni ClaudeBot. Citlyze capture les visites côté serveur, là où le vrai User-Agent est visible, donc même les robots sans JavaScript sont comptés.

La moitié humaine est différente : les visiteurs venus des réponses IA exécutent JavaScript ; pour le Trafic IA, un extrait navigateur ou une installation Tag Manager convient donc très bien (voir Installer le suivi du trafic IA). Les installations côté serveur de cette page capturent les deux types à la fois.

Installer le suivi

Allez dans Paramètres → Connexions → Suivi du site web et générez une clé de site. La clé a deux parties, un identifiant de clé et un secret de signature, affichées une seule fois ; copiez les deux. Ajoutez ensuite l'extrait adapté à votre plateforme (pour un guide clic par clic de chaque option, voir Installer le suivi des robots d'IA) :

• Cloudflare (recommandé) : collez l'extrait Worker devant votre site.
• Vercel / reverse proxy : ajoutez l'extrait middleware.
• WordPress : téléchargez AI Crawler Control by Citlyze, envoyez-le dans wp-admin → Extensions, puis dans ses réglages remplissez les trois champs : Tracker base URL (https://app.citlyze.com), Key ID et Signing secret. Utilisez Envoyer un événement de test (« Send test event ») pour vérifier la livraison. L'extension n'envoie rien tant que l'URL de base du tracker n'est pas renseignée.
• Serveur personnalisé / Node : pour les sites auto-hébergés (AWS, GCP, Azure, bare metal, conteneurs), ajoutez l'extrait middleware de style Express (Node 20+). Il s'adapte à Fastify, Koa ou http pur, et les autres langages peuvent implémenter directement le protocole de beacon signé.

Les extraits Cloudflare, Vercel et serveur personnalisé lisent le secret de signature dans une variable d'environnement, CITLYZE_SIGNING_SECRET (un secret chiffré du Worker sur Cloudflare), si bien que le secret n'est jamais dans du code que vous commitez ou partagez. Le plugin WordPress le conserve dans ses réglages.

Chaque événement est signé avec votre secret pour rejeter les beacons falsifiés.

Cette signature prouve que le rapport vient de votre site ; elle ne dit rien sur l'identité du visiteur. Confirmer qu'un visiteur était réellement GPTBot est une étape distincte, décrite dans Comment fonctionne la vérification.

Les boutiques Shopify standard ne peuvent pas exécuter de capture côté serveur, et Shopify ne permet pas de placer un proxy (comme Cloudflare) devant une boutique ; le suivi complet des robots n'est donc pas disponible sur Shopify standard. Les vitrines headless Hydrogen ou Oxygen exécutent du code côté serveur et peuvent utiliser l'extrait serveur personnalisé. L'hébergement Webflow ne peut pas non plus exécuter de code serveur ; sur Webflow Enterprise, un reverse proxy autogéré peut exécuter le Worker Cloudflare ou l'extrait serveur personnalisé au niveau du proxy.

Les collecteurs rapportent ce qui est arrivé à chaque requête :

• Le Worker Cloudflare, le middleware serveur personnalisé et le plugin WordPress envoient le statut HTTP exact (200, 301, 404, 410, 500, etc.), qui alimente les insights d'erreurs et de redirections ci-dessous. Le middleware Vercel s'exécute avant que la réponse existe et ne le peut donc pas ; pour obtenir les codes de statut sur Vercel, utilisez le log drain Vercel dans Suivi du site web → Logs serveur à la place du middleware.
• Pour une redirection, ces trois mêmes collecteurs envoient aussi sa destination : le chemin pour une page de votre propre site, seulement le domaine pour tout autre site.
• Pour les visites de robots, la query string est aussi envoyée (par exemple ?page=2). La query string d'un visiteur humain ne quitte jamais votre site.

Les événements voyagent par lots signés. Si Citlyze est brièvement injoignable, le Worker Cloudflare et le middleware serveur personnalisé réessaient une fois, et le plugin WordPress conserve les événements non livrés dans votre base de données WordPress jusqu'à un jour et continue de réessayer. Une nouvelle tentative n'est jamais comptée deux fois. Chaque collecteur installé met aussi à jour sa liste de robots connus au moins une fois par jour, si bien qu'un nouveau robot est reconnu sans mettre à jour l'extrait ou le plugin. La page Suivi du site web vous signale quand une version plus récente de votre extrait ou de votre plugin est disponible.

Le plugin WordPress voit chaque requête qui atteint WordPress, y compris celles qu'un autre plugin redirige avant le rendu de la page. Il ne voit pas ce qui n'atteint jamais WordPress : les pages servies depuis un cache de page complète, les redirections faites par votre serveur web ou votre CDN, et les requêtes qu'un pare-feu bloque avant le chargement de WordPress. La page de réglages du plugin vous signale quand il détecte un cache de page. Pour les sites fortement mis en cache, utilisez le Worker Cloudflare ou importez les logs de votre serveur. Si WordPress tourne derrière un proxy ou un répartiteur de charge autre que Cloudflare, indiquez dans les réglages du plugin l'en-tête d'IP client et les adresses du proxy, afin que les robots soient vérifiés par leur adresse réelle.

Utilisez un seul collecteur par site. Si un collecteur de site web et une source de logs serveur rapportent le même domaine, chaque visite est comptée deux fois ; la page Suivi du site web vous prévient dans ce cas.

Serveurs personnalisés et autres langages

L'onglet serveur personnalisé fournit un middleware Node, mais n'importe quelle stack peut rapporter : envoyez des requêtes POST HTTPS signées vers https://app.citlyze.com/api/track avec un corps JSON (256 Ko au maximum) et Content-Type: application/json. Chaque requête transporte un lot de 1 à 50 événements.

En-têtes requis :

Calcul de la signature :

1. Dérivez la clé de signature : le SHA-256 hexadécimal minuscule de 64 caractères de votre secret de signature (la chaîne ctk_... complète). Utilisez les octets UTF-8 de cette chaîne hexadécimale comme clé HMAC ; ne la décodez pas depuis l'hexadécimal.
2. Construisez le message : "3\n" + timestamp + "\n" + nonce + "\n" + bodyDigest, où bodyDigest est le SHA-256 hexadécimal minuscule des octets exacts du corps envoyé. Toute resérialisation après la signature invalide la signature.
3. x-aeo-signature est le HMAC-SHA256 hexadécimal minuscule de ce message avec la clé de signature de l'étape 1.

Conservez le secret de signature dans une variable d'environnement ou dans le coffre à secrets de votre plateforme, jamais dans le code source.

Champs du corps :

• collector : un nom court pour votre intégration, par exemple my-app/1.0 (lettres, chiffres, ., _, / et -, jusqu'à 64 caractères).
• events : la liste des événements. Chaque événement a ces champs (obligatoires sauf mention contraire) :
  • occurredAt : le moment de la requête, en millisecondes depuis l'epoch Unix. Les événements de plus de 48 heures sont ignorés.
  • host : le nom d'hôte de la requête sans le port, ou une chaîne vide. Les événements d'un hôte qui n'est ni le domaine de votre clé de site ni l'un de ses sous-domaines sont ignorés.
  • userAgent : le User-Agent du visiteur, jusqu'à 1024 caractères.
  • path : le chemin de la requête avec un / initial, sans query string ni fragment, jusqu'à 2048 caractères.
  • query (facultatif) : la query string sans le ?, pour les requêtes de robots uniquement.
  • visitorIp : l'IP du client telle que votre serveur la voit. Derrière un répartiteur de charge ou un proxy inverse, prenez-la dans l'en-tête de transfert que votre propre proxy définit ; c'est ce champ que vérifie la vérification d'identité des robots.
  • referrer : une chaîne vide, ou une URL de referrer https:// sans query ni fragment. Utile uniquement pour les visites humaines arrivant depuis des réponses d'IA.
  • utmSource (facultatif) : la valeur de utm_source, quand une visite depuis une réponse d'IA arrive sans referrer.
  • status : le statut HTTP à trois chiffres de la réponse, ou unknown si vous rapportez avant que la réponse existe.
  • method : la méthode HTTP en majuscules.
  • redirectTarget (facultatif) : pour une réponse 3xx, le Location vers lequel elle pointait.

Ne rapportez que les requêtes dont le user agent semble automatisé ou dont le referrer est un moteur de réponses d'IA, et envoyez les lots après la réponse, jamais pendant qu'un visiteur attend. Si un lot échoue avec une erreur réseau, un 429 ou un 5xx, renvoyez-le avec le même nonce et le même corps et un nouvel horodatage : un lot déjà arrivé est reconnu à son nonce et compté une seule fois. Un 429 porte un en-tête Retry-After. Tout autre 4xx signifie que le lot lui-même est invalide ; ne le renvoyez pas.

Si vous le souhaitez, récupérez une fois par jour la liste à jour des identifiants de robots connus et des hôtes de referrer d'IA depuis GET https://app.citlyze.com/api/track/registry, avec votre ID de clé dans l'en-tête x-aeo-key-id. L'en-tête de réponse x-aeo-registry-signature est le HMAC-SHA256 hexadécimal minuscule de "citlyze-registry-1\n" + bodyDigest, avec la clé de signature de l'étape 1 ; ignorez la liste s'il ne correspond pas.

Pour vérifier votre intégration, envoyez un lot avec "test": true contenant un seul événement dont le userAgent commence par citlyze-connection-test/ et dont le path est /citlyze-test. Un test correctement signé renvoie HTTP 200 et n'enregistre rien ; les vrais lots renvoient 204, que les visites apparaissent ou non dans vos rapports.

Renouveler ou révoquer une clé

Si un secret de signature a pu fuiter (par exemple commité dans un dépôt ou partagé dans une capture d'écran), utilisez Renouveler à côté de la clé. Le renouvellement émet un nouveau secret pour la même clé : l'identifiant, le nom, le domaine et tout l'historique enregistré sont conservés, mais l'ancien secret cesse immédiatement de fonctionner ; mettez donc à jour sans attendre CITLYZE_SIGNING_SECRET (ou le réglage du plugin) avec le nouveau secret. Révoquer est différent : la clé est désactivée définitivement et le suivi de ce site s'arrête.

Lire les analytics

La page Diagnostiquer → Activité des robots d'IA → Vue d'ensemble montre, pour la période sélectionnée :

• tuiles de synthèse : visites totales, robots distincts, robot principal et tendance
• visites de robots dans le temps (totaux quotidiens)
• heures de passage des robots : visites par heure de la journée
• tendances par robot dans le temps (une courbe par robot)
• détail par robot avec organisation, finalité, visites et tendance
• pages les plus crawlées (top 10, avec un lien vers la liste complète)
• bots non reconnus : des user agents de type bot ne correspondant à aucun robot IA connu, regroupés sous « Bot inconnu » pour repérer tôt les nouveaux robots

Les jours et les heures suivent le fuseau horaire de votre navigateur : une visite à 21 h à New York compte pour ce jour-là, pas pour le suivant. Le tableau par page utilise des jours UTC.

Les tendances ne comparent que des jours complets. Tant que la journée en cours n'est pas terminée, elle est exclue de la comparaison, et chaque jour complet est comparé au même jour une période plus tôt. Un robot sans visite sur la période précédente affiche Nouveau au lieu d'un pourcentage, et si le suivi a commencé après le début de la période précédente, aucune tendance n'est encore affichée.

Utilisez les périodes prédéfinies (7/30/90 jours), la plage de dates personnalisée et le filtre de robots pour affiner la vue. Les espaces de travail suivant plusieurs sites disposent aussi d'un filtre de site. Les personnes arrivées depuis des réponses d'IA sont couvertes dans Trafic IA.

Comment fonctionne la vérification

N'importe quel client peut écrire GPTBot dans son user agent. Un user agent est donc une affirmation, pas une preuve, et Citlyze le traite ainsi : les chiffres principaux ne comptent que le trafic que nous avons pu confirmer de façon indépendante.

Chaque visite reçoit l'un de trois niveaux de confiance :

• Vérifié : nous avons confirmé l'identité réseau du visiteur face à quelque chose que l'opérateur publie. Seuls ceux-ci comptent dans vos totaux.
• Probable : des éléments corroborants, par exemple votre CDN qui signale la requête comme un bot connu, mais sans confirmation indépendante.
• Non vérifié : le user agent a nommé un robot et rien ne l'a contredit, mais nous n'avons pas pu le confirmer. Affiché à part, jamais ajouté à vos totaux.

La vérification utilise ce que l'opérateur prend en charge :

Les opérateurs qui ne publient rien de vérifiable ne peuvent atteindre que non vérifié. C'est une caractéristique du robot, pas un problème de votre installation, et c'est pourquoi les vues sont séparées plutôt que fondues en un seul chiffre.

Deux points à retenir :

• Le trafic des agents est compté séparément. Les outils pilotés par des personnes, comme ChatGPT Agent, apparaissent dans l'activité des agents et non dans les totaux de robots : une personne qui clique n'est pas le même signal qu'un robot qui vous indexe.
• Parfois nous ne pouvons pas vérifier : la liste d'IP d'un opérateur peut être temporairement inaccessible. Ces visites restent non vérifiées plutôt que comptées, pour que vos totaux n'incluent jamais rien de non confirmé.

Pages crawlées

Diagnostiquer → Activité des robots d'IA → Pages explorées est la vue détaillée complète : chaque page récupérée par des robots d'IA sur la période sélectionnée, avec recherche, tri et pagination. Chaque ligne affiche les visites, la part du trafic total des robots, la tendance par rapport à la période précédente, les erreurs, les redirections, le robot principal et la date de dernière visite ; dépliez une ligne pour voir la répartition par robot et les codes de statut exacts reçus par les robots.

Des insights apparaissent au-dessus du tableau quand c'est pertinent :

• Crawlées mais jamais citées : pages que les moteurs d'IA récupèrent mais ne citent jamais dans vos réponses suivies ; candidates à un contenu plus clair et plus facile à citer.
• Pages en erreur : pages qui ont répondu aux robots par des 4xx/5xx. Une page cassée ne peut être ni lue ni citée.
• Pages qui redirigent : anciennes URL que les robots continuent de demander et d'où ils sont redirigés. Faites pointer vos liens internes et votre sitemap vers les URL finales.
• Pages récupérées pour la première fois : pages qu'aucun robot d'IA n'avait récupérées avant cette période depuis le début du suivi. Un nouveau contenu qui apparaît ici a été trouvé par les robots.

Les codes de statut et les redirections nécessitent un collecteur qui les rapporte : le Worker Cloudflare, le middleware serveur personnalisé, le plugin WordPress ou les logs serveur.

Le tableau peut être téléchargé en CSV sur les forfaits qui incluent l'export de données.

Journal d’exploration

Diagnostiquer → Activité des robots d'IA → Journal d’exploration liste chaque requête que les robots d'IA vérifiés et les agents signés ont adressée à votre site, jour par jour et dans l'ordre, regroupées en sessions d'exploration (les requêtes d'un robot sans interruption de plus de 30 minutes). Pour chaque requête, vous voyez l'heure, la page et sa query string, le code de statut et, pour les redirections, leur destination et si le robot l'a suivie dans la même session. Les pages récupérées plusieurs fois dans une session sont signalées.

Le journal d’exploration ne conserve que les requêtes des robots vérifiés et des agents signés, jamais celles des autres visiteurs, et n'enregistre jamais d'adresse IP ni de user agent. Les valeurs des paramètres de requête susceptibles de contenir des identifiants ou des données personnelles (comme token ou email) sont remplacées par redacted. Le nombre de jours consultables dépend de votre forfait ; voir Forfaits et limites. Le journal d'une journée peut être téléchargé en CSV sur les forfaits qui incluent l'export de données.

Accéder aux données via API et MCP

Les visites de robots sont disponibles par programme une fois le suivi installé :

• REST : GET /api/v1/crawler-events ; voir la ressource AI Crawler Events.
• MCP : l'outil list_crawler_events ; voir la référence des outils MCP.

Les deux sont en lecture seule et limités à votre espace de travail. La ressource REST filtre par crawler_id, site suivi et path exact ; les visites humaines depuis les réponses IA sont exposées via GET /api/v1/ai-referrals.