Google ignore llms.txt. Shopify le publie quand même.

Google Search affirme ne pas utiliser llms.txt pour les AI Overviews, AI Mode, les classements ou la visibilité dans ses résultats. Shopify indique pourtant que chaque boutique sert automatiquement llms.txt et llms-full.txt comme URL de compatibilité pour les anciens robots IA qui recherchent ces conventions.

Ces deux faits ne se contredisent pas. Ils concernent des consommateurs et des couches techniques différents. Google explique ce que Google Search utilise. Shopify publie des fichiers de compatibilité tout en précisant que Shopify Catalog reste la source de référence pour les produits des canaux agentiques activés.

La conclusion pratique est limitée : publier ou maintenir llms.txt peut être pertinent pour une audience documentée, mais le fichier ne doit pas être présenté comme une technique de classement Google, ni comme un remplacement des données produit, des pages explorables, des protocoles de commerce ou des outils de checkout.

La position de Google est explicite

Le guide Google AI features and your website indique que les fondations habituelles de Search restent pertinentes pour les fonctionnalités d’IA. Google recommande un contenu accessible, utile, techniquement solide et appuyé par les surfaces produit ou établissement appropriées.

Le même guide indique que Google Search n’utilise ni llms.txt, ni balisage spécial destiné à ses fonctions d’IA. Google précise également que ces ajouts n’aident ni ne pénalisent le classement ou la visibilité dans ses expériences d’IA.

Cette formulation exclut plusieurs promesses fréquentes :

• llms.txt n’est pas requis pour Google AI Overviews ;
• llms.txt n’est pas requis pour Google AI Mode ;
• le fichier n’est pas un facteur de classement Google documenté ;
• son absence n’est pas une pénalité Google documentée ;
• une requête d’un user-agent ne prouve pas que Google Search utilise le fichier.

La déclaration porte sur Google Search. Elle ne doit pas être transformée en « aucun agent n’utilise llms.txt » sans preuve plus large.

Ce que Shopify publie

La documentation Shopify Products in agentic storefronts distingue plusieurs surfaces.

Shopify présente /agents.md comme le fichier canonique de guidage agentique d’une vitrine. La plateforme sert aussi /llms.txt et /llms-full.txt comme URL de compatibilité. Par défaut, ces fichiers reprennent les mêmes indications de vitrine que /agents.md.

Shopify précise en parallèle que Shopify Catalog est la source de référence des données produit pour les canaux de vitrines agentiques activés. Les fichiers de découverte sont séparés de Catalog et ne le remplacent pas.

La contradiction apparente disparaît ainsi. Shopify peut publier llms.txt pour des consommateurs qui connaissent cette convention sans prétendre que le fichier pilote Google Search.

Cinq couches à ne pas confondre

Couche	Fonction principale	Exemple	Ce qu’elle ne prouve pas
Découverte par un moteur	Explorer, indexer, classer et présenter des résultats	Google Search	Qu’un agent lit llms.txt
Guidage d’un agent	Donner une carte concise ou des indications lisibles	agents.md, llms.txt	Que les données produit sont complètes ou transactionnelles
Distribution des produits	Fournir produits, prix, disponibilité et politiques aux canaux activés	Shopify Catalog	Qu’un agent navigateur peut modifier le checkout
Protocoles et outils de commerce	Exposer des opérations structurées de panier ou de checkout	UCP, MCP, WebMCP	Qu’un moteur classera mieux le site
Confirmation et paiement	Recueillir l’accord, gérer les challenges et confirmer la commande	Checkout Shopify, Shop Pay, 3-D Secure	Qu’un fichier de découverte a autorisé un achat

Plusieurs couches peuvent fonctionner ensemble. Leur coexistence est normale. L’erreur consiste à utiliser une preuve issue d’une couche pour revendiquer le succès d’une autre.

Une réponse HTTP 200 sur /llms.txt prouve par exemple que le fichier a été servi. Elle ne prouve pas qu’un agent l’a lu, a suivi ses liens, trouvé un produit, créé un panier, terminé une commande ou généré du chiffre d’affaires.

