Hoe maak je een e-commercewinkel leesbaar voor AI-winkelagenten?

Begin met het meten van je eigen kloof

Voordat je iets verandert, voer je de test uit die het grootste deel van het probleem voorspelt. Haal een productpagina op zoals een crawler dat doet — zonder JavaScript-uitvoering — en kijk wat er overblijft.

Je controleert op vier dingen in de ruwe respons: de prijs, de beschikbaarheidsstatus, de variantidentiteit en een stabiele productidentificatie. Als een van deze pas na client-side rendering verschijnt, dan raadt een agent die je product evalueert of slaat hij je over. Adobe ontdekte dat productpagina's 66% scoorden op machinale leesbaarheid, het laagste van elk paginatype, en dit is de overweldigende reden.

Voer dezelfde test uit op je collectiepagina's en je zoekresultaten. Categoriepagina's die volledig client-side renderen, zijn onzichtbaar als ontdekkingsvlakken, zelfs als de individuele producten in orde zijn.

De vier lagen, in volgorde van terugverdientijd

Elke onderstaande laag is onafhankelijk nuttig. Niets ervan is verspild als een bepaald protocol niet wint, wat de eigenschap is die je wilt gezien hoeveel er nog in beweging is.

De robots.txt-beslissing die mensen verkeerd nemen

AI-crawlers massaal blokkeren is een verdedigbare positie voor een uitgever wiens product de tekst is. Het is bijna onverdedigbaar voor een handelaar wiens product een product is: je weigert te verschijnen in het snelstgroeiende verwijzingskanaal in de detailhandel om tekst te beschermen die je hebt geschreven om dat product te verkopen.

Wees weloverwogen in plaats van standaard. Beslis afzonderlijk over crawlers die trainingscorpora bouwen en agenten die een pagina ophalen om een live winkelvraag te beantwoorden — dit zijn verschillende deals, en de meeste retailers willen de tweede onvoorwaardelijk toelaten.

De andere veelvoorkomende fout zijn te brede disallow-regels. Als je geauthenticeerde oppervlakken zich bevinden op paden op root-niveau die voorvoegsels zijn van marketingpagina's, deindexeert een kale disallow ook stilzwijgend de marketingpagina. Veranker elke regel.

llms.txt is goedkoop en het bezwaar ertegen is zwak

We zagen dit vroeger als een goedkope gok die niemand had genomen. Onze eigen meting zegt iets anders: van 147 bekende DTC-merken publiceren de meeste bereikbare al een llms.txt — en de grote meerderheid heeft het niet zelf geschreven, omdat hun platform een sjabloonversie levert. Google heeft gezegd dat geen enkel AI-systeem het bestand gebruikt; of merchants het publiceren is niet langer de vraag.

De beslissing is dus niet of je er een moet hebben. Het is of de gegenereerde standaardwaarde iets waard is. Een 4.3KB sjabloon beschrijft een generieke winkel — het weet niet welke van je producten belangrijk zijn of wat jou onderscheidt van elk ander merk dat hetzelfde document publiceert. De merken die hun eigen document schreven, variëren van 566 bytes tot 28KB.

De regel hoe dan ook: genereer het vanuit je route-register in plaats van het handmatig te schrijven, zodat het niet kan verouderen. Een verouderde index is erger dan geen, omdat het vol vertrouwen verwijst naar pagina's die zijn verplaatst.

Wat je krijgt zonder iets ervan te bouwen op PlatformDTC

Op PlatformDTC zijn dit platformeigenschappen in plaats van een project. Storefronts server-renderen productgegevens met gestructureerde opmaak als de standaarduitvoer van de publicatiepijplijn. De ontdekkingslaag — robots, sitemap, llms.txt — wordt gegenereerd vanuit de echte routestructuur tijdens het bouwen, dus een pagina die wordt geleverd, is een pagina die vindbaar is.

De programmatische laag is de Agent Gateway: catalogus-, winkelwagen-, offerte- en orderoperaties blootgesteld als scoped API-aanroepen en als MCP-tools, met idempotentiesleutels, een audit trail en een menselijke goedkeuringspoort voor alles wat geld uitgeeft.