llms.txt est un fichier Markdown placé à la racine d'un site (tauboutique.com/llms.txt) qui donne aux modèles d'AI une carte courte et sélectionnée du site : un titre avec le nom du site, un résumé d'un paragraphe et des listes de liens vers les pages importantes, chacune avec une courte note. Il a été proposé en septembre 2024 pour aider les modèles de langage et les agents AI à trouver les parties utiles d'un site sans devoir traverser la navigation, les scripts et les bannières de cookies.
Pour une boutique en ligne, la réponse courte est la suivante : un fichier llms.txt se rédige en un après-midi, il n'améliore pas ton classement dans la recherche Google (Google indique que la recherche l'ignore), et aucun grand assistant d'achat AI n'a documenté le lire. Il peut quand même aider les agents qui le cherchent, et beaucoup de boutiques en servent déjà un qu'elles n'ont jamais écrit. Ce qui décide si un assistant AI recommande tes produits, ce sont les données produit vers lesquelles pointent les liens. Au programme : ce qu'est le fichier, ce qu'il n'est pas, qui l'utilise, et un modèle conçu pour un catalogue plutôt que pour un site de documentation.
D'où vient llms.txt : la proposition de Jeremy Howard en 2024
Jeremy Howard, d'Answer.AI, a publié la proposition sur llmstxt.org le 3 septembre 2024. Le raisonnement était pratique : un modèle de langage a une capacité de lecture limitée, et une page HTML en consomme une grande partie avec les menus, les pieds de page, les scripts et le code de tracking. Un petit fichier Markdown écrit pour les machines pourrait diriger un modèle directement vers le contenu qui vaut la peine d'être lu, dans un format facile à analyser.
Les premiers à l'adopter ont été des éditeurs de logiciels avec une grosse documentation développeur, où un assistant de code profite d'un index propre des pages d'API. Cette origine explique pourquoi la plupart des exemples en ligne listent des références d'API et des guides de SDK. Une boutique a un autre contenu : catégories, produits, conditions et guides d'achat. Le format fonctionne pour les deux, mais le contenu doit être repensé.
llms.txt est une proposition, pas une norme ratifiée par un organisme de normalisation, et rien n'oblige une entreprise d'AI à le lire. Garde ça en tête quand un éditeur d'outils le présente comme indispensable.
Le format llms.txt, élément par élément
La proposition définit un ordre fixe. Seul le premier élément est obligatoire :
- Un H1 avec le nom du site ou du projet. Pour une boutique : le nom de la boutique.
- Une citation (blockquote) avec un court résumé de ce qu'est le site et du contexte clé dont un modèle a besoin pour comprendre le reste.
- Des paragraphes ou des listes facultatifs sans titre avec plus de détails, par exemple les pays vers lesquels tu livres ou ton délai de retour.
- Zéro ou plusieurs sections H2, chacune une liste de liens. Chaque élément est un lien Markdown, éventuellement suivi de deux-points et d'une note : ce qu'il y a sur cette page et pourquoi c'est important.
- Une section H2 nommée Optional pour les liens secondaires qu'un agent peut ignorer quand il manque de contexte.
La proposition demande aussi aux sites de proposer des versions Markdown propres de leurs pages à la même URL avec .md ajouté (/road-bikes devient /road-bikes.md, ou index.html.md pour une URL sans nom de fichier). La deuxième version de la proposition ajoute des indices de découverte : un élément link HTML ou un en-tête HTTP Link avec rel="describedby" pointant vers le fichier llms.txt, et rel="alternate" type="text/markdown" pointant vers la copie Markdown d'une page.
Tu verras aussi llms-full.txt. Il ne fait pas partie de la proposition. C'est une convention venue des plateformes de documentation : un seul fichier avec le texte complet du site au lieu de liens. Pour une boutique avec des milliers de produits, un fichier en texte intégral devient vite trop volumineux pour être utile, c'est pourquoi le modèle plus bas pointe plutôt vers les pages catégories et un flux.
WISEPIM publie son propre fichier sur wisepim.com/llms.txt, et il suit cette structure : un H1, un résumé d'un paragraphe dans une citation sur ce que fait le produit et pour qui, un lien vers la documentation complète sous forme de llms-full.txt, puis des sections de liens vers la documentation avec une note d'une ligne pour chacun. C'est le fichier d'un éditeur de logiciel. Le fichier d'une boutique met d'autres choses dans les mêmes emplacements.
Ce que llms.txt ne fait pas : classement, contrôle du crawl et citations AI
La plupart des confusions autour de llms.txt viennent du fait qu'on s'attend à ce qu'il se comporte comme robots.txt ou comme un signal de classement. Il n'est ni l'un ni l'autre.
- Ce n'est pas un facteur de classement Google. Le guide de Google pour optimiser pour les fonctionnalités d'AI générative dans la recherche range llms.txt parmi les choses que tu peux ignorer. Il indique que tu peux créer ces fichiers pour d'autres services, mais qu'ils ne vont « ni nuire ni aider » à la visibilité dans la recherche, « car la recherche Google les ignore ». Le même guide te conseille de continuer à utiliser les données structurées et les flux Merchant Center.
- Il ne contrôle pas le crawl. llms.txt invite ; il n'autorise ni ne bloque. Pour empêcher un crawler AI de récupérer tes pages, tu utilises toujours des règles robots.txt pour son user agent.
- Ce n'est la preuve de rien. En avril 2025, John Mueller de Google l'a comparé à la balise meta keywords : une affirmation du propriétaire sur son site, qu'un moteur de recherche peut vérifier en regardant le site lui-même. Il a ajouté qu'à sa connaissance, aucun des services d'AI n'avait dit l'utiliser (Search Engine Journal).
- Ce n'est pas un sitemap. Un sitemap liste toutes les URL pour la découverte. llms.txt est une sélection avec du contexte : moins de liens, chacun expliqué.
Google est le seul grand moteur de recherche à avoir dit par écrit ce qu'il fait du fichier. Nous n'avons trouvé aucune déclaration publique d'OpenAI, Perplexity, Microsoft ou Anthropic indiquant que leurs réponses shopping lisent le llms.txt d'une boutique. Méfie-toi de toute promesse de trafic AI supplémentaire grâce au seul fichier.
Qui publie un llms.txt : d'abord la documentation développeur, maintenant chaque boutique Shopify
L'adoption est plus large que l'absence d'effet sur le classement ne le laisse penser, surtout parce que les plateformes génèrent désormais le fichier pour toi :
Qui publie ou vérifie des fichiers llms.txt
| Sites de documentation développeur | Documentation de Stripe et d'Anthropic | Premiers à l'adopter ; leurs fichiers listent les pages d'API et les guides |
|---|---|---|
| WordPress et créateurs de sites | Yoast SEO, AIOSEO, Wix | Cités dans la liste d'outils de llmstxt.org comme générant le fichier automatiquement |
| Apps Shopify | L'app Shopify de Yoast, mars 2026 | Sa fonctionnalité llms.txt liste par défaut tes 10 produits les plus vendus, jusqu'à 5 de tes plus grandes collections, tes politiques de livraison, de retour et de confidentialité ainsi que tes pages récentes, et reconstruit le fichier chaque semaine |
| Shopify lui-même | Chaque boutique Shopify, depuis le 28 mai 2026 | D'après une entrée du changelog Shopify, un /agents.md par défaut est servi, et /llms.txt et /llms-full.txt servent le même contenu, sauf si le thème les remplace par ses propres templates Liquid (llms.txt.liquid, llms-full.txt.liquid ou agents.md.liquid) |
| Outils d'audit | Chrome Lighthouse | Son audit llms.txt dans la catégorie navigation agentique signale une erreur serveur lors de la récupération du fichier et marque un fichier absent comme non applicable, « car fournir le fichier est facultatif pour le moment ». |
La conséquence pratique : si tu es sur Shopify, tu sers probablement déjà un llms.txt écrit par Shopify. Ouvre tauboutique.com/llms.txt avant d'écrire quoi que ce soit, et décide si le contenu par défaut dit ce que tu veux qu'un agent sache.
Un modèle de llms.txt pour une boutique en ligne
Les fichiers de type documentation listent chaque page. Le fichier d'une boutique doit faire l'inverse : décrire le catalogue en quelques lignes et pointer vers les pages et les sources de données qui contiennent le détail. Cette structure fonctionne pour la plupart des boutiques B2C et B2B :
- H1 : le nom de la boutique tel que les acheteurs le connaissent.
- Citation : ce que tu vends, à qui, dans quels pays et quelles devises, en deux ou trois phrases.
- Infos clés (sans titre) : frais de livraison et seuil de livraison gratuite par pays, délais de livraison, délai de retour et qui paie le retour, conditions de garantie, moyens de paiement, prix TTC ou non, et conditions B2B si tu vends aux entreprises.
- ## Categories : une ligne par catégorie principale avec un lien et une note qui contient de vrais faits : nombre de produits, marques principales, plages de tailles ou de caractéristiques. Douze lignes valent mieux que mille deux cents.
- ## Buying guides and size charts : guides de taille, tableaux de compatibilité, comment choisir une taille ou un modèle. C'est le contenu que les agents utilisent pour répondre à « lequel dois-je acheter ».
- ## Policies : livraison, retours, garantie, confidentialité et CGV, chacun avec un résumé d'une ligne.
- ## Product data : ton sitemap produits et, si tu en publies un, un flux produits public. Indique le format et la fréquence de mise à jour.
- ## Optional : à propos, magasins physiques, blog, recrutement, presse.
Exemple concret : une boutique néerlandaise de pièces vélo
Voici cette structure remplie pour une boutique fictive, Velowinkel, qui vend des pièces et accessoires vélo aux Pays-Bas et en Belgique. Chaque élément ci-dessous correspond à une ligne ou un bloc du fichier :
- H1 : Velowinkel
- Citation : Velowinkel vend des pièces, des pneus et des accessoires pour vélos de route, gravel et ville aux acheteurs des Pays-Bas et de Belgique. Les prix sont en EUR et incluent 21 % de TVA néerlandaise. Environ 6 800 produits de 140 marques.
- Infos clés : livraison gratuite aux Pays-Bas dès 50 EUR, 4,95 EUR en dessous ; Belgique 6,95 EUR. Commande passée un jour ouvré avant 22h00, livrée le jour ouvré suivant aux Pays-Bas. Retours sous 30 jours, étiquette de retour gratuite pour les articles non utilisés. Paiement par iDEAL, Bancontact, carte et PayPal.
- ## Categories : Pneus (/tires) : 1 240 pneus et chambres à air, tailles ETRTO de 23-622 à 57-622, tubeless et pneus à tringle, valves Presta et Schrader. Transmission (/drivetrain) : chaînes, cassettes et plateaux, 9 à 12 vitesses, compatibles Shimano, SRAM et Campagnolo. Éclairage (/lights) : 310 éclairages avant et arrière, modèles homologués StVZO signalés. Une ligne par catégorie, huit au total.
- ## Buying guides : Guide des largeurs de pneu (/guides/tire-width) : quelles largeurs de pneu vont sur quelles largeurs de jante, avec un tableau de compatibilité. Compatibilité des chaînes (/guides/chain-compatibility) : quelle chaîne va avec quelle cassette selon le nombre de vitesses et la marque.
- ## Policies : Livraison (/shipping), Retours (/returns) : 30 jours, étiquette gratuite, câbles coupés sur mesure exclus. Garantie (/warranty) : deux ans selon le droit européen de la consommation, garantie fabricant sur les cadres et les roues.
- ## Product data : Sitemap produits (/sitemap_products_1.xml). Flux produits (/feeds/products-nl.xml) : format XML Google Shopping, tous les produits en stock, mis à jour chaque jour à 02h00.
- ## Optional : À propos de Velowinkel (/about), Atelier à Utrecht (/workshop), Blog (/blog).
Dans le vrai fichier, chacune de ces parenthèses est un lien Markdown complet. Remarque ce qui porte le poids : les notes. « Pneus : 1 240 pneus et chambres à air, tailles ETRTO de 23-622 à 57-622 » indique à un agent si cette boutique peut répondre à une question sur un pneu route de 28 mm avant même de récupérer une seule page. « Pneus : notre gamme de pneus » ne lui dit rien.
Flux produits, pages produit en Markdown et grands catalogues
Une boutique de 50 produits peut lier chacun d'eux. Une boutique de 20 000 ne le peut pas, et ne devrait pas essayer : le fichier serait plus long que le contexte qu'un agent veut y consacrer. Trois meilleures options pour les grands catalogues :
- Lier un flux produits public. Si tu génères déjà un flux pour Google Shopping ou un comparateur de prix, il contient les titres, prix, disponibilités, GTIN et attributs dans un format structuré. Le rendre public est un choix business : tes concurrents peuvent le lire aussi. Le guide de gestion des flux produits explique comment en structurer un.
- Proposer des versions Markdown des pages catégories et produits. Génère-les à partir de tes champs produit plutôt qu'en convertissant le HTML : titre, marque, GTIN, prix et disponibilité, puis les attributs sous forme de liste simple (largeur du pneu : 28 mm, ETRTO : 28-622, tringle : souple, poids : 215 g), la compatibilité, le contenu de la boîte et la politique de retour. Un produit sans ces champs produit une page Markdown vide.
- Réserver llms-full.txt aux conditions et aux guides, pas au catalogue. Pour des milliers de SKU, le texte produit complet est mieux servi par le flux et par les pages produit elles-mêmes.
Quelle que soit l'option choisie, le fichier ne fait que décrire des données qui existent ailleurs. Notre article sur le SEO technique pour l'e-commerce couvre le volet crawlabilité : URL canoniques, sitemaps et codes de statut s'appliquent toujours aux pages vers lesquelles llms.txt pointe.
Pourquoi les attributs derrière chaque lien décident des recommandations AI
L'objection de Mueller pointe le vrai problème. Un assistant AI à qui l'on demande un feu arrière étanche avec recharge USB-C et homologation StVZO ne se fie pas à un fichier de résumé ; il lit les pages produit, les données structurées et les flux marchands, et il compare des faits. Si « étanche » est noyé dans un paragraphe marketing et que l'indice IP manque, le produit perd cette comparaison, aussi bien que le llms.txt décrive la catégorie.
Pour une boutique, le bon ordre de travail est donc l'inverse du buzz :
- Remplis les attributs sur lesquels les acheteurs filtrent et posent des questions : dimensions avec unités, matières, compatibilité, certifications, caractéristiques d'alimentation et de batterie, plages de tailles. Lis comment les modèles de langage utilisent les données produit pour comprendre pourquoi des champs typés valent mieux que de la prose.
- Expose-les dans les données structurées de la page produit. Le guide schema.org pour les taxonomies produit montre quelles propriétés comptent, et le générateur de schema produit gratuit crée un bloc JSON-LD Product à comparer avec le tien.
- Envoie-les dans tes flux, y compris les flux que les assistants AI ingèrent directement. Le guide du flux ChatGPT Shopping liste les champs demandés par OpenAI.
- Ensuite, rédige llms.txt comme la carte de tout ce qui précède.
Sept vérifications avant de mettre en ligne le llms.txt de ta boutique
Sept vérifications avant le lancement du llms.txt d'une boutique
Une fois le fichier en ligne, consulte tes logs serveur pour les requêtes vers /llms.txt et les pages .md. Tu sauras quels agents le récupèrent, ce qui est plus fiable que n'importe quelle affirmation sur ceux qui devraient le faire.
WISEPIM travaille sur la couche située sous le fichier : il complète les attributs, descriptions et traductions manquants avec l'AI, vérifie chaque produit selon les règles des canaux dans Quality Guard et génère des flux via Feed Hub, pour que les pages et flux vers lesquels pointe ton llms.txt contiennent les faits qu'un assistant compare. La page de la fonctionnalité agentic commerce montre à quoi ça ressemble sur un catalogue.