Pourquoi Shopify conserve des URL de compatibilité

La proposition llmstxt.org v2, modifiée pour la dernière fois le 10 août 2026, définit un fichier Markdown en texte brut destiné à aider des agents à utiliser un site. Le projet présente ce format comme une proposition et documente la syntaxe et le mécanisme de découverte suggérés.

Servir une URL de compatibilité peut être raisonnable si des logiciels, des développeurs ou des agents expérimentaux recherchent déjà cet emplacement. Une plateforme peut réduire les frictions en faisant converger plusieurs conventions de découverte vers la même information.

La compatibilité ne prouve toutefois pas une consommation universelle. La formulation défendable est simplement que le fichier est disponible pour les consommateurs qui choisissent de le demander.

Cette distinction existe ailleurs sur le Web. Un site peut publier un flux RSS sans affirmer que chaque lecteur utilise un agrégateur. Il peut proposer une API sans prétendre que chaque visiteur l’appelle. Disponibilité et usage sont deux mesures différentes.

Un fichier de découverte n’est pas un flux produit

Un bon fichier de découverte est court, stable et sélectif. Un catalogue produit est volumineux, dynamique et opérationnel. Les fusionner crée des problèmes de maintenance et de confiance.

D’après Shopify, Catalog constitue la couche de référence des données produit pour les canaux agentiques activés. C’est à ce niveau que la synchronisation de produits gérée par la plateforme importe. Un fichier de découverte peut orienter vers des politiques, collections, documentations, supports ou interfaces structurées, mais il ne doit pas devenir une deuxième base d’inventaire maintenue à la main.

Dupliquer des faits commerciaux dans llms.txt crée plusieurs risques :

• prix périmés ;
• disponibilité différente du catalogue actif ;
• variantes absentes ou simplifiées ;
• restrictions régionales perdues ;
• conditions promotionnelles conservées après la fin de l’offre ;
• sources contradictoires sans règle d’autorité.

Si le fichier contient des données commerciales dynamiques, son propriétaire doit définir une source de vérité automatisée et un contrat de mise à jour. Sinon, mieux vaut lier les ressources de référence que les recopier.

La distinction avec robots.txt

Shopify explique aussi que le blocage ou l’autorisation des robots du Web ouvert agit sur l’accès de ces robots, tandis que des produits peuvent toujours être fournis à des canaux agentiques activés par Shopify Catalog.

Cela ne rend pas robots.txt inutile. Cela signifie que l’accès d’un crawler et l’activation d’un canal sont deux contrôles différents.

robots.txt communique des préférences d’exploration aux robots qui le respectent. llms.txt est une proposition de guidage. Shopify Catalog est une surface de données produit gérée par la plateforme. Aucun de ces éléments ne remplace universellement les autres.

Les équipes doivent documenter quel contrôle régit quel consommateur, plutôt que d’imaginer un seul interrupteur de « visibilité IA ».

Quand publier llms.txt est raisonnable

La publication peut être pertinente lorsque les conditions suivantes sont réunies :

1. une audience nommée ou testable existe ;
2. le contenu renvoie vers des ressources maintenues et de référence ;
3. aucune promesse de classement Google ou d’usage universel n’est faite ;
4. le responsable et le déclencheur de mise à jour sont définis ;
5. la revue de sécurité traite le contenu comme une entrée potentiellement hostile pour les agents ;
6. l’effet est mesuré séparément du trafic organique et des ventes.

Sur Shopify, la plateforme peut déjà générer les fichiers de compatibilité. Avant d’ajouter une automatisation, il faut lire les réponses live et vérifier si le contenu généré répond au besoin réel.

Quand ce n’est pas la priorité

llms.txt devient secondaire lorsque des preuves plus fondamentales manquent, par exemple :

• pages importantes non explorables ou signaux canoniques incohérents ;
• titres, descriptions, disponibilités ou politiques produit erronés ;
• Merchant Center ou canal de commerce pertinent incomplet ;
• données structurées contredisant le contenu visible ;
• informations de livraison, retour ou support imprécises ;
• flux de panier et checkout agentiques non testés ;
• absence de surveillance des liens périmés ou des affirmations contradictoires.

