What exactly did the shopper ask?
“Find me a gravel bike under CHF 4,000 that’s good for long alpine rides, and that I can get in Switzerland within a week.” The request carries four constraints an agent has to check against each candidate: a price ceiling in Swiss francs, a riding use that implies gearing and frame geometry, a country, and a delivery window.
This is a constructed worked example, built to show the mechanics, and no real shop or sale is described. The two shops below are invented, and the fields are the ones our agentic commerce readiness check reads in real audits.
Why did the first shop drop out?
Shop A sells a suitable bike at CHF 3,790. Its product page looks excellent to a person: large photos, a geometry chart, a green “in stock” badge. To the agent it fails at three points.
- The price and the stock badge are loaded by JavaScript after the page renders, so the HTML the agent fetches contains neither.
- The geometry chart is an image, so the stack, reach and tyre clearance that tell the agent whether the bike suits long climbs are not readable.
- There is no GTIN and no
Offerin the markup, so the agent cannot confirm that the bike on this page is the same model it saw reviewed elsewhere.
The agent cannot confirm the price is under CHF 4,000 or that the bike reaches Switzerland within a week, so it does not recommend it. Nothing on Shop A’s side records that this happened: there was no visit a person made and no basket that was abandoned.
Why did the second shop win?
Shop B sells a comparable bike at CHF 3,890, CHF 100 more. Its page declares a Product with a GTIN, brand and model, an Offer with price: 3890.00, priceCurrency: "CHF", availability: "InStock", and a shippingDetails block stating delivery to Switzerland in two to three days. The frame geometry and gearing are published as an HTML table, and a Markdown version of the size guide is linked from the page.
The agent can check every constraint against a field. It recommends Shop B’s bike first, explains why in one line per constraint, and, on a channel that supports agent checkout, builds a cart through Shop B’s checkout endpoint once the shopper confirms.
Which schema.org fields did the agent check, constraint by constraint?
Each constraint in the request maps to one field the agent can verify, and Shop A failed all five because each fact existed only on screen or not at all.
| Constraint | Field the agent reads | Shop A | Shop B |
|---|---|---|---|
| Under CHF 4,000 | Offer.price with priceCurrency | Price loaded by JavaScript, absent from the fetched HTML | 3890.00, CHF |
| Suits long alpine rides | Geometry and gearing as text, in additionalProperty or an HTML table | Geometry chart published as an image | HTML table with stack, reach, tyre clearance and gearing |
| Available in Switzerland | Offer.availability and shippingDetails.shippingDestination | Stock badge loaded by JavaScript, no shipping block | InStock, destination CH |
| Delivered within a week | shippingDetails.deliveryTime | Not declared | Two to three days |
| Same model as reviewed elsewhere | gtin, brand and model | No GTIN, brand and model only in the title | GTIN, brand and model declared |
OpenAI’s help page on shopping in ChatGPT supports this logic in its own words: it reads structured metadata such as price, and “if you specify a budget of $30, ChatGPT will focus more on price” (OpenAI Help Center, fetched 16 October 2026). The same page says merchants selling one item are ranked on availability, price, quality and whether they are the maker or primary seller. A budget in the request makes the price field decisive, and an unreadable price cannot pass it.
What does this example show about price?
That the cheaper shop lost. An agent compares what it can verify, so a lower price that cannot be read is worth less than a higher one that can. The boundary is that this holds when the agent does the shortlisting. A shopper who already knows Shop A and visits it directly still sees the lower price, which is why readiness work adds a channel rather than replacing the existing one.
Does this apply to products other than bikes?
Yes, wherever the request carries a hard constraint that maps to a field: a budget, a size, a compatibility, a delivery date. A shopper asking for a laptop under CHF 1,500 with 32 GB of memory, or a sofa that fits 220 cm and arrives before a move, sets the same test, and the shop whose answer sits in a field passes it.
It holds less where the choice is driven by taste and reputation rather than specification, such as a gift box of chocolate. There, being named at all depends more on the guides and reviews the assistant already cites, as the chocolatier audit shows. For sports retailers the field list goes further, with sizes, ski lengths and service options, and it is set out for AI shopping agents for sporting goods. Matching a product across shops rests on its identifier, which is why the GTIN for AI shopping agents comes first in most catalogues.
The free readiness check tests a single product page against the same fields, and the Buyer Journey Check runs missions like this one through real assistants on your own catalogue.