Commerce agentique
Comment rendre un magasin en ligne lisible par les agents de shopping IA ?
Mis à jour le
Rendre un magasin lisible par les agents implique quatre tâches : rendre les données produit côté serveur afin que le prix, la disponibilité et les identifiants existent dans le HTML brut plutôt qu'après le rendu côté client ; les baliser avec schema.org Product, y compris les offres, le prix, priceCurrency, la disponibilité et un GTIN ou SKU ; publier une couche de découverte — robots.txt autorisant les crawlers assistants, un sitemap et un llms.txt ; et exposer un point de terminaison programmatique pour les devis et le panier afin qu'un agent puisse obtenir un prix ferme sans utiliser de navigateur. Le premier point résout la majeure partie de l'écart à lui seul.
Commencez par mesurer votre propre écart
Avant de changer quoi que ce soit, effectuez le test qui prédit la majeure partie du problème. Récupérez une page produit comme le ferait un crawler — sans exécution JavaScript — et regardez ce qui subsiste.
Vous vérifiez quatre éléments dans la réponse brute : le prix, l'état de disponibilité, l'identité de la variante et un identifiant produit stable. Si l'un de ces éléments n'apparaît qu'après le rendu côté client, alors un agent évaluant votre produit devine ou vous ignore. Adobe a constaté que les pages produits obtenaient un score de 66 % en lisibilité machine, le plus bas de tous les types de pages, et c'est la raison principale.
Effectuez le même test sur vos pages de collection et vos résultats de recherche. Les pages de catégorie qui sont entièrement rendues côté client sont invisibles en tant que surfaces de découverte, même lorsque les produits individuels sont corrects.
Les quatre couches, par ordre de rentabilité
Chaque couche ci-dessous est utile indépendamment. Rien n'est perdu si un protocole particulier ne parvient pas à s'imposer, ce qui est la propriété que vous souhaitez étant donné que beaucoup de choses sont encore en mouvement.
| Couche | Ce qu'il faut mettre en œuvre | Pourquoi cela rapporte en premier |
|---|---|---|
| Données produit rendues côté serveur | Prix, disponibilité, variante, SKU/GTIN présents dans la réponse HTML initiale | Comble le plus grand écart mesuré et améliore le SEO classique simultanément — la même correction sert les deux audiences |
| Balises schema.org Product | Produit avec offres, prix, priceCurrency, disponibilité, sku/gtin, aggregateRating uniquement si réels | Transforme le texte analysé en faits avérés ; également l'entrée pour les résultats enrichis Google Merchant |
| Couche de découverte | robots.txt autorisant les crawlers assistants, sitemap.xml, llms.txt indiquant ce que vous vendez | Peu coûteux, en une seule fois, et détermine si l'un des éléments ci-dessus est un jour récupéré |
| Devis et panier programmatiques | Une API renvoyant un total ferme incluant les frais de port et les taxes, plus la construction du panier | Requis par UCP et ACP pour l'étape de transaction ; supprime entièrement la simulation de navigateur |
La décision concernant robots.txt que les gens prennent mal
Bloquer en masse les crawlers IA est une position défendable pour un éditeur dont le produit est le texte. C'est presque indéfendable pour un commerçant dont le produit est un produit : vous refusez d'apparaître dans le canal de référence à la croissance la plus rapide dans le commerce de détail afin de protéger le texte que vous avez écrit pour vendre ce produit.
Soyez délibéré plutôt que par défaut. Décidez séparément des crawlers qui construisent des corpus d'entraînement et des agents qui récupèrent une page pour répondre à une question de shopping en direct — ce sont des enjeux différents, et la plupart des détaillants veulent admettre le second sans condition.
L'autre erreur courante est l'utilisation de règles de désautorisation trop larges. Si vos surfaces authentifiées se trouvent sur des chemins de niveau racine qui sont des préfixes de pages marketing, une simple désautorisation désindexe silencieusement la page marketing également. Ancrez chaque règle.
llms.txt est peu coûteux et l'objection à son égard est faible
Nous avions l'habitude de présenter cela comme un pari peu coûteux que personne n'avait tenté. Nos propres mesures disent le contraire : sur 147 marques DTC bien connues, la plupart de celles qui sont accessibles publient déjà un llms.txt — et la grande majorité ne l'a pas écrit, car leur plateforme en fournit un modèle. Google a déclaré qu'aucun système d'IA n'utilise le fichier ; la question de savoir si les commerçants le publient n'est plus d'actualité.
La décision n'est donc pas de savoir s'il faut en avoir un. C'est de savoir si le modèle généré par défaut a de la valeur. Un modèle de 4.3KB décrit un magasin générique — il ne sait pas quels de vos produits sont importants ni ce qui vous distingue de toutes les autres marques publiant le même document. Les marques qui ont écrit le leur varient de 566 octets à 28KB.
La règle dans tous les cas : générez-le à partir de votre registre de routes plutôt que de l'écrire à la main, afin qu'il ne se périme pas. Un index obsolète est pire que pas d'index du tout, car il pointe avec confiance vers des pages qui ont été déplacées.
Ce que vous obtenez sans rien construire sur PlatformDTC
Sur PlatformDTC, ce sont des propriétés de la plateforme plutôt qu'un projet. Les vitrines rendent les données produit côté serveur avec un balisage structuré comme sortie par défaut du pipeline de publication. La couche de découverte — robots, sitemap, llms.txt — est générée à partir de l'arbre de routes réel au moment de la construction, donc une page qui est livrée est une page qui est découvrable.
La couche programmatique est l'Agent Gateway : opérations de catalogue, panier, devis et commande exposées sous forme d'appels API ciblés et d'outils MCP, avec des clés d'idempotence, une piste d'audit et une porte d'approbation humaine pour tout ce qui implique des dépenses.
Questions fréquentes
- La préparation pour les agents est-elle en conflit avec l'optimisation du taux de conversion ?
- Rarement, car ils opèrent sur des couches différentes. Le rendu côté serveur du prix et de la disponibilité modifie ce qui se trouve dans la réponse HTML, pas ce qu'un humain voit. La véritable tension réside dans les tactiques qui n'existent que pour créer un sentiment d'urgence — un agent lit le vrai numéro d'inventaire, donc un faux est à la fois inefficace et un risque pour la crédibilité.
- Le balisage schema.org Product est-il suffisant à lui seul ?
- Seulement si les valeurs qu'il contient sont réelles et actuelles. Un balisage qui affirme un prix que la page ne facture plus, ou un stock disponible pour une variante épuisée, est pire que rien — il produit des réponses erronées avec assurance et, pour les résultats enrichis Google Merchant, risque une pénalité de données structurées. Générez-le à partir de la même source que celle à partir de laquelle la vitrine est rendue.
- Combien de temps cela prend-il sur un magasin existant ?
- La couche de découverte prend des heures. Le balisage Schema prend des jours si vos données de catalogue sont propres. Le rendu côté serveur des données produit est le véritable projet et dépend entièrement de l'architecture de votre vitrine — un thème rendu côté client construit sur une API JSON est une refonte du chemin de rendu, pas un correctif.
- Quels crawlers assistants devrais-je autoriser ?
- Distinguez les deux objectifs. Les agents qui récupèrent des pages pour répondre à des questions de shopping en direct — ceux qui produisent le trafic de référence mesuré par Adobe — sont ceux à autoriser. Les crawlers de corpus d'entraînement en masse sont une décision commerciale distincte. Nommez-les individuellement dans robots.txt plutôt que de vous fier à une règle générale.