In our scans of 30 e-commerce stores across nine categories this summer, 11 returned an empty API response to every AI buyer that visited. Not "incomplete." Not "needs work." Empty — zero structured product data on any page. An agent like ChatGPT or Perplexity, asked to find a product those stores sell, receives the equivalent of a 200 OK with a blank body: the server answered, but it returned nothing the caller can use. The agent moves on.
Calling a product page an API endpoint is not a metaphor. When an AI buyer evaluates your store, it issues an HTTP request to your product URL, parses the response, and extracts structured fields — price, availability, brand, return policy — from the JSON-LD block in the page source. That extraction is functionally identical to an API integration: a machine consumer reads a machine-readable payload and makes a decision based on what it finds. If your page has no JSON-LD, your API returns {} to every AI agent that calls it. And like any API consumer that gets an empty response, the agent treats the data source as unavailable and picks another one.
The two consumers of a product page
For 25 years, a product detail page had one consumer: the human shopper. Design, photography, copy, and checkout flow all served that single audience. The page was a destination — a place a person arrived at, looked around, and either bought or left.
That model now has a second, co-equal consumer: the machine agent that reads the page on behalf of a shopper before the shopper ever sees it. This consumer does not evaluate typography or imagery. It evaluates data completeness: can it extract a price as a number, confirm stock status from a controlled vocabulary, cite a brand name, and quote a return window without guessing?
The two consumers have entirely different needs from the same URL. And most e-commerce stores — including well-funded direct-to-consumer brands — have built for only one of them.
Structured data is your API schema
The JSON-LD Product block on a page is the machine-readable equivalent of an API response schema. Each field is a typed property that an AI agent can extract deterministically:
{
"@type": "Product",
"name": "Waterproof Trail Jacket",
"offers": {
"@type": "Offer",
"price": "189.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
},
"brand": { "@type": "Brand", "name": "Alpine Gear" },
"image": "https://store.com/images/jacket.jpg"
}A model receiving this block — alongside a query like "waterproof jacket under $200" — can match every constraint directly against typed fields: name contains the category keyword, price is below the threshold, availability confirms the item is buyable. No parsing, no guessing, no inference from prose. The agent reads the fields and quotes them in its recommendation.
Now consider the same product page without that block. The model sees text, images, and markup. It has to guess which string on the page is the price, whether the product is in stock, and what the brand is. A paragraph that says "ships within 3–5 business days" might be a shipping promise or a generic marketing line — the model cannot tell. When another store's page returns structured data, the model defaults to the unambiguous source. It does not owe your store the benefit of the doubt.
This is the core of the API mental model. If your JSON-LD is missing, your API returns nothing. If your JSON-LD has price as a string with no currency, your API returns a malformed field that the consumer cannot validate. If your availability field says "In Stock" as free text instead of the schema.org URL, your API returns an unrecognized value. In every case, the consumer treats the field as absent and the product as unverified — the same behavior you would expect from any API client that received an invalid response.
What happens when the API returns nothing
The 11 zero-structured-data stores in our scan batch — spanning luxury jewelry, specialty coffee, print-on-demand apparel, photography equipment, and baby goods — averaged 23 out of 100 on overall AI readiness. Their crawlability scores ranged from 40 to 100, meaning some of them were perfectly reachable by AI crawlers. The data layer was the sole point of failure.
A store with perfect crawlability and zero structured data scored 33 at best — because every dimension except structured data represents access and comparison, and there is nothing to access or compare if the data layer is empty. The scoring model weights structured data at 40% of the total, but its influence is closer to 100%: without it, the other dimensions have nothing to work with. An AI buyer that can reach the page but finds no structured data on it is in the same position as an API consumer that gets a 200 with an empty response body — the server is up, but it returned nothing useful.
This is not an edge case. In our batch, 37% of stores returned empty. They are not necessarily small stores. They included a heritage jewellery brand with a global physical footprint and a fast-fashion retailer with millions in monthly traffic. The problem is not resources. It is that nobody on the team thought of the product page as something a machine would call.
The fields your API needs to return
Schema.org defines dozens of Product properties. An AI buyer evaluating a purchase decision cares about a specific subset — the ones that answer the questions a shopper asks before buying. The eight fields that do the work are name, offers.price with priceCurrency, offers.availability, brand, image, sku or gtin, aggregateRating, and hasMerchantReturnPolicy. We broke down each one in the product schema field guide; the point here is structural: every one of these fields is a machine-readable answer to a question an AI buyer will ask. If the field is absent, the model does not guess. It omits your product.
The API mental model also clarifies why partial data is only slightly better than no data. A product page that returns name, price, and nothing else is like an API endpoint that returns a product name and price but no stock status — the consumer cannot tell whether the item is buyable and will not recommend it for a query that implies intent to purchase. Completeness is not a nice-to-have. It is the difference between being quoted and being skipped.
Crawlability is your API gateway
Every API has a gateway layer — authentication, rate limiting, IP allowlisting — that determines whether a consumer can reach the endpoint at all. For a product page, that gateway is robots.txt, the sitemap, and the optional llms.txt file. If robots.txt blocks GPTBot, ClaudeBot, or PerplexityBot, the AI buyer never reaches the page, and the quality of the structured data on it is irrelevant. The API is firewalled.
In our scans, crawlability accounts for 20% of the readiness score — a deliberate underweighting relative to its practical importance, because it is the fastest dimension to fix. Unblocking a crawler is a one-line robots.txt change. Adding a sitemap is a plugin install or a static file generation. The llms.txt file, which tells AI agents which pages matter and why, takes minutes to write and publish at the domain root. We wrote a full guide to llms.txt for stores that want to ship one today.
But crawlability alone cannot save a store with no structured data. The stores in our batch that had crawlability scores of 100 and structured data scores of 0 finished with overall readiness in the low 30s — a clean demonstration that access without data is an open door to an empty room. The gateway layer matters, but the response body matters more.
Designing for two consumers
The stores that scored well in our scans — 80 and above on overall readiness — had one thing in common: their product pages were built for both consumers. They had valid, complete Product JSON-LD that an AI agent could extract deterministically, and a visual experience that served the human shopper. The two are not in tension. Structured data lives in the <head> or at the bottom of the <body>; it costs no pixels of above-the-fold real estate and requires no design compromise.
The shift from "my page is a destination" to "my page is an endpoint" is not a technical migration. It is a recognition that a second consumer is already calling your URLs, right now, whether you built for it or not. The only question is what it finds when it does.
See where your store stands — run a free scan at prefero.me.