Signaux de fraîcheur face à la réalité de l’exploration

Pourquoi l’Observatoire Scrubnet s’intéresse à la fraîcheur

L’Observatoire des robots d’exploration de Scrubnet est un environnement de recherche public et indépendant, intégré à son ensemble plus vaste d’outils et de connaissances.

Il héberge des flux autorisés et lisibles par machine, qui offrent une surface publique cohérente sur laquelle observer les requêtes des robots.

Les flux sont proposés dans quatre formats :

• HTML
• Texte brut
• JSON
• Markdown

L’un des principaux objectifs du système est de rendre ses signaux de fraîcheur aussi exacts que possible.

Lorsqu’un contenu change, Scrubnet s’efforce d’aligner les informations de modification exposées dans le flux, le sitemap et la réponse HTTP sur la mise à jour réelle. Lorsqu’un contenu n’a pas changé, les horodatages ne doivent pas être artificiellement actualisés au seul motif qu’une page a été régénérée ou demandée.

Cette distinction est importante.

Google indique utiliser les valeurs <lastmod> des sitemaps lorsqu’elles sont systématiquement et manifestement exactes. Son infrastructure d’exploration prend également en charge les validateurs de cache HTTP tels que Last-Modified, If-Modified-Since, ETag et If-None-Match.

L’Observatoire est donc conçu autour de l’exactitude des signaux, et non de l’inflation des horodatages.

L’objectif n’est pas d’affirmer que ces flux bénéficieront de davantage d’exploration, d’indexation ou de visibilité dans l’IA. Il s’agit de créer un environnement où le comportement des robots peut être étudié tout en réduisant l’incertitude entourant les données de fraîcheur sous-jacentes.

Construire l’Observatoire de la fraîcheur

Les tableaux de bord traditionnels de journaux sont utiles pour les totaux et les chronologies, mais il devient difficile d’appréhender simultanément les relations entre plusieurs dimensions :

• Quand la requête a-t-elle eu lieu ?
• Quel format de fichier a été demandé ?
• Quel robot a effectué la requête ?
• Quel était l’âge du contenu demandé ?
• L’activité était-elle régulière ou concentrée en pics ?

L’Observatoire de la fraîcheur a été conçu comme une visualisation 3D HTML5 interactive afin de faciliter l’exploration de ces relations.

Le graphe est divisé en quatre couloirs représentant HTML, TXT, JSON et Markdown. Chaque colonne représente l’activité des robots pour un intervalle temporel et un format donnés.

La hauteur d’une colonne est linéairement proportionnelle au volume de requêtes, tandis que sa couleur représente l’âge moyen du contenu demandé. L’échelle chromatique de fraîcheur s’adapte au jeu de données visible, ce qui permet de garder les différences lisibles lorsque les filtres ou les plages de dates changent.

Les utilisateurs peuvent tourner autour de la visualisation, zoomer sur des périodes précises, sélectionner des colonnes et examiner les détails des requêtes sous-jacentes.

L’Observatoire comprend également des filtres pour :

• Un robot individuel
• Plusieurs robots
• Les formats de fichiers
• Les plages de dates
• Une agrégation horaire, quotidienne ou hebdomadaire

L’analyse horaire est limitée aux plages de 31 jours ou moins afin de préserver la réactivité de la visualisation et du service d’agrégation.

Les compteurs récapitulatifs situés au-dessus du graphe s’actualisent selon les filtres actifs et indiquent :

• Le nombre total de requêtes
• L’âge moyen des contenus demandés
• Le pourcentage de réponses réussies
• Le nombre de robots sélectionnés
• Le nombre de formats sélectionnés

Toutes les moyennes et tous les pourcentages de réponse sont calculés à partir des données actuellement visibles dans le graphe, et non de la base de données non filtrée.

Maintenir un jeu de données ciblé

L’Observatoire s’appuie sur un service d’agrégation MySQL mis à jour.

Seules les requêtes vérifiées de robots sont incluses. Les enregistrements dépourvus d’un âge de contenu exploitable sont exclus, notamment les requêtes de type sitemap pour lesquelles l’âge d’une ressource individuelle ne peut pas être déterminé de manière fiable.

Le jeu de données est également limité à HTML, TXT, JSON et Markdown afin que des ressources sans rapport ne faussent pas la comparaison.

On obtient ainsi un jeu de données d’observation ciblé, mais il est important de comprendre ce qu’il représente.

L’Observatoire mesure des requêtes, et non l’indexation, la récupération, l’entraînement de modèles, les classements ou les citations. La demande d’une ressource par un robot confirme uniquement que ce robot y a accédé.

Les résultats ci-dessous décrivent les comportements observés sur les flux de Scrubnet pendant la période sélectionnée. Ils ne doivent pas être automatiquement transposés à d’autres domaines, à des sites plus vastes ou à des environnements de contenu différents.