La documentation Google appuie cette priorité : la qualité technique et éditoriale habituelle reste la base de ses expériences de recherche avec IA.

La méthodologie, le validateur, les exemples et le guide de création traitent ces contrôles séparément, sans les présenter comme une preuve d’usage par Google.

Mesurer sans confondre présence et usage

Un modèle de preuve par étapes limite les conclusions abusives.

1. Présence

Vérifier que /llms.txt renvoie le statut, le type de média, l’encodage et le contenu attendus. Conserver la date d’observation et l’empreinte du contenu.

2. Validité

Contrôler la syntaxe, les liens, la langue, les ressources canoniques, les duplications et la fraîcheur. Un fichier valide peut rester inutilisé.

3. Récupération

Utiliser des journaux serveur ou une autre source autorisée pour identifier les requêtes. Classer avec prudence les user-agents connus, inconnus ou usurpables. Une chaîne de user-agent seule constitue une preuve d’identité faible.

4. Suivi des liens

Chercher une séquence défendable entre une requête du fichier et les ressources liées. Adresses IP partagées, caches et systèmes de confidentialité peuvent rendre l’attribution impossible.

5. Action métier

Mesurer séparément vues produit, appels d’outils, créations de panier, mises à jour de checkout et commandes confirmées. Ne pas les déduire d’une requête du fichier.

6. Impact incrémental

Pour savoir si le fichier a causé une amélioration, utiliser une comparaison contrôlée ou un autre protocole causal explicite. Un graphique avant-après peut refléter une release, la saisonnalité, l’activation d’un canal, des changements de contenu ou une dérive de mesure.

À chaque étape, conserver « non mesurable » lorsque les données ne permettent pas de conclure.

Checklist de maintenance

• Identifier les consommateurs visés et documenter leur existence.
• Garder un fichier concis qui renvoie vers des ressources canoniques maintenues.
• Ne pas recopier prix, stock ou politiques dynamiques sans automatisation fiable.
• Indiquer clairement la langue et le périmètre.
• Contrôler chaque lien et redirection.
• Supprimer toute affirmation selon laquelle Google Search utilise le fichier.
• Surveiller les changements de documentation Google, Shopify et llmstxt.org.
• Enregistrer les empreintes de contenu et dates d’observation.
• Traiter tout texte consommé par un agent comme un vecteur potentiel d’injection de prompt.
• Mesurer séparément récupération, actions en aval et résultats métier.

Ce qui peut être affirmé aujourd’hui

Au 29 septembre 2026, les affirmations suivantes sont étayées par les sources primaires citées :

• Google Search affirme ne pas utiliser llms.txt pour ses fonctionnalités d’IA ;
• Google indique que le fichier n’aide ni ne pénalise ses classements ou sa visibilité ;
• Shopify présente /agents.md comme le fichier canonique de guidage d’une vitrine et expose /llms.txt et /llms-full.txt par compatibilité ;
• Shopify Catalog, et non ces fichiers de découverte, est la source de référence des données produit pour les canaux agentiques activés ;
• llmstxt.org décrit une proposition communautaire de fichier Markdown.

Les sources ne prouvent ni adoption universelle par les agents, ni avantage de classement, ni effet sur la conversion.

Conclusion

« Google n’utilise pas llms.txt » et « Shopify publie llms.txt » répondent à deux questions différentes.

Google définit les entrées de Google Search. Shopify prend en charge des conventions de découverte de vitrine tout en faisant passer les données produit de référence par Catalog. La proposition llmstxt.org offre un format léger que certains consommateurs peuvent choisir d’utiliser.

La bonne décision dépend donc du consommateur visé. Publiez le fichier pour une audience documentée, gardez-le factuel et maintenable, puis mesurez-le comme une surface de découverte. Ne le présentez ni comme un raccourci vers la visibilité Google, ni comme un substitut aux données commerciales et aux outils transactionnels.