Definition
Structured product data is product information recorded as typed, named fields whose meaning is declared in advance, so a system can read a value without interpreting the sentence around it. Its opposite is not inaccurate data — it is prose, which carries the same facts in a form only a human reader can reliably decode. Structure is a property of how information is stored and transmitted, not of how true or how well written it is.
Key points
- Product information sits on a spectrum: unstructured prose, semi-structured tables and bullet lists, and fully structured records where each fact occupies its own typed field.
- A field counts as structured only if something declares what belongs in it — a name, a data type, a unit where the fact is a measurement, and often a controlled list of permitted values.
- That declaration exists in two places: internally, in the catalog's own schema, and externally, in whatever vocabulary carries the data to another system.
- The external vocabularies are what make the data portable — schema.org markup on a page, a merchant feed specification, a GS1 identifier — each one a shared agreement about what a given field means.
What separates structured product data from a good description?
Take a drill listed as "cordless 20V drill with a half-inch chuck and two batteries." A person understands that instantly. A system cannot filter on it, because nothing in the string says that 20 is a voltage, that half an inch is a chuck capacity rather than a bit size, or that two counts an included accessory rather than a warranty term. The structured version stores voltage as a number with a unit, chuck capacity as a number with a unit, and included items as a repeatable list. The facts are identical. Only one version can be sorted, validated, or compared against a competing product.
Common pitfalls
- Publishing a field with no declared type or unit, leaving downstream systems to guess whether "20" means volts, amps, or minutes.
- Assuming a spreadsheet is structured data — column headers name the fields, but nothing constrains what the cells beneath them contain.
- Structuring data carefully inside the catalog and then flattening it back into a description string on the way out to a channel.
FAQ
How is this different from structured product data for AI?
This page defines the underlying form. Structured product data for AI takes that same form and holds it to a stricter bar, covering the applied work — schema design, disambiguation, semantic markup — that models and shopping agents need before they can reason over a catalog.
Does structured product data have to appear as markup on the page?
No. A catalog can be rigorously structured internally and expose none of that publicly. Markup is one delivery mechanism among several; feeds, APIs, and exports carry structured data equally well. Markup simply makes the structure visible to systems that only ever see the rendered page.
Source
How declared, machine-readable fields differ from page text, and why a shared vocabulary is required for another system to interpret them, is explained in Google's introduction to structured data.