Les formats sont publiés comme des représentations utiles et lisibles par machine, et non comme des traitements contrôlés et randomisés. Leur balisage, leurs métadonnées et la taille de leur charge utile diffèrent : le nombre de requêtes montre donc leur répartition par format, mais n’établit pas que le format à lui seul est à l’origine de cette différence.

Amazonbot a généré davantage de requêtes Markdown

L’une des différences de format les plus nettes provenait d’Amazonbot.

Pendant la période analysée :

• Aucune requête d’Amazonbot vers des ressources JSON n’a été observée.
• Markdown a reçu environ deux fois plus de requêtes que HTML ou TXT.
• Les contenus Markdown demandés par Amazonbot étaient, en moyenne, nettement plus anciens que les contenus HTML et TXT qu’il demandait.

Amazonbot semblait également suivre un cycle d’activité d’environ 24 heures. D’après le fuseau horaire utilisé par le tableau de bord de Scrubnet, sa cadence d’exploration augmentait davantage pendant la nuit.

L’association d’une activité Markdown plus forte et de contenus demandés plus anciens est particulièrement intéressante.

Elle pourrait indiquer une file propre au format, un processus récurrent de réexploration historique ou un objectif différent pour les requêtes Markdown. Les données ne révèlent toutefois pas encore la cause de ce comportement.

Il serait également prématuré d’y voir la preuve que les systèmes d’Amazon préfèrent universellement Markdown. Pour l’instant, le résultat ne s’applique qu’aux ressources Scrubnet admissibles et à la période observée.

La documentation d’Amazon décrit Amazonbot comme un robot utilisé pour améliorer les produits et services d’Amazon, les contenus recueillis pouvant contribuer à l’entraînement de modèles d’IA.

Des périodes d’observation plus longues pourront montrer si cette répartition des requêtes reste stable ou si elle a été influencée par une campagne d’exploration temporaire.

Les requêtes Markdown de Meta se sont produites par vagues concentrées

Le robot externe de Meta a présenté un schéma différent.

Ses requêtes HTML, TXT et JSON étaient relativement réparties dans le temps. En revanche, les requêtes Markdown formaient de grands pics concentrés.

Plutôt que d’explorer Markdown à une cadence de fond régulière, Meta semblait demander des groupes de ressources Markdown pendant des périodes d’activité plus restreintes.

L’âge des contenus demandés variait également selon le format. Pendant la période analysée, Meta a demandé des contenus HTML plus anciens que les contenus TXT ou JSON.

Cela laisse penser que la planification des requêtes n’est peut-être pas partagée uniformément entre les formats. Différents formats pourraient être traités par des files, des campagnes ou des systèmes distincts, même si les journaux ne suffisent pas à confirmer l’architecture sous-jacente.

L’observation principale est que le total agrégé des requêtes peut masquer des comportements importants. Deux formats peuvent recevoir un nombre de requêtes similaire sur un mois tout en suivant des schémas temporels complètement différents.

ClaudeBot a affiché un faible niveau de fond ponctué de grands pics

ClaudeBot a produit l’un des profils d’exploration les plus reconnaissables.

Pendant une grande partie de la période, il a maintenu une cadence de requêtes relativement faible mais régulière. Certains jours, ce niveau de fond était interrompu par des pics d’exploration étonnamment élevés.

Aucun calendrier répétitif manifeste n’a encore été identifié pour ces vagues.

ClaudeBot a accédé aux quatre formats, HTML recevant le plus grand volume total de requêtes. Comparée à celles d’Amazonbot et de Bingbot, sa répartition par format semblait plus équilibrée.

Anthropic distingue ClaudeBot, qui peut collecter des contenus web publics pour le développement de modèles, de ses agents dirigés par les utilisateurs et de ses agents propres à la recherche. Anthropic indique également que ses robots respectent les règles de robots.txt.

Les pics inexpliqués peuvent correspondre à des collectes plus larges, à des campagnes de réexploration ou à des variations de la demande, mais cela reste une hypothèse.

Un jeu de données couvrant une période plus longue sera nécessaire pour déterminer si ces pics sont réellement irréguliers ou s’ils font partie d’un cycle plus lent, invisible sur 28 jours.

Les requêtes de Googlebot et de GoogleOther ont parfois coïncidé

Googlebot et GoogleOther ont tous deux accédé aux quatre formats de Scrubnet avec une relative régularité.

La surprise ne venait pas de leur couverture globale des formats, mais du moment de certaines activités.

Les deux robots ont produit un important pic de requêtes TXT à peu près au même moment.

Un seul événement synchronisé ne suffit pas à démontrer une coordination. Il laisse néanmoins penser que ces deux identités de robots ne doivent pas nécessairement être considérées comme des systèmes totalement indépendants.

Google décrit GoogleOther comme un robot générique que différentes équipes produit peuvent utiliser pour récupérer des contenus accessibles au public. Google a également expliqué que plusieurs clients d’exploration pouvaient fonctionner sur une même infrastructure sous-jacente, tout en utilisant des identités et des configurations de robot différentes.

