Suivre llms.txt sans métriques trompeuses

Un tracker fiable exige des entrées stables et une incertitude visible. Cette méthode transforme des requêtes planifiées en série temporelle auditable.

Dernière mise à jour:

Un bon tracker mesure si une liste fixe d’hôtes sert un fichier parsable à une URL donnée et à une date donnée. Il sépare les pannes réseau des fichiers absents et ne transforme jamais publication en usage par les agents, citation ou impact SEO.

À retenir

  • Versionnez la composition du panel et la règle d’URL.
  • Séparez absent, fallback HTML, malformé, valide et injoignable.
  • Publiez entrées et agrégats pour rendre le dénominateur reproductible.

Que doit mesurer le tracker ?

Définissez une seule question. Notre suivi demande si chaque hôte sert une réponse texte commençant par un H1 à https://hote/llms.txt. Il ne mesure pas la lecture par un agent ni l’utilité du fichier.

Le panel public contient 219 hôtes. Le 3 août, 218 étaient joignables et 113 validaient la condition racine. Le dénominateur du taux de 51,8 % est donc 218.

Utiliser des états explicites

Ne réduisez pas tous les échecs à « absent » :

  • valide : réponse texte réussie avec H1 ;
  • absent : réponse 404 ou 410 explicite ;
  • restreint : réponse 401 ou 403 ;
  • erreur serveur : réponse 5xx ;
  • autre erreur HTTP : toute autre réponse en échec ;
  • HTML : shell d’application ou page d’erreur ;
  • malformé : texte sans structure minimale ;
  • injoignable : timeout ou erreur réseau.

Seuls les états joignables appartiennent au dénominateur du taux de présence.

Construire le pipeline planifié

Stockez le panel dans Git avec nom et catégorie. Récupérez les fichiers par lots limités, suivez les redirections, fixez un délai et utilisez un user-agent transparent. Conservez URL demandée et destination finale. Pour plafonner réellement la taille, arrêtez la lecture du flux plutôt que de tronquer le texte après téléchargement complet.

Écrivez des snapshots datés avant de produire annuaire et agrégats. Exécutez la tâche selon un calendrier, commitez uniquement les mesures modifiées, puis passez les mêmes gates de build et QA que toute publication.

Le benchmark des liens décrit les réessais. L’annuaire expose le sous-ensemble valide courant.

Publier sans exagérer

Affichez taille du panel, base joignable, nombre valide, date, chemins testés, condition du parseur et exclusions avec chaque pourcentage. Liez adoption-stats.json et adoption-panel.json.

N’inférez jamais le comportement des agents depuis la publication. Des logs serveur formeraient un jeu de données séparé, avec leur propre méthode de vérification des bots.

Peut-on ajouter des hôtes ?

Oui, mais versionnez le changement et ne fusionnez pas les taux avant et après sans rupture de série.

Les erreurs réseau comptent-elles comme absence ?

Non. Elles ne révèlent rien sur la présence du fichier.

Un H1 valide suffit-il à recommander le fichier ?

Non. C’est une condition reproductible d’inclusion, pas une approbation qualitative.

Sources