Product Dimensions Structured Data: Fields Nobody Fills In

Product dimensions structured data is the part of your listing that nothing with eyes ever reads — and it is now the part that decides whether your product turns up in an answer at all. You put 600 × 320 × 720 mm on the spec image. A shopper reads it. A crawler, a shopping feed and an assistant answering "what wall cabinets are under 350 mm deep?" read nothing, because that number exists only as pixels.

Product dimensions structured data means the machine-readable declaration of a product's physical size: named fields carrying numeric values and explicit units, published either as JSON-LD on the product page or as columns in a merchant feed. Three separate specifications now define those fields, they disagree about names, and most catalogues fill in none of them.

Here is the whole block, field by field, with the copy-paste version at the end.

Product dimensions structured data: the three specs that read your size

Read the bottom row twice, because it contains the trap almost every catalogue falls into.

Google's dimension fields describe your box, not your product

shipping_length, shipping_width and shipping_height are optional, accept centimetres or inches, and are bounded at 1–400 cm or 1–150 inches. Google is explicit about their job: they exist to help determine shipping cost when you use a carrier-calculated method. All three must be supplied together in the same unit, or the data cannot be used at all.

So they describe the carton. There is no Merchant Center attribute for the finished product's own dimensions.

That gap is why product_detail matters more to you than any other field on this page. It carries technical specifications not covered by other attributes, in a three-part format separated by exactly two colons:

section_name : attribute_name : attribute_value

section_name is optional but recommended; attribute_name and attribute_value are required. Google's own examples follow the shape Display:Size:13 inch and Battery:Capacity:12.5 hours. Which means the correct home for a product's real size in a Google feed looks like this:

Two rules that keep this clean. Put the unit inside attribute_value — the field is free text and a bare "600" is unusable. And never restate anything that already has its own attribute: Google tells you not to duplicate information covered elsewhere, and price or delivery-timing data is explicitly out of bounds here.

schema.org: the four fields plus the one nobody uses

On the page itself, schema.org gives Product direct dimension properties, each accepting a Distance or a QuantitativeValue:

• width — "The width of the item."
• height — "The height of the item."
• depth — "The depth of the item."
• weight — a Mass or QuantitativeValue.

Then there is size, which is a different kind of field and routinely misused. Its definition allows a plain text string such as XL or 32Wx34L, a QuantitativeValue with a unitCode, or a full SizeSpecification — and it says outright that where those don't fit, "width, height, depth and weight properties may be more applicable." Translation for anyone selling anything that isn't apparel: use size for garment sizing systems, use the four dimension properties for physical goods, and don't put 600x320x720 in size as a string.

The field nobody uses is hasMeasurement, a QuantitativeValue on Product intended for measurements of the item — schema.org's own examples are the inseam of pants, the wheel size of a bicycle, the gauge of a screw. It accepts an array, so it is where every secondary dimension belongs: internal shelf width, seat height, fixing centres, aperture, thread pitch. These are the numbers a buyer emails you about, and there is a standard field for them sitting empty in almost every catalogue.

For units, unitCode takes a UN/CEFACT 3-character common code — MMT millimetre, CMT centimetre, INH inch, KGM kilogram, LBR pound. If you are unsure of a code, unitText with a plain string is valid and better than a wrong code.

Copy-paste: the JSON-LD dimension block

Drop this inside your existing Product node. It validates, it is complete, and it deliberately separates product size from carton size.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wall cabinet, 2-door, 600 mm",
  "sku": "WC-600-2D",
  "material": "Birch plywood, white melamine",
  "width":  { "@type": "QuantitativeValue", "value": 600, "unitCode": "MMT" },
  "height": { "@type": "QuantitativeValue", "value": 720, "unitCode": "MMT" },
  "depth":  { "@type": "QuantitativeValue", "value": 320, "unitCode": "MMT" },
  "weight": { "@type": "QuantitativeValue", "value": 14.2, "unitCode": "KGM" },
  "hasMeasurement": [
    { "@type": "QuantitativeValue", "name": "Internal shelf width",
      "value": 564, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Wall fixing centres",
      "value": 512, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Carton, longest side",
      "value": 760, "unitCode": "MMT" }
  ]
}

The ChatGPT feed wants the same numbers under different names

The Agentic Commerce product feed spec — the file merchants push for ChatGPT shopping surfaces — takes dimensions two ways, and the dependency rules are strict:

The spec states that physical characteristics and classification help with categorisation, filtering and search relevance — which is a plain statement that a product with no dimensions is a product that cannot be filtered into a result set. If a shopper asks for a cabinet under 350 mm deep and your depth field is empty, you are not ranked low. You are absent.

One honest gap: the spec defines no separate package-dimension field, and does not say whether dimensions means the product or its carton. Declare which one you mean somewhere a human and a model can both read it, and be consistent across your whole catalogue.

Why these fields are worth filling in even though Google won't show them

