Structured Data for Product Discovery by Agents

Quick answer. Structured data for product discovery by agents is the machine-readable layer of a product page: schema.org Product and Offer markup carrying price, currency, availability, GTIN, brand, shipping and return terms. Agents read that JSON-LD to identify an item, compare it against alternatives and judge whether it can be bought. It improves machine comprehension today. Fully autonomous checkout still depends on protocols that are not settled.

What matters most

• Agents parse the same schema.org Product and Offer properties Google uses, so one accurate markup layer serves both readers.
• Price, availability, GTIN and delivery terms decide whether an item survives a comparison; descriptive copy does not.
• Markup that contradicts checkout teaches an agent to distrust the feed, and distrust is harder to fix than missing data.
• Variant-level offers, not one parent product, are what an agent needs to shortlist a specific size or colour.
• No markup guarantees inclusion in an AI answer, and most assistant traffic cannot be attributed with current tooling.

What does an AI agent actually read on a product page?

An agent does not browse. It fetches the HTML, or calls an API, and pulls facts out of the response. The facts it trusts most are the ones you declared: JSON-LD blocks using schema.org Product and Offer, present in the page source rather than assembled later by client-side JavaScript.

From that block an agent resolves four things. The entity, meaning brand plus GTIN or MPN. The offer, meaning price, currency, availability and condition. The terms, meaning shipping cost, delivery estimate and the return window. The media, meaning image URLs it can fetch and size. Where a fact is missing, the agent guesses from your copy or moves to a page that states it plainly. Guessing produces bad comparisons. Silence produces no comparison at all.

Two newer surfaces sit alongside markup. An MCP server exposes catalogue search and stock checks as tools an agent can call directly, which suits API-first and headless catalogues. An llms.txt file gives language models a plain-text map of the site. Neither is a ratified commerce standard, and neither replaces accurate Product markup. Treat them as additions.

• Entity: brand, gtin13 or mpn, so the item resolves to one real product rather than a title match
• Offer: price, priceCurrency, availability, itemCondition
• Terms: OfferShippingDetails with cost and transit time, MerchantReturnPolicy with window and method
• Media: fetchable image URLs with width and height declared
• Constraints: size, colour, material, pattern, plus weight and dimensions where shipping depends on them

Where to go next

• e-commerce SEO for commerce platforms
• headless SEO and server-rendered markup
• agentic delivery platform work
• analytics and attribution for assistant traffic
• the commerce platforms we work across

Which catalogue fields actually change a buying decision?

Most product pages carry enough text to describe an item and not enough structure to compare it. The fields below are the ones that decide whether an agent can shortlist you at all.

Two rules apply to every one of them. The markup must match what the page and the checkout actually show, because an agent that finds InStock on a sold-out item learns to distrust the whole feed. And the values must be machine-formatted: ISO 4217 currency codes, ISO 8601 dates, schema.org ItemAvailability values. Free text such as ‘usually ships in a few days’ is not a delivery estimate an agent can use.

• gtin13, mpn and brand: resolve the item to a single product and separate you from a reseller listing
• offers.price and priceCurrency: a price without a currency is a number, not a claim
• offers.priceValidUntil: tells an agent when a promotional price stops being true
• offers.availability: use InStock, OutOfStock, BackOrder or PreOrder, and refresh it from live inventory
• shippingDetails: delivery cost and estimated transit time, which agents need to compare landed cost
• hasMerchantReturnPolicy: the return window and method, which affects perceived risk on higher-priced items
• itemCondition, color, size, material: the fields that let an agent confirm the variant a customer asked for

Where does product markup usually break?

The failures are repetitive. In most audits the same five faults account for the majority of unusable product data, and none of them are visible to a shopper.

The pattern behind them is consistent: the human-facing template was built first, and the structured layer was bolted on by a theme, plugin or app that knows nothing about inventory rules or pricing schedules. Audit the rendered output, not the intent.

How do you handle variants, currencies and unit prices?

Variants first. An agent asked for a 42-inch chest in navy needs an offer it can point at, so give each sellable variant its own URL, its own Product node and its own availability. A single parent product with an AggregateOffer that says ‘from £19’ gives an agent nothing to shortlist and a customer nothing to buy.

Currencies next. Publish one Offer per currency you genuinely sell in, set priceCurrency on each, and never publish a converted figure the checkout will not honour. Where you sell by measure, UnitPriceSpecification states the price per unit, which is the number some comparison surfaces quote back to a customer.