Une infrastructure commune ne signifie pas que Googlebot et GoogleOther poursuivent le même objectif. Cela signifie cependant que des similitudes de calendrier pourraient résulter d’une planification, de sources de découverte, d’une infrastructure ou de décisions relatives à la capacité d’exploration partagées.

D’autres événements synchronisés devront être enregistrés avant de tirer une conclusion plus solide.

Peu de requêtes Markdown de Bingbot ont été observées

Bingbot a présenté un comportement par format presque inverse de celui d’Amazonbot.

L’activité Markdown était pratiquement absente du jeu de données sélectionné, tandis que HTML recevait la majorité des requêtes de Bingbot.

Cela rappelle qu’il n’existe peut-être pas un format universellement « adapté aux robots d’exploration ».

Markdown est souvent présenté comme un format idéal pour les systèmes d’IA parce qu’il est léger, structuré et facile à traiter. Sur Scrubnet, cela semble pertinent pour le comportement d’Amazonbot, mais pas pour l’activité observée de Bingbot.

HTML reste le format demandé avec la plus grande régularité sur l’ensemble plus large des robots.

Cela ne rend pas nécessairement HTML intrinsèquement supérieur. Il bénéficie peut-être simplement d’une prise en charge plus large, de voies de découverte plus solides ou d’un rôle mieux établi dans les systèmes de traitement des robots.

La plupart des requêtes ciblaient des contenus anciens

Les différences de format propres à chaque robot sont instructives, mais le résultat le plus surprenant apparaît lorsque toutes les requêtes vérifiées sont examinées ensemble.

Sur la période de 28 jours sélectionnée :

• L’âge moyen des contenus demandés était d’environ 120 jours.
• 4 % des requêtes concernaient des contenus datant d’un jour au maximum.
• 8 % concernaient des contenus âgés d’un à sept jours.
• Environ 88 % visaient des contenus âgés de plus de sept jours.

Ces pourcentages décrivent les requêtes, et non les taux de sélection. La répartition par âge de toutes les ressources admissibles des flux constitue un dénominateur important : un corpus composé principalement d’URL anciennes générerait naturellement une majorité de requêtes vers des contenus anciens.

Les flux de Scrubnet sont expressément conçus pour exposer des informations de fraîcheur exactes. Pourtant, les requêtes des robots se dirigeaient en très grande majorité vers des ressources plus anciennes.

À première vue, cela peut sembler contredire l’importance que les plateformes de recherche accordent aux sitemaps, aux dates de modification, à la mise en cache HTTP et aux notifications de mise à jour.

Une interprétation plus prudente consiste à distinguer les signaux de fraîcheur de l’allocation de l’exploration.

Les signaux de fraîcheur peuvent aider un robot à comprendre qu’un élément a changé. Ils peuvent l’aider à donner la priorité à une URL, à éviter des transferts de données inutiles ou à déterminer si une ressource mise en cache doit être actualisée.

Ils ne garantissent pas que les URL récemment modifiées représenteront la majorité des requêtes.

L’activité des robots peut également être influencée par :

• La proportion d’URL anciennes et nouvelles disponibles
• L’historique d’exploration
• La popularité ou l’importance perçue des ressources
• Les objectifs propres au robot
• Les mécanismes de découverte
• Les calendriers de réexploration et de validation
• La capacité de l’hôte
• Les files de traitement propres au format
• Les campagnes de collecte plus larges

Il est également possible que des signaux de fraîcheur exacts rendent le traitement des ressources anciennes plus efficace sans réduire visiblement le nombre de requêtes. Les requêtes conditionnelles et les réponses 304 Not Modified, par exemple, peuvent permettre à un robot de valider une ressource existante sans télécharger son corps complet.

L’Observatoire actuel montre principalement quelles ressources ont été demandées et leur âge enregistré. Une future analyse des en-têtes de requêtes conditionnelles et du comportement des réponses pourra révéler un autre aspect de la fraîcheur.

Ce que les résultats ne prouvent pas

Ces résultats doivent être considérés comme des observations, et non comme des règles universelles applicables aux robots.

Ils ne prouvent pas que :

• Amazonbot n’explore jamais le JSON.
• Bingbot ne peut pas ou ne veut pas explorer Markdown.
• Markdown est le format préféré d’Amazonbot sur l’ensemble du web.
• Meta explore toujours Markdown par vagues.
• Les pics de ClaudeBot sont aléatoires.
• Googlebot et GoogleOther partagent le même calendrier d’exploration.
• Les signaux de fraîcheur sont sans effet.
• Les contenus plus anciens ont davantage de valeur pour les robots.

Scrubnet représente un seul hôte, une seule architecture de flux et une collection définie de ressources.

La publication de ces résultats ne vise pas à produire une nouvelle liste de contrôle définitive pour l’optimisation. Elle vise à rendre le comportement des robots suffisamment visible pour permettre de poser de meilleures questions.