Pages llms.txt et manifeste d'agent : un index machine maintenu pour votre site

Une page llms.txt et manifeste d’agent est un index destiné aux machines qui indique aux systèmes d’IA ce que représente un site, quelles pages publiques sont faisant autorité et — lorsque l’entreprise prend en charge des actions d’agent — quelles capacités et politiques vérifiées s’appliquent. Il s’agit d’une carte vers des sources maintenues, et non d’un substitut à ces sources ni d’une promesse qu’un robot d’exploration particulier l’utilisera.

Son contrat est identité → périmètre → destinations faisant autorité → capacités optionnelles → contraintes → fraîcheur. Le fichier réussit lorsqu’une machine peut le récupérer, l’interpréter sans deviner, suivre des URL canoniques en direct et arriver à des faits qui correspondent encore à la réalité de production.

Questions auxquelles elle répond

La question principale est : « Quelles parties de ce site un système d’IA devrait-il utiliser pour comprendre l’organisation, son contenu et ses actions prises en charge ? » Les questions complémentaires incluent :

• Quel est le nom canonique du site, son domaine, son objectif et son public ?
• Quelles pages de produit, service, documentation, tarification, politique et support sont faisant autorité ?
• Quelles pages doivent être privilégiées par rapport aux archives, pages de campagne, paramètres ou versions régionales en double ?
• Le site expose-t-il une véritable capacité d’agent, ou seulement des informations lisibles par un humain ?
• Où sont documentés l’authentification, les limites de débit, le traitement des données, les conditions commerciales et le support ?
• Quelles déclarations sont des conseils descriptifs plutôt que des règles de contrôle d’accès ?
• Qui possède le fichier, quel événement déclenche une mise à jour et comment la dérive est-elle détectée ?

Quand utiliser ce type de publication

Utilisez ce type lorsque le site dispose d’assez de contenu public et durable pour bénéficier d’un index orienté machine organisé et que quelqu’un peut en assurer la maintenance. La raison de le publier est de réduire l’ambiguïté pour les systèmes de récupération, et non de créer une URL supplémentaire pour le plaisir.

Ne confondez pas les conseils avec le contrôle. robots.txt exprime les préférences d’accès des robots ; un sitemap XML aide les robots à découvrir des URL ; l’authentification et l’autorisation décident si une action peut avoir lieu. llms.txt fournit un contexte organisé. Une phrase dans llms.txt ne peut pas accorder l’accès, révoquer l’accès, protéger un secret ou outrepasser les conditions d’une page de destination.

Idéal pour ces types d’entreprises

1. SaaS . La meilleure adéquation car une entreprise logicielle dispose généralement de sources distinctes pour le produit, les fonctionnalités, la tarification, l’intégration, l’API, la sécurité, le statut et la documentation. L’index peut déterminer quelle page possède chaque fait, tandis qu’un manifeste de capacités séparé peut décrire uniquement les actions que le produit prend réellement en charge.
2. E-commerce . Pertinent lorsque les produits, l’expédition, les retours, la disponibilité et les politiques de service client sont publics et canoniques. Conservez les données volatiles des articles dans des flux ou API ; utilisez l’index pour pointer vers ces sources maintenues plutôt que de copier un catalogue en Markdown.
3. Marketplaces . Utile lorsque les politiques des acheteurs, vendeurs, prestataires et de la plateforme diffèrent. Étiquetez chaque public et juridiction afin qu’un agent n’applique pas les règles des vendeurs à un acheteur ou ne déduise pas l’inventaire de la plateforme à partir d’une seule annonce.
4. Services B2B . Utile pour clarifier les capacités, les secteurs, les limites de service, les preuves, les documents d’approvisionnement et les voies de contact. Ne convertissez pas un périmètre négocié ou une promesse spécifique à un client en une déclaration universelle destinée aux machines.
5. Agences . Utile lorsque l’entreprise maintient de nombreuses pages de services, méthodologies, études de cas et expertises. Les portails clients, identifiants, rapports privés et manuels internes restent en dehors du fichier public.
6. Fabricants et entreprises industrielles . Utile pour diriger les systèmes vers les familles de produits, les spécifications, les certifications, les manuels, les distributeurs et les documents de sécurité. L’index ne doit jamais reformuler des instructions critiques pour la sécurité lorsque le document contrôlé fait autorité.

