Skip to main content
Analytics des crawlers est disponible avec les offres Business, Enterprise et Agency Business, ou grâce à une activation explicite de la fonctionnalité.
Ouvrez Measure > Analytics des crawlers pour examiner les requêtes de crawlers acceptées depuis une source de logs connectée. La configuration se trouve dans Paramètres sur cette page. Analytics des crawlers stocke des agrégats quotidiens bornés. Il ne conserve ni événements de trafic bruts ni activité humaine, et il ne prouve pas qu’une page demandée a été indexée, utilisée pour l’entraînement ou citée.

​
Choisir une source de livraison

La page de configuration propose ces collecteurs : AWS CloudFront est un connecteur actif dans la configuration actuelle. Ce n’est pas une intégration à venir. Une marque utilise une seule source de livraison activée. Après activation, changer de fournisseur nécessite une migration explicite. Un connecteur en attente, non activé, peut être remplacé depuis la configuration.

​
Créer et protéger une clé

Créez une clé dédiée à la source sélectionnée. Le secret en clair n’est affiché qu’une fois ; l’interface n’affiche ensuite que son préfixe. Vous pouvez conserver jusqu’à 5 clés actives par intégration. Pour effectuer une rotation, créez la clé de remplacement, mettez à jour la source, confirmez la livraison, puis supprimez l’ancienne clé. Choisissez un fuseau horaire IANA lors de la création de la première clé. Il définit les instantanés quotidiens et devient immuable après activation.

​
Limites propres à chaque fournisseur

​
Flux gérés

  • Vercel envoie les logs de production Static et Runtime en JSON. Vercel ne peut pas filtrer le drain par user agent : les lignes humaines transmises sont écartées par Qwairy mais peuvent compter dans le volume de livraison Vercel. L’échantillonnage rend les totaux partiels.
  • Cloudflare Logpush ne doit envoyer que les champs listés dans la configuration et appliquer son préfiltre de crawlers. Le job doit utiliser max_upload_bytes: 5000000 et max_upload_records: 10000.
  • CloudFront utilise la liste exacte de champs Standard Logging v2 indiquée dans la configuration, une sortie JSON, un buffer HTTP Firehose de 1 Mio et 60 secondes, et une sauvegarde des échecs dans S3. Des intervalles de livraison plus courts ne sont pas pris en charge.
  • Akamai utilise les champs DataStream 2 listés, une sortie JSON, l’option Log User-Agent Header et une fréquence d’envoi de 60 secondes ou plus.
  • Fastly utilise le format JSON minimal fourni. Sa configuration accepte jusqu’à 10 000 entrées et 2 000 000 octets par requête ; les tableaux JSON, le NDJSON et gzip sont pris en charge.
  • Netlify envoie l’intégralité de son flux Traffic Logs et ne propose pas de filtre de drain limité aux crawlers. Le User-Agent doit rester disponible pour la classification. Qwairy ignore le champ d’IP client et ne conserve ni les requêtes, ni les lignes humaines, ni les payloads bruts.
Pour les sources à fort volume qui ne peuvent pas filtrer avant livraison, évaluez le coût de livraison du fournisseur et les plafonds d’ingestion avant l’activation.

​
Collecteurs edge et applicatifs

L’API HTTP générique accepte des requêtes POST avec Content-Type: application/json et X-API-Key. Chaque enregistrement utile contient la méthode, le chemin, le nom d’hôte, le user agent, l’horodatage et, en option, le code de statut. Filtrez les user agents de crawlers d’IA connus dans votre couche serveur ou edge avant l’envoi. Un lot générique peut contenir jusqu’à 1 000 enregistrements et le plafond d’un lot normalisé est de 2 000 000 octets. Les recettes Cloudflare Worker et WordPress appliquent ce modèle de collecteur au niveau edge ou applicatif. Relisez le code généré avant déploiement et conservez la clé dans un secret côté serveur.

​
Règles de traitement

La page de configuration permet d’exclure des chemins et des user agents avant l’agrégation. Les motifs ne tiennent pas compte de la casse et acceptent les jokers, à raison d’un par ligne. Vous pouvez configurer jusqu’à 32 règles de chemin et 32 règles de user agent. Chaque motif est limité à 256 octets et chaque ensemble de règles à 4 096 octets.

​
Lire le tableau de bord

