llms.txt manquant dans un audit IA : que signifie l’avertissement ?
Vérifiez l’URL exacte, la réponse HTTP et l’objectif de l’audit avant de traiter l’absence de llms.txt comme un problème de recherche par IA.
Imaginez qu’un audit IA donne un carton rouge à votre site : « llms.txt manquant ». Avant d’ajouter un fichier pour faire disparaître l’avertissement, ouvrez le constat et identifiez l’URL et la vérification qui l’ont produit. Un index facultatif absent, une page d’erreur HTML renvoyée comme un succès et une panne du serveur appellent des décisions différentes. Aucune de ces observations, à elle seule, ne dit si une réponse d’IA citera votre site.
Comprendre ce que mesure la vérification
Conservez le nom et la version de l’outil, la date, l’avertissement exact et l’URL testée. Lisez la documentation de cette vérification. Lors de notre contrôle des sources du 9 novembre 2026, la documentation llms.txt de Lighthouse indiquait qu’une erreur serveur était signalée et qu’un fichier absent renvoyant 404 était classé « Non applicable ». Elle présentait le fichier comme facultatif. Un autre outil peut simplement indiquer s’il a trouvé un fichier. Son étiquette rouge ne change pas ce que cette requête a réellement renvoyé.
Pour les aperçus IA et le Mode IA de Google, Google indique qu’aucun nouveau fichier texte pour l’IA n’est nécessaire. Cela répond à une question d’éligibilité dans la recherche Google. Cela n’établit pas comment tous les autres assistants traitent un index. Distinguez le critère de l’audit de l’exigence de la plateforme pour décider quoi corriger.
Lire la réponse derrière le résultat
Ouvrez exactement l’URL vérifiée par l’audit. Pour examiner la requête dans Chrome, ouvrez le panneau Réseau, rechargez l’URL et sélectionnez sa requête. Regardez la méthode, l’URL finale après redirections, le statut, les en-têtes et le corps dans « Response ». Une requête HEAD ou un en-tête Content-Type seuls ne montrent pas ce qu’un GET a renvoyé.
Prenons un site de documentation fictif, docs.example. Son /llms.txt renvoie 404, mais /docs/llms.txt fournit un index Markdown. La proposition llms.txt actuelle autorise les fichiers à la racine ou dans un sous-chemin, couvrant les pages situées sous ce chemin. Un audit qui ne vérifie que le fichier racine n’a pas examiné l’index de documentation. C’est une différence de périmètre, pas la preuve qu’il faut dupliquer le fichier à la racine. Vérifiez où le client prévu le cherche avant de changer son emplacement.
Supposons maintenant que /llms.txt renvoie HTTP 200, mais que son corps soit un écran HTML « Page introuvable » aux couleurs du site. Une vérification fondée uniquement sur le statut pourrait y voir un succès. Notez le résultat réel : l’URL a renvoyé une page d’erreur HTML, pas l’index Markdown prévu. Demandez à la personne qui gère le routage d’examiner cette réponse. Si vous obtenez plutôt une page d’accueil, une page de connexion ou un contrôle d’accès, consignez ce résultat ; l’en-tête text/html seul ne permet pas de les distinguer.
Si la requête renvoie 500, notez une erreur serveur. Cela ne prouve pas que le fichier manque. Si elle fournit du Markdown lisible, examinez aussi le contenu et les liens. La proposition exige un titre de projet ou de site, mais un titre ne suffit pas à montrer que l’index décrit le site actuel ou mène à des pages utiles.
Décider à qui sert le fichier
Un index de documentation entretenu peut offrir à une personne ou à un agent un chemin court vers les informations pertinentes. OpenAI en publie un pour sa documentation développeur. Cela montre qu’un index publié existe. Cela n’établit aucune obligation pour les autres sites et ne montre pas que ChatGPT Search récupère leurs fichiers.
Si un client précis ou un processus de consultation de documentation doit utiliser le fichier, identifiez les pages qu’il doit trouver. Gardez un résumé exact, suivez les liens et vérifiez que les destinations sont actuelles et lisibles. Intégrez l’index à votre processus de mise à jour lorsque ces pages changent d’adresse. Un petit site peut aussi avoir cet usage.
Si votre objectif est simplement que les fonctionnalités d’IA de Google trouvent une page déjà utile, l’alerte de fichier manquant n’a pas établi de nouvelle exigence. Examinez les vrais problèmes d’accès et de contenu avec le guide des bases du contenu et de la technique. Ajouter un index ne prouve ni que la page liée est accessible, ni que ses affirmations sont claires.
Valider la correction avec des éléments observables
Supposons que, sur le site fictif, vous corrigiez dans /docs/llms.txt un lien qui pointait vers un guide de configuration supprimé. Rouvrez l’index, suivez le lien corrigé et confirmez que le guide attendu se charge. Relancez l’audit d’origine avec la même version de l’outil, notez l’heure et vérifiez que vous consultez le résultat de la nouvelle exécution. S’il ne vérifie toujours que /llms.txt, son résultat peut rester inchangé alors que le lien de documentation est réparé.
Gardez un compte rendu précis : « L’index de documentation pointe vers le guide de configuration actuel ; la vérification du fichier racine indique toujours son propre résultat. » Une requête consignée plus tard ne montre que ce que cet enregistrement contient, pas qu’un modèle a utilisé le contenu. Une citation exige une réponse observée. L’effet de cette modification sur les citations, les visites ou les conversions reste non vérifié tant que vous ne disposez pas d’éléments démontrant ces résultats.