There is an uncomfortable asymmetry in how retail sites are built. The pages that carry the least decision detail are the best structured, and the page that carries all of it is the worst.
Adobe's research across the US retail sector scored product pages lowest of any page type on machine readability. They also found that 79% of product pages do not ship a full set of structured data, and that the spread is enormous: the best-performing sites averaged 82.5% while the lowest averaged 54.2%.
Some of the specifics are stark. Only 5% of sites state shipping terms in a machine-readable way, and only 4% state return terms. Those are two of the facts a buyer most often decides on, and almost nobody publishes them in a form anything but a human can read.
Machine readability by page type, US retail
Adobe AnalyticsThe page carrying all the comparison detail scores lowest. Adobe also report a spread from 82.5% at the best sites to 54.2% at the worst.
View as table
| Value | |
|---|---|
| Homepages | 75% |
| Category pages | 74% |
| Product pages | 66% |
Share of sites stating these terms in a machine-readable way
Adobe AnalyticsTwo of the facts buyers most often decide on, and almost nobody publishes them in a form anything but a human can read.
View as table
| Value | |
|---|---|
| Shipping terms | 5% |
| Return terms | 4% |
Why the product page is the hard one
A homepage has a handful of things on it and they are mostly navigational, so marking them up is tractable. A product page has to express everything that distinguishes one item from a near-identical one, and most of that distinguishing detail was written as prose because prose is what sells.
So the richer your product copy, the larger the gap between what you have said and what a structured consumer can use. A beautifully written description is an asset to a human reader and invisible to an agent applying a filter.
Structured data is downstream of recorded data
It is tempting to treat this as a markup task: add the schema, ship the JSON-LD, done. That works for the fields you hold. It does nothing for the fields you never recorded, and those are the ones that decide comparisons.
You cannot mark up a fact you do not have. Schema coverage is capped by attribute coverage.
Which puts the work in an order: find out which attributes a decision in your category actually turns on, check which of those you record, recover what is recoverable from the text you already publish, and only then argue about markup. Doing markup first produces a well-structured statement of the things you happened to have.
What to check on your own catalogue
- Take one category and list the constraints a buyer would filter on. Not the fields you have, the constraints they have
- For each, check whether it exists as a value rather than as a sentence in the description
- For the ones that are sentences, that is extraction work and it is usually cheap
- For the ones that are absent entirely, that is acquisition, and knowing which is which before you commit is most of the value