Les petits sites vitrines avec cinq pages stables peuvent tirer peu de bénéfice d’un artefact supplémentaire à maintenir. Les sites sans responsable de contenu clair devraient d’abord corriger la canonicalisation, la navigation et la qualité des sources avant de publier un fichier qui dérivera immédiatement.

Intention de recherche

L’intention de recherche est le résultat attendu d’une requête. Ce type a deux publics avec des intentions différentes. Une machine récupère un chemin racine prévisible et attend du Markdown concis, des titres stables, des liens canoniques et aucun bruit décoratif. Un chercheur humain veut généralement des conseils d’implémentation : « exemple llms.txt », « que mettre dans llms.txt » ou « format de manifeste d’agent ». La page explicative publique peut répondre à ces questions, tandis que le fichier /llms.txt déployé reste optimisé pour la récupération par machine.

Le fichier lui-même n’est pas une page d’atterrissage pour des mots-clés. N’ajoutez pas de définitions génériques, de termes de catégorie répétés ou des centaines de liens de blog pour le faire « classer ». Chaque ligne supplémentaire consomme de l’attention et crée une obligation de maintenance supplémentaire. Préférez dix liens délibérés avec des descriptions claires plutôt qu’un dump de dix mille URL.

Étant donné que les conventions et le support des consommateurs peuvent évoluer, indiquez sur quoi votre implémentation est basée et évitez de revendiquer une adoption universelle. Une récupération réussie prouve seulement que le fichier est accessible et analysable ; elle ne prouve pas qu’un produit d’IA particulier l’utilise pour le classement, la récupération, l’entraînement ou la citation.

Structure de la page

Les fourchettes de mots sont des contraintes d’édition, pas des objectifs. Le fichier déployé doit rester assez concis pour être audité ligne par ligne. La note d’implémentation destinée aux humains peut être plus longue, mais elle ne doit pas être copiée dans le fichier machine.

Un fichier organisé typique fait environ 200 à 700 mots. La longueur n’est pas un signal de qualité : la bonne taille est le plus petit index qui établit l’identité et achemine un consommateur vers des sources maintenues sans masquer les distinctions clés.

Éléments requis

L’index doit être ennuyeux au meilleur sens du terme : prévisible, explicite et facile à différencier. Placez les informations d’interprétation critiques avant les liens optionnels afin qu’une lecture partielle ne produise pas de conclusion erronée.

Frontmatter

Suivez la spécification du frontmatter . Sur cette spécification de type de publication, utilisez entity = "post-type-llms-txt-page" et schemaType = "Article". Sur une page d’implémentation destinée aux humains pour une organisation spécifique, utilisez une identité stable telle que acme-ai-access-index, et non une phrase de campagne ou une date.

Utilisez Article car la page web explique l’implémentation. Le balisage schema décrit le contenu visible ; il ne transforme pas le fichier texte brut en un protocole d’agent reconnu. Ne marquez pas la page comme SoftwareApplication, Dataset ou HowTo à moins que son contenu visible et son modèle ne satisfassent indépendamment aux exigences correspondantes.

Le fichier brut /llms.txt n’a normalement pas de frontmatter car le frontmatter ne doit pas fuir dans la sortie publiée. Stockez ses métadonnées opérationnelles dans le CMS, la configuration du générateur ou le registre du dépôt : domaine canonique, périmètre linguistique, propriétaire, collection source, mode de génération, date de dernière vérification, règle de prochaine révision, résultat du validateur et destination des alertes. Si des fichiers localisés existent, documentez la règle de sélection et conservez une réponse racine canonique sans ambiguïté.

