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 matters to people too: a promise of "fast shipping" does not establish whether a product will arrive before a deadline. An agent asked to meet that date may seek clarification, flag uncertainty or prefer a verifiable alternative. There is no exclusion rule shared by every system; there is missing information that makes the comparison harder.

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 can make other features irrelevant to the request. If the customer needs to buy immediately within a budget, an unavailable or overpriced product does not meet those constraints. Price and availability are therefore priority checks for that task, not a mandatory sequence followed by every agent in every search.

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. The page, feed and structured data must describe the same variant under the same commercial conditions. A discrepancy makes the usable price ambiguous and may require another check. We cannot infer which value every system will select: we can correct the mismatch and state when and under which conditions the price is valid.

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, color, capacity). If the page exposes only the concept, no size or color 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 can give people and agents information the catalog does not declare. If several customers report that a garment runs small, they raise a fit issue worth checking. A system may consider it during comparison, but it is not a certified attribute or a source every agent will use in the same way. The page should distinguish manufacturer specifications from customer experiences.

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.