Here is the part that reads like a contradiction. Google's own Product structured data documentation, which lists what earns you a rich result, does not include width, height, depth, weight or hasMeasurement. Its supported list runs to price, availability, review ratings, shipping, return policy, apparel sizing, identifiers and pros and cons.

So dimension markup will not draw you a bigger snippet. It was never going to.

What changed is the consumer. Google says product_detail provides structured data that helps it understand and display products across surfaces including AI-driven features such as AI Mode in Search; the Agentic Commerce feed exists to make products findable and filterable inside a chat. Those systems do not need a visual template to fire — they need an attribute they can compare against a constraint. A dimension field is not decoration on a search result any more. It is the thing that qualifies you for retrieval.

Which reframes the priority: fill these in for the engines that answer questions, not for the ones that draw boxes.

The rule that breaks everything: one number, two places

Every failure mode I have seen with product dimensions structured data comes from the same root — the feed says one thing and the image says another.

It happens innocently. Someone types the carton size into shipping_width, someone else measures the assembled unit for the spec diagram, a third person rounds 564 mm to 56 cm in product_detail. Now an assistant confidently tells a shopper the cabinet is 640 mm wide, the shopper looks at your image which says 600, and you have manufactured a trust problem plus a return. Worse, the machine-read number is the one that gets quoted, because it is the one that was legible.

The fix is process, not markup: measure once, then publish that same measurement into both the field and the image. Concretely —

1. Measure the finished item, not the drawing and not the carton, and record which one each figure refers to.
2. Put each figure on the image against the feature it describes — snapped to the product's real edge, not floated near it — and export at each platform's spec-diagram size. Software built for dimension annotation does this deterministically, which is the whole difference from a general photo editor where you hand-place arrows, or from an image generator, which will happily render a dimension it never measured because plausible is what it optimises for.
3. Copy the same figures into width/height/depth, product_detail and the feed's dimension fields. Same source, same rounding, same units.
4. When a figure changes, change it in both places in the same commit. A drifted pair is worse than a missing one.

A worked example of the image half of that pairing is in this product size labels case study, and the unit question that trips up half of all exporters is covered in product dimensions in cm or inches.

Pre-publish checklist

• width, height, depth present on the Product node, each as a QuantitativeValue with unitCode or unitText
• weight present with a unit
• Every secondary dimension a buyer actually asks about is in hasMeasurement with a descriptive name
• size used only for apparel sizing systems — no 600x320x720 strings
• Feed: shipping_length / shipping_width / shipping_height all three present, same unit, and describing the carton
• Feed: assembled product dimensions in product_detail, unit inside the value, exactly two colons per entry
• Feed: no duplication of data that already has its own attribute; no price or delivery timing inside product_detail
• Agentic feed: either dimensions with its unit, or length+width+height plus dimensions_unit
• Agentic feed: weight never sent without item_weight_unit
• Product dimensions and carton dimensions are labelled distinctly everywhere they appear
• Every number in the markup matches the number printed on the spec image, to the millimetre
• One owner named for that match, so nobody edits one side alone

FAQ

How do I add product dimensions to structured data?

Put width, height, depth and weight on your Product node in JSON-LD, each as a QuantitativeValue with a numeric value and a unitCode. Add every other measurable feature as entries in hasMeasurement with a descriptive name. In a Google feed, the assembled size belongs in product_detail, not in the shipping_* fields.

Does Google use width, height and depth from Product schema?

Not for rich results. Google's supported product properties cover price, availability, reviews, shipping, return policy, apparel sizing, identifiers and pros and cons — physical dimensions are not on that list. They still matter for retrieval and comparison in AI-driven surfaces, which is a different and now larger job.

What is the difference between shipping_length and the product's actual size?

shipping_length, shipping_width and shipping_height describe the shipping package, and exist so carrier-calculated rates can be worked out. They are not the product's finished dimensions and should not be filled with them. Merchant Center has no dedicated attribute for assembled size, which is why product_detail is the correct place for it.

Which unit codes should I use for dimensions in JSON-LD?

unitCode takes a UN/CEFACT 3-character common code — MMT for millimetre, CMT centimetre, INH inch, KGM kilogram, LBR pound. If you are not certain of the code for a unit, use unitText with a plain string instead; a readable unitText beats a wrong unitCode.

Do I still need dimensions on the product image if they are in the feed?

Yes, and the reasoning is symmetrical. Machines read the fields and cannot read your image; buyers read the image and will never open your feed. Your dimension diagram is an image, and every system that decides whether your product appears in an answer reads text — so ship both, and make them agree to the millimetre. How to phrase the image half so buyers act on it is covered in communicate product dimensions to buyers; if you want the cost of getting it wrong in currency, the return cost calculator does that arithmetic.

Sources & References

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode and unitText
• Google Merchant Center — shipping dimension attributes and their limits
• Google Merchant Center — product detail [product_detail] attribute
• Google Search Central — Product structured data and supported properties
• Agentic Commerce — product feed specification