An AI shopping agent can only recommend a product with confidence when it understands what the product is, who it is right for, and whether a buyer can actually get it.

For a retailer, machine-readable product data that covers those questions can mean more accurate matches, clearer comparisons, and fewer shopping questions that go unanswered. It does not guarantee a recommendation or a sale. But it gives an AI shopping agent better information to work with.

Picture a shopper asking an agent: "I need a premium main course for 12 guests, delivered before a holiday dinner. Which size should I buy, and what should I order with it?"

Answering that well takes more than good product copy. The agent needs sizes, prices, stock status, serving guidance, shipping conditions, and the products that pair with it. When those facts are scattered or inconsistent, the agent has to do extra work to piece them together, or it leaves the question unresolved.

At eLLMo, this is work we keep doing, not a project we finished. To see how far it has come, we pulled three snapshots from along the way: a typical product page from the market, an early build of our own, and where we stand today.

Two terms, in plain English

JSON-LD is a standard way to give software structured product facts: price, size, stock status, reviews, and more. Think of it as a fact sheet written for machines, sitting behind the page a person reads.

Semantic alignment means the structured facts agree with the product description and the store's own operational data. If a page says an item comes in multiple sizes, the structured data should list those sizes correctly. If an option is sold out, the structured record should not say it is in stock.

A page can carry plenty of JSON-LD and still leave real questions unanswered. The goal is useful, accurate information, not more code for its own sake.

Three snapshots, in order

We looked at a typical product page from a different retailer, an early build of our own for a seasonal product, and today's version of that same product. We anonymized the retailers and every product-identifying detail so the comparison stays about information design, not about any one brand.

1. A typical product page: strong copy, thin structured data

Our starting point was a premium food retailer's product page for a specialty multipack. The page read well, with strong photography and a clear description of the product.

Its structured data said far less. It covered the basics, a merchant, a price, a rating, but treated the product as a single generic option, with little of the detail already written on the page carried into a form software could use. Shipping and return terms were not attached to the offer at all.

An AI agent could still read the visible page copy. But it had to extract and guess at facts that the structured data never stated plainly.

The lesson: a store can know a great deal about its product without putting that knowledge into a form a machine can read.

2. An early build of our own: broader coverage, not yet consistent

For a seasonal product of our own, we went further. More of the product's real structure, its options, pricing, stock, and the specific facts a shopper actually asks about, made it into the data, alongside a fuller plain-language description.

That was real progress. The product was no longer just a name, a description, and one offer.

It also taught us something: more detail only helps when it agrees with itself. We found the written description and the structured data citing different numbers for the same thing. That was worth fixing before anything else.

3. Where we stand today: data an agent can actually decide with

Today, the goal has shifted from describing the product to helping an agent decide whether to recommend it.

We have kept deepening how the different pieces of the page connect to and agree with each other, and closed the gap we found between the written description and the structured data.

The product information now answers the questions that actually drive a recommendation: Who is this best for? Who might prefer something else? Which option fits this order? How does it compare to the alternative? What should go with it?

That is the shift: organizing the information around the decision an AI shopping agent has to make, not only the facts a retailer wants to highlight.

What changed across the three snapshots

We scored each snapshot on three outcomes: how complete the machine-readable data is, how ready the content is to support a useful AI-generated answer, and how ready the data is to support an actual purchase decision.

These are directional, qualitative scores from our own review of each page's data, not measured search rankings, citations, or conversion results. The typical page is a different retailer and product from our own two snapshots, which track the same product over time. The point is not that the data got longer. It is that it answers more of what actually matters to an agent.

What a shopping agent actually checks

We grouped the comparison into a handful of dimensions: the product's basic identity, its offers and options, its specific attributes, its shipping and return terms, who it suits, how it compares with alternatives, and whether the writing and the structured data agree.

Each dimension is scored the same way across all three snapshots. A wider shape means more complete coverage in our review.

The biggest gains are in who the product is for and how it compares to alternatives. A product description can explain why an item is good. Decision-ready data explains whether it is the right choice for a specific shopper, at a specific price, in a specific quantity, with their delivery needs met.

Why this work never stops

Products change. Prices move. New reviews come in. Items go out of stock. Shipping rules vary by location, and seasonal order windows open and close.

That makes machine-readable product data an ongoing engineering job, not a one-time setup task. This comparison is one slice of a process that keeps running. We use what we learn from simulated buyers and the store's own records to keep improving it.

There is still work ahead. Richer structured data is only as useful as it is accurate. A preorder needs the right timing. A variant needs the right stock status. A shipping promise has to match what the merchant can actually deliver. The structured and written data should reinforce each other, never contradict each other.

The opportunity for a retailer is bigger than showing up in an AI answer. It is making it easier for an AI agent to understand why a product fits, which option a buyer should choose, and what has to be true before a purchase makes sense.

To see how AI agents read the rest of a page, see the product pages AI cannot read and why brands are losing organic traffic to AI search.

*Related Links: Google's guide to product variant structured data, Google's guide to merchant listing structured data.*