Then validity. If a price ends on a date, say so with priceValidUntil. An agent that reads an expired validity date may discard the offer even though the page still renders the old price.

Does structured data guarantee your products appear in agent answers?

No. No search engine or model provider publishes a rule stating that markup earns inclusion in an AI answer. Markup raises the chance that an agent can read, verify and compare you. It does not buy placement, and it will not rescue a product that is out of stock or priced inconsistently.

Measurement is the honest weak point. You can watch server logs for known crawler user agents, and you can read referrer data where assistant surfaces pass it through. Both are partial. Many assistant sessions end inside the assistant, with no click and no referrer, so the visit never appears in your analytics at all. Treat assistant traffic reporting as directional rather than complete.

What you can measure properly is the input. Whether your Product markup validates, whether price and availability match the checkout, whether crawler requests for product URLs return a 200 with the offer present in the source. Those are within your control and they are where the work belongs.

What should you fix first on your platform?

The order is the same everywhere: identity, then offer accuracy, then terms. Identity means GTIN, MPN, brand and a clean variant structure. Offer accuracy means server-rendered price and live availability. Terms means shipping and returns attached to the Offer. How you do it depends on what you run.

On Shopify and Shopify Plus, check what the product template emits and confirm that variant price and availability come from the served variant, not the parent product. Apps that inject a second Product block are common and they create conflicts. On BigCommerce, check the Stencil product templates and any structured data setting or app, and make sure your GTIN, UPC and MPN fields actually reach the markup. On WooCommerce, product schema usually comes from an SEO plugin or the theme rather than the core plugin, so confirm which one is emitting it before you change either. On Adobe Commerce, Salesforce Commerce or SAP Commerce, generate the markup in the GraphQL or headless layer so it renders server-side. On any headless storefront, emit JSON-LD in the server response, not after hydration.

A workable first week: export every product URL, fetch each one without JavaScript, and check the offer is present. Compare a sample of prices and stock counts against the checkout. Add the missing GTINs. Attach shipping and return terms. Then put a weekly check in place, because markup decays the moment merchandising changes a template.

• Validate one product, one variant and one out-of-stock item in Google’s Rich Results Test
• Fetch ten product URLs with JavaScript disabled and confirm price, availability and GTIN are visible
• Reconcile a sample of markup prices against live checkout prices
• Add OfferShippingDetails and MerchantReturnPolicy where they are missing
• Log crawler user-agent hits on product URLs so you can see who is fetching and what they receive

Frequently asked questions

Do AI assistants actually read schema.org markup on product pages?

Some do, some do not, and none publish their rules. Large crawlers generally prefer declared JSON-LD because it is cheaper to parse than page copy. Your markup is a low-cost way to remove ambiguity about price, stock and identity. Treat it as a precondition for being compared, not a guarantee of being recommended.

Should I use JSON-LD, microdata or RDFa?

JSON-LD. Google’s documentation recommends it, it sits apart from your HTML so template changes are less likely to break it, and a parser can extract it in one pass. Microdata and RDFa remain valid and are still read. Do not mix formats on the same product page, because conflicting values force a parser to pick one and it may not pick yours.

Do I need different structured data for Google and for AI agents?

No. Both consume schema.org Product and Offer. Google’s product documentation defines a subset with eligibility rules for rich results and merchant listings. Agents generally read a wider set, including shipping and return terms. Publish one accurate, complete block. Maintaining a separate ‘AI version’ creates contradictions that reduce trust in both.

What is llms.txt and does it help product discovery?

llms.txt is a proposed convention for a plain-text file at the site root that points language models to key pages. It is not a ratified standard and no major model provider commits to reading it. Publishing one is cheap and harmless. It does not substitute for accurate per-product markup, and you should not expect measurable discovery from it alone.

Can an agent buy from my store without a human?

Rarely, and not through markup. Markup describes a product; it does not authorise a transaction. Agent-initiated checkout needs a payment and order protocol agreed between the assistant, the merchant and the processor, and merchant coverage is still thin. Most agents today research, compare and hand over a link. Build for that path first and keep your product data consistent with checkout.

Sources

• Product type and its properties, including offers, gtin, mpn, brand and itemCondition
• Google’s product structured data requirements and merchant listing properties
• llms.txt proposed convention for pointing language models at key pages
• Model Context Protocol, for exposing catalogue data as callable tools