Les périodes disponibles sont Dernières 24 heures, 7 derniers jours et 30 derniers jours. Analytics des crawlers utilise des jours analytiques dans le fuseau horaire configuré pour l’intégration. Dernières 24 heures désigne le jour analytique en cours, de son minuit local jusqu’à l’instantané actuel ; ce n’est pas une fenêtre glissante de 24 heures. Les autres périodes incluent le jour analytique en cours et les 6 ou 29 jours analytiques précédents. Les totaux, les répartitions par crawler, les graphiques et les tableaux de pages utilisent l’ensemble public des identités de User-Agent observables et propres à l’IA prises en charge. Le registre d’ingestion peut reconnaître d’autres identités pour la classification et la compatibilité, mais elles sont exclues des totaux et tableaux publics actuels. La classification repose sur un jeton pris en charge dans le User-Agent HTTP. Qwairy ne vérifie ni l’IP source ni le DNS inverse : une occurrence prouve la chaîne d’identité reçue, pas l’origine du demandeur. Les crawlers de recherche traditionnels et les jetons de politique robots comme Google-Extended sont exclus des totaux publics d’occurrences. L’ensemble public actuel d’identités est :
  • Claude-SearchBot, MistralAI-Index, OAI-SearchBot et PerplexityBot ;
  • ChatGPT-User, Google-GeminiNotebook, MistralAI-User, Perplexity-User, Claude-User et Google-CloudVertexBot ;
  • ClaudeBot, GPTBot et GrokBot.
Google-NotebookLM est accepté comme alias HTTP de l’identité canonique Google-GeminiNotebook. La page affiche :
  • les occurrences observées ;
  • les pages qui ont renvoyé au moins une réponse HTTP 2xx à un crawler classé ;
  • les identités de crawlers observées ;
  • la fréquence moyenne sur les tranches quotidiennes observées ;
  • les tendances, la répartition par crawler, l’état des pages, les groupes de codes de statut et le détail des pages.
Le tableau Pages demandées par les crawlers IA liste chaque page avec son dernier crawl, ses occurrences, sa fréquence moyenne, les crawlers IA et les réponses HTTP. Recherchez des pages par chemin, filtrez-les par état et triez les colonnes. Un chemin pseudonymisé est signalé comme tel et ne peut pas être ouvert comme URL. Les états des pages sont calculés ainsi :
  • Nouveau : la première observation conservée de la page date des 7 derniers jours, borne incluse (firstSeenAt >= now - 7 days).
  • Très crawlée : la page fait partie du premier décile par occurrences de crawlers pris en charge sur les 7 jours analytiques en cours, a une activité sur au moins 2 de ces jours et n’est pas négligée.
  • Négligé : la dernière observation conservée de la page est strictement antérieure à la limite des 30 jours.
Nouveau et Très crawlée peuvent apparaître ensemble. Négligé est exclusif et ne peut apparaître avec aucun des deux. Le calcul de Très crawlée utilise toujours la fenêtre des 7 jours analytiques en cours, indépendamment de la période choisie pour les occurrences affichées. Une livraison manquante n’est pas interprétée comme un zéro. L’interface distingue les états observé, non mesuré et ingestion incomplète. Les quotas ou les lacunes du fournisseur produisent incomplete_ingestion. Le marqueur ≥ est réservé à un compte dont la précision numérique est plafonnée ; la livraison « au moins une fois » est signalée séparément, car des renvois reconditionnés peuvent dupliquer des observations. Les agrégats quotidiens par page et par crawler sont conservés 30 jours analytiques. Les preuves de continuité de livraison sont conservées 13 mois. Les identités durables de pages conservent firstSeenAt, lastSeenAt et lifetimeCount après l’expiration des agrégats quotidiens. Une identité de page n’est créée qu’après au moins une réponse HTTP 2xx.

​
Confidentialité et rapprochement des chemins

Avant l’agrégation, Qwairy supprime les chaînes de requête et les fragments. Les segments d’apparence sensible, comme les longs identifiants numériques, les adresses e-mail, les UUID, les longues valeurs hexadécimales, les JWT et les jetons à forte entropie, sont remplacés par un pseudonyme à sens unique propre à l’intégration. Les chemins qui dépassent la longueur prise en charge sont aussi bornés par un pseudonyme. Les comptes d’occurrences et les horodatages de cycle de vie restent réels, mais un chemin pseudonymisé ne peut être ni reconstitué ni rapproché d’une intégration à l’autre. Performance des pages ne lui associe aucun titre et l’exclut du rapprochement avec GA4, Search Console et Bing. Les plafonds techniques d’ingestion sont de 10 000 000 événements par intégration et par jour et de 200 000 000 événements par équipe facturée et par jour. Ils protègent l’infrastructure partagée et ne limitent pas le nombre de pages.

​
Valider la connexion

  1. Utilisez le point de terminaison et le schéma d’authentification affichés pour la source choisie.
  2. Envoyez l’événement de test du fournisseur ou une requête de crawler autorisée.
  3. Attendez que le connecteur passe de l’état en attente à connecté une fois des données agrégées acceptées.
  4. Vérifiez les alertes de continuité de livraison avant d’interpréter un zéro.
  5. Comparez avec des logs sources équivalents et non échantillonnés pour rapprocher les totaux.

​
Pages associées