Le nouvel audit de navigation agentique Lighthouse de Chrome traite votre .txt fichier en tant que document de démarque. Si votre llms.txt n’utilise pas la syntaxe des liens markdown, vous échouez à l’audit, même si chaque lien du fichier est exact et fonctionne. J’ai effectué l’audit sur nohacks.co. Deux des six audits ont réussi. Trois sont revenus sans objet. Un échec : l’audit llms.txt, avec l’erreur textuelle « Le fichier ne semble contenir aucun lien. » Le correctif était de cinq caractères par lien. Le fichier est toujours servi sous forme de texte brut. Seul le résultat de l’audit a changé.
Lighthouse 13.3.0 a intégré la catégorie Navigation agentique ainsi que les performances, l’accessibilité, le référencement et les meilleures pratiques. Six audits dans l’ensemble par défaut : bonne formation de l’arborescence d’accessibilité (agent-accessibility-tree), décalage de mise en page cumulé (cumulative-layout-shift), découvrabilité llms.txt (llms-txt) et trois vérifications WebMCP (webmcp-registered-tools, webmcp-form-coverage, webmcp-schema-validity). La catégorie renvoie un taux de réussite fractionnaire au lieu d’un score de 0 à 100, car les normes du Web agent sont toujours en évolution.
1 audit sur 6 a échoué sur Nohacks.co
J’ai effectué l’audit via la CLI Lighthouse : npx lighthouse@latest https://nohacks.co --only-categories=agentic-browsing. Six audits sont revenus. Trois sont revenus sans objet, tous WebMCP : webmcp-registered-tools, webmcp-form-coverageet webmcp-schema-validity. Lighthouse ne donne aucune raison pour un résultat non applicable, il marque simplement l’audit et passe à autre chose. nohacks.co expose WebMCP, mais uniquement à travers l’impératif expérimental navigator.modelContext API (deux outils de glossaire, deux pour un répertoire de navigateur agent), sans annotations de formulaire déclaratif. L’analyse s’est déroulée dans un Chrome 150 sans tête par défaut sans indicateur WebMCP, de sorte que le verdict non applicable pourrait signifier que le site Web n’expose rien de ces audits reconnus, ou que l’environnement d’analyse n’avait aucune API WebMCP active à ce moment-là. Lighthouse ne dit pas lequel. Deux audits passés sans problème : agent-accessibility-tree signalé « Tous les audits ont été réussis » confirmer que la structure sémantique HTML et ARIA est suffisamment bien formée pour que les agents puissent y naviguer, et cumulative-layout-shift est revenu à zéro.
Un audit a échoué : llms-txt. Le message d’erreur textuel de Lighthouse était :
Le fichier ne semble contenir aucun lien.
Le score de la catégorie était de 0,67. Ce fut la première surprise. Le fichier sur nohacks.co/llms.txt contient de nombreux liens. Chemins de navigation vers les articles, les épisodes, les invités, le glossaire. URL des flux RSS. Modèles d’URL de fichiers audio. Le fichier contient plus de cinq kilo-octets de contenu structuré. Alors pourquoi Lighthouse ne signalait-il aucun lien ?
Analyses de phare .txt Comme Markdown et rejette les liens en texte brut
L’extension du fichier est .txtmais Lighthouse analyse le contenu comme une démarque et exige une syntaxe de lien de démarque pour que tout texte soit considéré comme un lien. Le fichier est nommé llms.txt. Le serveur HTTP le renvoie avec un text/plain Tapez MIME. Ouvrez-le dans un navigateur et vous voyez du texte brut. Mais la spécification llms.txt sur llmstxt.org définit le format comme un document markdown. La spécification est explicite : « Chaque section contient une liste à puces de liens. Chaque élément de la liste a un lien suivi de notes facultatives sur le lien, séparées du lien par deux points. « L’analyseur de Lighthouse applique cela strictement. Chaque lien doit être codé selon la syntaxe du lien markdown, [text](url)avec des crochets autour du texte du lien et des parenthèses autour de l’URL.
Mon fichier utilisait un format de texte brut plus naturel :
- Homepage: / - Publication masthead, cornerstone series, latest articles and episodes
- Articles: /blog - All articles on AXO, the agentic web, and AI agents
- Episode: /episode/[slug] - Full show notes, transcript, audio player
Mêmes destinations. Mêmes descriptions. Mêmes informations. L’analyseur de Lighthouse n’enregistre pas ces lignes en tant que liens. Sur l’ensemble du fichier, il enregistrait exactement zéro. L’audit échoue.
Un fichier avec un .txt extension, servie avec un text/plain Type MIME, qui échoue à un audit à moins qu’il ne soit formaté en démarque. Il s’agit d’une inadéquation sur laquelle la couche d’audit devra être plus honnête. L’extension dit une chose. Le type MIME dit une chose. L’analyseur est la source de la vérité et l’analyseur exige une démarque.
Le correctif est de 5 caractères par lien
Enveloppez chaque cible de lien dans la syntaxe markdown bracket-paren, [text](url)et remplacez le - séparateur avant chaque description avec : . Cinq caractères par lien. Conversion mécanique, répétée dans tout le fichier.
- [Homepage](/): Publication masthead, cornerstone series, latest articles and episodes
- [Articles](/blog): All articles on AXO, the agentic web, and AI agents
- [Episode](/episode/[slug]): Full show notes, transcript, audio player
J’ai fait la modification. Réexécutez l’audit. Le score est passé de 0,67 à 1,0. Le titre de l’audit est passé de « llms.txt ne suit pas les recommandations » à « llms.txt suit les recommandations. » Aucun élément de détail dans le rapport ultérieur. Passe propre.
Le fichier est toujours servi comme text/plain. L’extension du fichier est toujours .txt. Le contenu du fichier est toujours le même. Seul l’encodage du lien a changé.
Lighthouse mesure la syntaxe des liens analysables, et non la qualité des fichiers
L’audit vérifie si votre fichier est mécaniquement analysable. Il ne vérifie pas si le fichier décrit utilement votre site Web. Les deux lectures sont vraies en même temps.
La première lecture : L’audit mesure quelque chose de réel. La syntaxe du lien Markdown est analysable mécaniquement. Les lignes descriptives en texte brut ne le sont pas. Si un agent IA (ou l’analyseur Lighthouse remplaçant un agent) doit extraire les liens du fichier par programme, le format markdown est requis. L’audit est correct : le fichier avant mon correctif ne pouvait pas être analysé pour les liens par l’outillage standard. La conversion vers la syntaxe des liens markdown corrige un véritable écart d’interopérabilité.
Deuxième lecture : la conformité du format n’est pas la même chose que la qualité du fichier. Un llms.txt soigneusement rédigé, précis et complet qui utilise des descriptions en texte brut échoue à cet audit. Un llms.txt fin et généré automatiquement avec une syntaxe de lien markdown passe. L’audit ne peut pas faire la différence entre les deux. Le plugin WordPress AIOSEO, utilisé par plus de 3 millions de sites Web selon sa liste WordPress.org, génère des fichiers llms.txt avec une syntaxe de lien markdown par défaut, un comportement par défaut révélé par Glenn Gabe et la propre documentation du plugin le confirme. Ces fichiers générés automatiquement utilisent la syntaxe des liens markdown car c’est ce que le générateur émet. La plupart d’entre eux réussissent probablement cet audit. La plupart des fichiers llms.txt sélectionnés à la main et sensibles au propriétaire échouent probablement.
Cet écart mérite d’être pris en compte avant de considérer la réussite/l’échec de l’audit comme une mesure de la mesure dans laquelle votre site Web est réellement prêt pour les agents. L’audit vérifie si votre fichier est analysable. Il ne vérifie pas si votre fichier est utile.
Devriez-vous vous soucier de la vérification Llms.txt de Lighthouse Agentic Browsing ?
Oui, mais de peu. Lighthouse peut vous dire si votre llms.txt est analysable en tant que démarque. Il ne peut pas vous dire si le fichier décrit honnêtement votre site Web. Ce chèque est à vous. Ouvrez Chrome DevTools, cliquez sur l’onglet Phare, vérifiez que la catégorie Navigation agent est cochée et exécutez Analyser sur votre URL. L’audit prend moins d’une minute. S’il échoue en raison de l’erreur d’absence de lien, le correctif consiste en cinq caractères par lien et cinq minutes d’édition. Si le projet est adopté, la question la plus difficile sera celle que Lighthouse ne pourra pas poser. Le fichier a-t-il été généré automatiquement par un plugin que vous n’avez pas configuré, ou l’avez-vous écrit vous-même, et dans tous les cas, décrit-il réellement ce qu’est votre site Web ?
L’architecture axée sur la machine Pilier de structure se trouve au-dessous de tout cela : des modèles de données avant la mise en page, l’indépendance du rendu, un contenu qui ne dépend pas du JavaScript côté client ou des paramètres par défaut de l’affichage humain pour être lisible par machine. L’audit llms.txt est une vérification étroite au niveau de cette couche. La plus grande question structurelle, à savoir si votre surface lisible par machine décrit votre site Web avec précision, vous appartient.
Plus de ressources :
Cet article a été initialement publié sur No Hacks.
