What Machine-Readable Product Data Really Means

"Make your product data machine-readable." You hear that a lot right now, and it is true. But it usually stays abstract. What exactly should be readable, for whom, and how do you know it works? This article makes the sentence concrete.

Which fields an agent actually needs

An AI agent shopping for a customer makes a series of decisions on a product page. Does the product match the request, is it available, what does it cost, in which variant, when will it arrive. Each of those decisions needs a data field it can read reliably.

Five fields are decisive. The product name and description, so the agent understands what it is looking at. The price, the current one, not last week's. Availability, because an agent is reluctant to suggest something that cannot ship. Variants, meaning size, colour, version. And delivery time, because it often tips a buying decision.

If one of these fields is missing or ambiguously stored, the product either drops out for the agent or gets classified wrong.

Having data is not the same as delivering it

The most common mistake is to assume that because the data exists, an agent must be able to see it. But existing in the shop system is not the same as delivered in the HTML. Many shops keep their product data neatly maintained in the database and only load it into the page via JavaScript once a browser opens it. An agent reading the raw HTML gets none of it.

Machine-readable therefore means the decisive fields are already in the delivered HTML, in a form a machine can map unambiguously. In practice this is usually structured markup following the schema.org standard, embedded as JSON-LD right in the page. There it does not just show the number 149. It marks 149 as the price in euros, along with availability and variant.

How to check it arrives

The fastest test takes two minutes. Open a product page, right-click and choose "View page source". That is the HTML before JavaScript runs. Search it for the price, then availability, then a variant.

Find all three and you are in good shape. Find the price but no availability and you have a typical partial gap. Find nothing at all while the browser shows everything, and your data sits behind JavaScript where an agent cannot see it.

For a closer look, a Readiness Check tests the same fields systematically and shows where the gaps are.

Feed and interface as the next step

Structured data in the page is the foundation. Looking further ahead, you also provide your product data as a feed or through an interface, so an agent can query the catalogue without reading every page one by one. Not everyone needs this yet, but it is the direction the standard is moving. Getting the foundation right now makes the rest easier later.

Why this matters now

Morgan Stanley expects AI agents to account for between 190 and 385 billion dollars of US online commerce by 2030. In the same analysis, the bank names the precondition explicitly: retailers need to make inventory, prices, variants and delivery times machine-readable and retrievable. That is exactly the list above.

The good news is that getting there is rarely a rebuild. Usually it comes down to delivering the key fields server-side instead of loading them via JavaScript. For the common shop systems, that is a manageable step.

You already have almost all the fields an agent needs. The only question is whether they are in the right place.