Exemple complet

Ce fichier fictif illustre un index concis pour une plateforme SaaS. Ses URL, produit et capacités sont des exemples ; le modèle est la spécification.

# Northstar Analytics

> Northstar Analytics est une plateforme de reporting pour les équipes opérationnelles. Cet index pointe vers les pages publiques qui définissent le produit, les formules, la documentation, les politiques et les capacités d'agent prises en charge.

Les autorisations d'accès sont contrôlées par robots.txt, l'authentification et les politiques liées ci-dessous. Ce fichier n'accorde pas l'accès ni l'autorisation de réutiliser le contenu.

## Produit

- [Présentation du produit](https://www.northstar.example/product) : Périmètre actuel du produit et flux de reporting pris en charge.
- [Formules et tarifs](https://www.northstar.example/pricing) : Formules publiques actuelles, fonctionnalités incluses et conditions de facturation.
- [Intégrations](https://www.northstar.example/integrations) : Sources de données et systèmes de destination pris en charge.

## Documentation

- [Accueil documentation](https://docs.northstar.example/) : Documentation actuelle pour les utilisateurs et les administrateurs.
- [Référence API](https://docs.northstar.example/api/) : Points d'accès publics, schémas, authentification, erreurs et limites de débit.
- [Notes de version](https://docs.northstar.example/releases/) : Modifications datées du produit et du comportement de l'API.

## Confiance et support

- [Sécurité](https://www.northstar.example/security) : Programme de sécurité et documents d'assurance actuels.
- [Politique de confidentialité](https://www.northstar.example/privacy) : Traitement des données, conservation et droits des utilisateurs.
- [Support](https://www.northstar.example/support) : Voies de contact prises en charge et lien vers le statut du service.

## Capacité d'agent

- [Action d'exportation de rapport](https://docs.northstar.example/agents/export-report) : Contrat d'action authentifiée, entrées acceptées, format de sortie, limites de débit et gestion des erreurs. La disponibilité dépend du forfait et du rôle de l'utilisateur.

## Optionnel

- [Bibliothèque de recherche](https://www.northstar.example/research) : Rapports de référence originaux avec méthodes et dates de publication.

Vérifié le 27 août 2026 par l'équipe Documentation Operations. Généré à partir du registre canonique des ressources publiques ; valider après les changements de produit, forfait, politique, API ou URL.

L’exemple déclare une seule capacité car un contrat d’action réel documenté existe. Si le produit n’a aucune action d’agent prise en charge, omettez cette section. Ne déduisez jamais une capacité transactionnelle de la présence d’une barre de recherche, d’un formulaire ou d’un point d’accès non documenté.

Pour un manifeste d’agent stocké séparément de /llms.txt, respectez la même discipline. Spécifiez un format versionné, un identifiant canonique, un point d’accès de production, une méthode d’authentification, les opérations autorisées, le schéma d’entrée et de sortie, les limites de débit, les limites de consentement, les états d’erreur et les URL de politique. Validez-le par rapport au système en production. Une déclaration syntaxiquement valide qui fait la promotion d’une action désactivée est toujours incorrecte.

Galerie de design

Le fichier brut a peu de design visuel par intention. Les variantes de la galerie doivent tester l’architecture de l’information, l’ordre de lecture, la lisibilité mobile de la page d’implémentation humaine et les preuves opérationnelles — pas la décoration.

Liste de contrôle qualité

Ne publiez que lorsque chaque affirmation applicable est vraie :

• Le fichier est accessible à l’URL racine prévue sans authentification, boucles de redirection, murs de consentement ni interface applicative rendue.
• La réponse est un texte brut lisible ou du Markdown, utilise UTF-8 et ne dépend pas de JavaScript pour révéler son contenu.
• Le H1 donne le nom canonique de l’organisation ou du site, et la description énonce l’objectif, le public et le périmètre sans slogans.
• Chaque URL liée est canonique, publique, indexable par politique, accessible et appartient à l’organisation ou est clairement étiquetée comme externe.
• Les descriptions des liens indiquent quelle autorité détient la destination ; elles ne répètent pas un texte d’ancrage générique comme « en savoir plus ».
• Les sources principales du produit, de la tarification, de la documentation, des politiques et du support concordent avec l’index.
• Les pages d’archives, résultats de recherche, paramètres de suivi, versions régionales en double, pages de campagne et pages de balises de faible valeur sont exclus.
• Les affirmations de capacité correspondent à un contrat en production, pris en charge, authentifié et incluent les contraintes pertinentes.
• Aucun secret, jeton, point d’accès privé, donnée personnelle, document client, élément de feuille de route non publié ou détail d’implémentation sensible pour la sécurité n’apparaît.
• Le langage sur l’accès, les autorisations, les licences et les politiques renvoie aux sources de contrôle et n’est pas contredit par l’index.
• Le fichier ne revendique pas un classement garanti, une citation, une exclusion d’entraînement ou un support universel des consommateurs.
• Le périmètre linguistique et régional est explicite partout où la tarification, les politiques, la disponibilité ou la documentation diffèrent.
• Le propriétaire, le registre source, le processus de génération et la méthode de validation sont enregistrés à l’extérieur ou à la fin du fichier.
• Les vérifications de liens brisés, de redirections inattendues, de statut de réponse, de hachage de contenu et de sections requises sont exécutées après les déploiements pertinents.
• La date de vérification change uniquement après que les destinations, descriptions, capacités et politiques ont été substantiellement vérifiées.

Erreurs courantes

Traiter le fichier comme un sitemap. Un inventaire complet des URL détruit la priorisation et est difficile à réviser. Conservez les sitemaps XML pour la découverte ; organisez llms.txt autour des sources faisant autorité et des groupes pertinents.

Le traiter comme un contrôle d’accès. Une demande en Markdown n’est pas une couche d’application. Exprimez les règles d’exploration dans robots.txt, protégez les ressources privées par l’authentification et placez les exigences contraignantes dans la politique et les contrôles système correspondants.

Copier le contenu de destination dans l’index. Les tarifs, spécifications de produits et politiques répétés divergent. Résumez juste assez pour identifier l’autorité, puis créez un lien vers la source maintenue.

Publier des capacités spéculatives. Un formulaire ou une route API non documenté ne rend pas un site prêt pour les agents. Déclarez uniquement les actions prises en charge en production avec authentification, schémas, contraintes, erreurs et un responsable.

Tout inclure « au cas où ». Plus de liens créent plus d’ambiguïté et plus de points de défaillance. Le contenu optionnel doit mériter son inclusion en répondant à un besoin de récupération probable que les sections principales ne couvrent pas.

Exposer du contenu privé. Les fichiers publics lisibles par machine sont publics. Ne listez jamais d’hôtes de préproduction, d’API internes, d’identifiants, d’exportations clients, de documents non publiés ou de détails de sécurité qui n’ont pas été intentionnellement approuvés pour publication.

Générer sans gouvernance. L’automatisation peut reproduire des données sources de mauvaise qualité à grande vitesse. Un générateur a besoin d’un registre source approuvé, de règles d’exclusion, d’un ordre déterministe, d’une validation, d’une responsabilité de révision et d’alertes de déploiement.

Éditer manuellement un fichier généré. La génération suivante écrase la correction. Corrigez l’enregistrement source ou le générateur, régénérez et enregistrez le changement matériel.

Revendiquer des résultats non supportés. « Ceci garantit des citations IA » transforme une convention d’implémentation incertaine en une promesse trompeuse. Rapportez les preuves d’accessibilité et de récupération séparément des résultats de visibilité et de citation.

Mettre à jour la date sans vérifier la réalité. Un nouveau timestamp ne peut pas réparer une URL de documentation morte, un forfait renommé ou une action désactivée. La vérification signifie comparer chaque déclaration importante avec sa source de production.

Liens internes

Lie la page d’implémentation humaine vers le haut à types de publication SEO lorsqu’un auteur doit distinguer l’index machine d’un annuaire, d’une page de documentation ou d’une politique. Créez un lien depuis chaque affirmation opérationnelle vers sa source de contrôle : le périmètre du produit vers la page produit, les prix actuels vers la tarification, le comportement vers la documentation, les autorisations vers les contrôles d’accès et les obligations vers la politique.

Le fichier brut doit utiliser des URL absolues canoniques car il peut être récupéré en dehors de la navigation normale du site. Préférez une destination faisant autorité par fait. Si deux pages se chevauchent, résolvez la propriété avant de lister les deux ; l’index doit exposer la hiérarchie des sources, pas mémorialiser un désaccord interne.

Utilisez des noms de section courts et stables comme Produit, Documentation, Politiques et Capacités d'agent. Gardez les variantes linguistiques dans des groupes clairement étiquetés seulement lorsqu’elles diffèrent matériellement. Ne liez pas chaque article de blog ; sélectionnez des recherches ou guides durables uniquement lorsqu’ils aident un système à comprendre le sujet et les preuves du site.

Les liens entrants comptent aussi opérationnellement. La documentation, les portails développeurs et les guides d’accessibilité IA doivent diriger les mainteneurs vers l’enregistrement d’implémentation, tandis que l’enregistrement pointe vers le fichier en production et le validateur. Cela crée un chemin de révision pour les humains sans encombrer l’index machine.

Comment mesurer les résultats

Mesurez le fichier d’abord comme infrastructure, puis comme apport de visibilité. Une augmentation des citations ne peut pas être attribuée à llms.txt simplement parce que les deux sont survenus après la publication.

Suivez quatre couches :

• Disponibilité : statut de réponse de l’URL racine, comportement de redirection, type de contenu, encodage, latence, indépendance du rendu et disponibilité.
• Intégrité : succès d’analyse, sections requises, URL en double, liens brisés, cibles de redirection, décalage canonique, domaines non autorisés, secrets exposés et changements de hachage de contenu.
• Fraîcheur : jours depuis la vérification substantielle, changements de destination depuis la vérification, couverture du registre source, accusé de réception du propriétaire et délai de correction de la dérive.
• Résultats : récupérations dans les journaux serveur par des agents identifiables lorsque légalement et techniquement approprié, visites des destinations indexées, citations IA des pages canoniques préférées et exactitude des réponses pour les questions suivies de marque ou de produit.

Établissez une base de référence avant le déploiement : quelles URL sont citées, quels faits sont mal énoncés, si le fichier racine existe et quels robots le demandent. Annotez la publication et chaque mise à jour matérielle. Comparez des fenêtres d’observation suffisamment longues pour éviter de confondre une récupération ou une citation avec une tendance, et maintenez la distinction entre corrélation et causalité.

Testez les modes de défaillance directement. Renommez une copie de préproduction d’une URL listée et confirmez que le validateur détecte la rupture. Modifiez un mappage canonique et confirmez que le générateur met à jour l’index. Désactivez une capacité dans un environnement de test contrôlé et confirmez que la vérification du manifeste échoue. Ces tests prouvent le système de maintenance, pas l’adoption externe.

Utilisez comment nous mesurons les résultats pour séparer la disponibilité technique, la représentation machine, la découverte, la citation, l’engagement et les résultats commerciaux. Dans AmICited, examinez le fichier en production sous Accessibilité Agent et utilisez le rapport Cockpit pour observer les URL citées et la visibilité IA parallèlement aux annotations de déploiement. L’affirmation de succès crédible est « le fichier est valide, à jour et achemine les systèmes vers les sources prévues » ; tout changement de visibilité en aval nécessite des preuves séparées.

FAQ

Questions fréquemment posées