Structured product data for AI agents is not a new standard. It is Product and Offer schema done properly, served in the initial HTML rather than injected by JavaScript, and kept accurate. An agent comparing your product against three competitors needs six things it can extract without rendering your page: what the product is, what it costs and in what currency, whether it is available, which variant it is, how long delivery takes, and what happens if the customer returns it. Miss any of those and the agent either guesses or moves on. This matters concretely: web-scraped product data of poor quality was one of the reasons OpenAI wound down its Instant Checkout effort in spring 2026.
Key Takeaways
- This is standard structured-data hygiene applied to a new consumer, not an exotic new standard. If you already do rich results properly, you are most of the way there.
- Product data quality, stale prices, missing availability, wrong variants, contributed to the retreat of the first serious agentic checkout attempt.
- The non-negotiable rule: price and availability must be in the initial HTML. JavaScript-injected values are unreliable for agents that fetch rather than render.
- Six core fields carry most of the weight: identity, price + currency, availability, variant, delivery estimate, returns policy.
- Variants are where most implementations break. One URL showing six sizes with one schema block is unusable to an agent.
- Wrong structured data is worse than absent structured data. Accuracy beats completeness.
- Everything here also serves search rich results and AI answer engines, so the work is not a bet on agent adoption.
Six fields do most of the work. Getting them right is mostly discipline, not engineering.
Why This Is Urgent-ish, Not Urgent
Two September 2026 launches put agents on more websites: Meta Muse (8 September), a consumer agent that browses in a sandboxed VM and can make purchases; and OpenAI's Agents API (10 September), which makes agent-building cheap.
But agent traffic is still small, and agentic checkout has already retreated once. So the honest framing is: do this because it is overdue hygiene that also happens to serve agents, not because your revenue depends on it this quarter.
The lesson from the first attempt
OpenAI's Instant Checkout was wound down in spring 2026. Conversion came in around a third of a major retailer's own site performance, and the product data feeding it, much of it web-scraped, had quality problems.
Scraping exists because first-party data was not available in machine-readable form. If your data is published cleanly, nobody has to scrape it, and nobody gets it wrong.
The Field Spec
| Data field | Why an agent needs it | How to expose it |
|---|---|---|
| Product name and identity | To confirm it has the right item before comparing anything | schema.org/Product → name, plus sku, gtin13/mpn where available |
| Brand | Disambiguates near-identical products across retailers | Product.brand as a Brand object |
| Description | Feature and suitability matching against the user's request | Product.description: plain text, in the HTML, not only in a tab |
| Price | The single most compared field | Offer.price: numeric, no currency symbol in the value |
| Currency | A number without currency is unusable in a cross-market comparison | Offer.priceCurrency: ISO 4217 code (INR, USD) |
| Availability | Determines whether you stay in the comparison set at all | Offer.availability → InStock, OutOfStock, PreOrder, BackOrder |
| Price validity | Prevents an agent quoting an expired promotional price | Offer.priceValidUntil |
| Variant (size, colour, capacity) | Users ask for a specific variant; the wrong one is a failed task | Separate Offer per variant, or ProductGroup with hasVariant and variesBy |
| Variant-level price and stock | Variants differ; a product-level answer is often wrong | Price and availability on each variant Offer, not only the parent |
| Delivery estimate | A frequent deciding factor when price is close | Offer.shippingDetails → OfferShippingDetails with deliveryTime |
| Shipping cost | Affects true comparison price | OfferShippingDetails.shippingRate with shippingDestination |
| Returns policy | Agents check risk before recommending a purchase | Offer.hasMerchantReturnPolicy → MerchantReturnPolicy with window and method |
| Ratings and review count | Used as a quality proxy in ranked comparisons | Product.aggregateRating, only if genuine and policy-compliant |
| Canonical product URL | The handoff target under "discover in AI, buy on site" | Offer.url: deep link to the exact variant, no session parameters |
| Condition | New vs refurbished changes the comparison entirely | Offer.itemCondition |
| Feed equivalent | Some surfaces consume feeds, not page markup | Merchant feed with the same fields, generated from the same source of truth |
Reference the vocabulary directly at schema.org/Product and schema.org/Offer rather than copying a blog's example, the examples age badly.
The Rule That Matters Most: Server-Side, Not Client-Side
If you take one thing from this post, take this.
Why JavaScript injection fails
Some agents render JavaScript fully. Many do not, because fetching raw HTML is faster and cheaper, and agents run under token and time budgets. If your price arrives from a client-side API call after page load, you are betting on the agent being in its expensive mode.
You do not control that. You do control your HTML.
How to check
Fetch your product page with curl and search the response for the price string, the currency code and the availability value. If they are not there, an agent that does not render cannot see them.
The partial-render trap
Worse than full client-side rendering is partial: a schema block present in the HTML with a placeholder price, updated later by JavaScript. A non-rendering agent reads the placeholder and reports a wrong price confidently. Absent data leads to a shrug; wrong data leads to a wrong recommendation.
Variants: Where Implementations Break
The most common serious error I see.
The problem
One product URL displays six sizes. The page carries a single Product schema block with one price and one availability value. A user asks an agent for size 9 in black. The agent has no way to know whether size 9 in black exists, costs the same, or is in stock.
Two valid approaches
Separate URLs per variant, each with its own complete Offer: cleanest, and gives you a deep-linkable handoff target per variant.
`ProductGroup` with `hasVariant`, using variesBy to declare the varying attributes, and a full Offer per variant including its own price and availability.
Either works. What does not work is a parent-level price standing in for six different variants.
Deep links matter under "discover in AI, buy on site"
If the consensus is that the agent discovers and the human buys on your site, then the URL the agent hands over should land the human on the exact variant, ready to add to cart. A link to a generic product page that requires re-selecting size and colour loses conversions you already won.
Under "discover in AI, buy on site," your canonical variant URL is the handoff. Make it land precisely.
Policies Are Product Data Too
Shipping and returns are not marketing pages. To an agent making a recommendation, they are decision inputs.
Delivery estimates
deliveryTime with handling time and transit time, and shippingDestination where rates vary by region. "Ships in 2–4 business days to most Indian metros" as plain HTML is genuinely useful; a delivery estimate that only appears at checkout is invisible at the moment the decision is made.
Returns
Window in days, who pays return shipping, refund vs exchange, and any category exclusions. Use MerchantReturnPolicy and also publish it as readable HTML at a stable URL. An agent that cannot confirm your returns terms will prefer a competitor whose terms it can confirm.
Do not hide policies
Not in a PDF. Not in an accordion that loads content only on click. Not exclusively in a chat widget. All three are opaque to an agent, and two of them are annoying to humans as well.
Accuracy Beats Completeness
A tempting shortcut is to mark up everything with whatever values are handy. Do not.
Wrong data is worse than no data
An agent that recommends your product at a price that turns out to be stale, or as in stock when it is not, produces a bad experience that the user attributes to your brand. Once, that is a refund. Repeatedly, it is a source the agent learns to distrust.
Keep one source of truth
Page markup, merchant feed and any API should read from the same inventory and pricing system. Divergence between your schema block and your feed is a common, invisible, corrosive bug.
Validate on a schedule
Run structured data validation as part of your deploy pipeline, not as an annual audit. Template changes break schema silently and often.
What This Is Not
It is not a new standard. It is not protocol-specific: ACP, UCP and AP2 all need accurate product data, so this work is correct regardless of which wins. It is not something you need a vendor for. And it is not an argument that agent traffic is large today, because it is not.
It is overdue structured-data hygiene, serving a new consumer alongside the old ones.
FAQ
What is structured product data for AI agents?
Product information published in a machine-readable format, principally schema.org Product and Offer markup in the page HTML, so an automated agent can extract price, availability, variants, shipping and returns without rendering or guessing.
Is this a new standard I need to adopt?
No. It is existing schema.org vocabulary applied properly. The new part is the consumer, not the format.
Why must product data be in the initial HTML?
Many agents fetch raw HTML rather than rendering JavaScript, because it is faster and cheaper. Client-side-injected prices and stock status are invisible to them, and placeholder values in the HTML can be read as real.
Which fields matter most?
Product identity, price, currency, availability, variant-level detail, delivery estimate and returns policy. Those six carry most comparison decisions.
How should I handle product variants?
Either give each variant its own URL with a complete Offer, or use ProductGroup with hasVariant and variesBy, ensuring each variant carries its own price and availability. A single parent-level price for six variants is unusable.
Does this help with SEO as well?
Yes. The same markup drives search rich results and helps AI answer engines quote you accurately, so the work is not contingent on agent adoption.
What did OpenAI's Instant Checkout retreat teach us?
That product data quality is a real bottleneck. Conversion came in around a third of a major retailer's own site performance, and web-scraped product data had quality problems. Clean first-party data removes the need to scrape.
Which agentic commerce protocol should I target?
None specifically. ACP (OpenAI/Stripe), UCP (Google/Shopify) and AP2 (Google plus partners, now at the FIDO Alliance) all depend on accurate product data, so build the data layer and stay protocol-neutral.
How often should I validate structured data?
On every deploy. Template changes break schema silently, and stale or broken markup is worse than none.
Do I need a product feed as well as page markup?
If the surfaces you care about consume feeds, yes, but generate both from the same source of truth so they cannot disagree.
If you want this implemented properly rather than partially, and a view on what else in your organic setup is quietly leaking, take a look at my work and get in touch through the contact form at younusfardeen.com. I have 4+ years of marketing experience helping brands grow organically, and this kind of unglamorous foundation work is usually where the compounding starts.