What makes a product page readable by a shopping agent

Something different from what a person does. A person looks at the photos, forms an impression, reads two lines of description, and decides on criteria they cannot fully articulate. An agent starts from a request with explicit constraints (a budget, a size, a delivery date, a compatibility) and tries to verify each one. Whatever it cannot verify, it treats as risk.

The practical consequence inverts a settled merchandising rule. In human commerce ambiguity is sometimes useful: not stating shipping times avoids discouraging the purchase, and the image carries the page. For an agent ambiguity is grounds for exclusion: no date found means the constraint cannot be guaranteed, so it moves to the next page.

This is not about writing for a machine instead of a person. It is about making resolvable the information that is already present but implicit: inside an image, inside a menu that opens on click, inside a sentence that says "fast shipping" instead of a number of days.

The criterion is not whether the data exists, it is whether it resolves: a value, a unit, a stable place to read it. The table separates the two, because almost every catalog I look at has the data and lacks the form.

Because they are the only two constraints that make everything else irrelevant. A perfect product out of stock is not an option, and a product over budget never enters the comparison. An agent asked to return three valid alternatives checks these first, and whatever fails that filter never reaches feature evaluation.

The most common technical problem sits in exactly these two fields. On many storefronts price and availability do not exist in the served HTML: they appear after a cart call, or after the user selects a variant. To a human eye this is invisible, because the browser runs everything and the page looks complete. To whoever reads the server response, those fields are empty.

The check is trivial and I recommend it to anyone with a catalog: fetch the HTML of a product page without executing JavaScript and search for the price. If it is not there, your best page is invisible to anyone not rendering it, and that includes part of the systems now comparing products.

Then there is consistency. Price on the page, price in the feed, and price in the structured data must match. When they diverge the system does not pick the lowest: it records an inconsistency, and an inconsistency on a commercial field is the worst kind to have, because it casts doubt on the correct fields too.

Variants are where most catalogs become illegible, because they mix two structures: a product that is a concept (the model) and its variants that are the purchasable things (size, colour, capacity). If the page exposes only the concept, no size or colour constraint is verifiable.

The form that works keeps the two levels distinct and linked: the model as container, each variant with its own identifier, price, availability, and attributes. You do not need one page per variant. You need every variant readable from the model page, all of them, not just the one selected by default.

The opposite mistake costs as much: multiplying pages and letting each declare itself the main product. The result is a family of near-identical pages competing with each other, where the system cannot tell which one represents the model and picks unstably. A correct canonical and a declared model-to-variant relationship solve both cases.

Reviews serve an agent for a different reason than they serve a person. A person reads them for reassurance. An agent uses them as a source of attributes the catalog does not declare: if twenty reviews repeat that the garment runs small, that becomes a de facto attribute, and it will be used to answer a fit question even when your page says nothing.

This makes reviews a readability lever, not only a conversion one. If an attribute keeps surfacing in reviews and is missing from the page, the page is incomplete on a point the market considers relevant. Worth reading them with that eye: they are a free list of missing attributes.

On claims the rule is simple: what cannot be verified does not help and can hurt. "Best in class" is not data and enters no comparison. "Waterproof to 5 metres for 30 minutes" is data, enters a comparison, and can win the page on a specific question. Replacing a superlative with a measurement is probably the highest effort-to-result intervention available on a product page.

With four checks you can run on one page in half an hour, before involving anyone.

Do not fill attributes with generic values to complete the schema. A badly populated attribute is worse than an empty one, because it produces a wrong comparison instead of a missing figure, and the missing figure is at least honest.

Do not add structured data that contradicts the visible page. A price in the schema different from the price on screen is a declared inconsistency, and engine guidelines treat it as one.

Do not start from the whole catalog. One cycle on twenty to a hundred representative products tells you which problems are systemic, and systemic problems are almost always few and repeated. Fixing them on the sample produces the specification for fixing them everywhere, and in that order the work actually finishes.