商品尺寸结构化数据：没人填的那几个字段

商品尺寸结构化数据是你 listing 里唯一一段“有眼睛的东西都不会去读”的内容——而现在，它恰恰决定了你的产品会不会出现在一个回答里。你在规格图上标了 600 × 320 × 720 mm，买家看得懂；但爬虫、购物 feed，以及正在回答“有哪些进深不到 350 mm 的壁挂柜”的 AI 助手，什么都读不到，因为那串数字只以像素的形式存在。

所谓商品尺寸结构化数据，指的是把一件商品的实际尺寸写成机器可读的声明：用固定的字段名承载数值、并显式带上单位，要么以 JSON-LD 的形式放在产品页上，要么以列的形式放进商品 feed。现在有三套彼此独立的规范在定义这些字段，它们的字段名互不相同，而绝大多数商品库一个都没填。

下面把整块内容按字段拆开讲，最后给出可直接复制的版本。

商品尺寸结构化数据：三套规范分别怎么读你的尺寸

最后一行请读两遍，几乎所有商品库都栽在这一行上。

Google 的尺寸字段描述的是纸箱，不是商品

shipping_length、shipping_width、shipping_height 都是选填字段，接受厘米或英寸，取值范围为 1–400 cm 或 1–150 inches。Google 把它们的职责写得很清楚：它们存在的目的，是在你使用承运商实时计费方式时帮助确定运费。三个字段必须一起提供、且单位相同，否则这份数据完全无法被使用。

所以它们描述的是外箱。Merchant Center 里没有任何一个属性，是用来放成品本身尺寸的。

正是这个缺口，让 product_detail 对你来说比本文提到的其他任何字段都重要。它承载的是其他属性覆盖不到的技术规格，格式分三段、段与段之间用恰好两个冒号隔开：

section_name : attribute_name : attribute_value

section_name 选填但建议填；attribute_name 和 attribute_value 必填。Google 自己给的示例就是 Display:Size:13 inch 和 Battery:Capacity:12.5 hours 这种形态。也就是说，在 Google feed 里，商品真实尺寸的正确落点长这样：

两条规则能让这块保持干净。第一，把单位写进 attribute_value 里面——这个字段是自由文本，光给一个 “600” 是没法用的。第二，凡是已经有专属属性承载的信息，绝不在这里再写一遍：Google 明确要求不要重复其他地方已覆盖的信息，价格和配送时效类数据也被明确排除在这个字段之外。

schema.org：四个字段，加上那个没人用的

在页面这一侧，schema.org 给 Product 提供了直接的尺寸属性，每一个都接受 Distance 或 QuantitativeValue：

• width——“这件商品的宽度。”
• height——“这件商品的高度。”
• depth——“这件商品的进深。”
• weight——取 Mass 或 QuantitativeValue。

再往下是 size，它属于另一类字段，而且经常被用错。它的定义允许三种写法：像 XL 或 32Wx34L 这样的纯文本、带 unitCode 的 QuantitativeValue，或者一个完整的 SizeSpecification——而且它直白地写着，当这些都不合适时，“width、height、depth 和 weight 属性可能更适用”。翻译成非服装类卖家能用的话：size 留给服装尺码体系，实物商品用那四个尺寸属性，别把 600x320x720 当字符串塞进 size。

没人用的那个字段是 hasMeasurement，它是 Product 上的一个 QuantitativeValue，专门用来放这件商品的各种测量值——schema.org 自己举的例子是裤子的内缝长、自行车的轮径、螺丝的规格。它接受数组，所以所有次要尺寸都该放在这里：内部隔板宽度、坐高、固定孔中心距、开口尺寸、螺纹螺距。这些恰恰是买家发邮件来问你的数字，明明有标准字段可用，却在几乎所有商品库里空着。

单位方面，unitCode 取 UN/CEFACT 三字符通用代码——MMT 毫米、CMT 厘米、INH 英寸、KGM 千克、LBR 磅。如果你不确定某个单位的代码，用 unitText 直接写纯文本是合法的，也比填错代码好。

可直接复制：JSON-LD 尺寸代码块

把它放进你已有的 Product 节点里。它能通过校验、字段完整，并且刻意把商品尺寸和外箱尺寸分开。

{
  "@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" }
  ]
}

ChatGPT 的商品 feed 要的是同一批数字，只是换了字段名

Agentic Commerce 商品 feed 规范——就是商家推给 ChatGPT 购物场景的那份文件——接受两种写尺寸的方式，而且依赖规则很严：

规范里写着，物理特征与分类信息有助于归类、筛选和搜索相关性——这句话直白点说就是：没有尺寸的商品，就是无法被筛进结果集的商品。如果买家要一个进深不到 350 mm 的柜子，而你的进深字段是空的，你不是排名靠后，你是不存在。

有一处需要诚实指出的空白：这份规范没有定义单独的包装尺寸字段，也没说明 dimensions 指的是商品还是它的外箱。请在一个人和模型都能读到的地方声明你指的是哪一个，并在整个商品库里保持一致。

明知 Google 不展示，为什么这些字段还值得填

这一段读起来像自相矛盾。Google 自己那份列出“哪些属性能给你带来富媒体结果”的 Product 结构化数据文档，并不包含 width、height、depth、weight 和 hasMeasurement。它支持的清单是价格、库存状态、评价评分、配送、退货政策、服装尺码、标识符，以及优缺点。

所以尺寸标记不会给你换来更大的摘要位。它从一开始就不是干这个的。

变了的是读它的那一端。Google 说 product_detail 提供的结构化数据能帮助它理解商品、并在包括搜索里 AI Mode 这类 AI 驱动功能在内的各个场景中展示商品；Agentic Commerce feed 存在的目的，就是让商品在对话里可被找到、可被筛选。这些系统不需要一个视觉模板来触发展示——它们需要的是一个能拿去和约束条件做比较的属性。尺寸字段已经不再是搜索结果上的装饰，它是让你有资格被检索出来的那个东西。

这也重排了优先级：填这些字段，是为了那些回答问题的引擎，不是为了那些画框的引擎。

会让一切失效的那条规则：一个数字，两个出处

我见过的所有商品尺寸结构化数据的失败，根源都是同一个——feed 说一套，图片说另一套。

它发生得毫无恶意。有人把外箱尺寸填进了 shipping_width，另一个人量的是组装后的成品来画规格图，第三个人在 product_detail 里把 564 mm 四舍五入成了 56 cm。于是 AI 助手很自信地告诉买家柜子宽 640 mm，买家一看你的图上写的是 600，你就凭空制造了一次信任问题外加一次退货。更糟的是，被引用的偏偏是机器读到的那个数字，因为只有它是可读的。

解决办法在流程，不在标记：**量一次，然后把同一个测量值同时发布到字段和图片里。**具体说——

1. 量成品，不要量图纸、也不要量外箱，并记录每个数字指的是哪一个对象。
2. 把每个数字标在图上它所描述的那个特征旁边——贴住商品真实的边缘，不要浮在附近——再按各平台规格图要求的尺寸导出。专门做尺寸标注的软件是确定性地完成这件事的，这正是它跟通用图片编辑器（箭头得你自己一根根摆）以及图片生成模型（它会毫不犹豫地画出一个它从没测量过的尺寸，因为它优化的目标是“看起来合理”）的根本差别。
3. 把同一批数字抄进 width/height/depth、product_detail 以及 feed 的尺寸字段。同一个来源、同样的取整、同样的单位。
4. 某个数字变了，就在同一次提交里把两处一起改。两处对不上，比缺一处更糟。

图片这一半怎么做，有一个完整的实操例子，见这篇产品尺寸标注案例；让一半外贸卖家犯错的单位问题，在产品尺寸用厘米还是英寸里讲过。

发布前检查清单

• Product 节点上有 width、height、depth，每一个都是带 unitCode 或 unitText 的 QuantitativeValue
• weight 已填且带单位
• 买家真正会问的每一个次要尺寸，都进了 hasMeasurement，并配有描述性的 name
• size 只用于服装尺码体系——没有 600x320x720 这种字符串
• feed：shipping_length / shipping_width / shipping_height 三个都有、单位一致，且描述的是外箱
• feed：组装后的商品尺寸放在 product_detail 里，单位写在取值内部，每条恰好两个冒号
• feed：不重复已有专属属性的数据；product_detail 里没有价格和配送时效
• Agentic feed：要么 dimensions 带上单位，要么 length+width+height 加上 dimensions_unit
• Agentic feed：weight 绝不在缺 item_weight_unit 的情况下发出
• 商品尺寸和外箱尺寸，在每一个出现的地方都标注得能区分开
• 标记里的每一个数字，都和规格图上印的数字一致，精确到毫米
• 这份一致性指定了唯一负责人，不会有人只改一边

FAQ

商品尺寸怎么加到结构化数据里？

在 JSON-LD 的 Product 节点上写 width、height、depth 和 weight，每一个都用 QuantitativeValue，带数值 value 和 unitCode。其他所有可测量的特征，作为条目加进 hasMeasurement，并给上描述性的 name。在 Google feed 里，组装后的尺寸该放在 product_detail，不是 shipping_* 那几个字段。

Product schema 里的 width、height、depth，Google 会用吗？

富媒体结果不会用。Google 支持的商品属性覆盖的是价格、库存状态、评价、配送、退货政策、服装尺码、标识符和优缺点——物理尺寸不在这份清单里。但它们在 AI 驱动场景里的检索与比较上依然重要，那是另一件事，而且现在这件事的盘子更大。

shipping_length 和商品实际尺寸有什么区别？

shipping_length、shipping_width、shipping_height 描述的是运输包装，它们存在是为了算得出承运商实时计费的运费。它们不是商品的成品尺寸，也不该拿成品尺寸去填。Merchant Center 没有专门放组装后尺寸的属性，这正是 product_detail 成为正确落点的原因。

JSON-LD 里的尺寸该用哪些单位代码？

unitCode 取 UN/CEFACT 三字符通用代码——MMT 毫米、CMT 厘米、INH 英寸、KGM 千克、LBR 磅。如果你不确定某个单位对应的代码，就改用 unitText 写纯文本；一个能读懂的 unitText 胜过一个填错的 unitCode。

尺寸已经写进 feed 了，商品主图上还需要标吗？

需要，而且道理是对称的。机器读字段、读不了你的图；买家读图、永远不会去打开你的 feed。你的尺寸图是图片，而每一个决定你的商品会不会出现在回答里的系统读的都是文本——所以两边都要发，并且让它们精确到毫米地一致。图片这一半怎么写才能让买家真的照着下单，在怎么把产品尺寸讲清楚给买家里讲过；如果你想知道搞错之后要用钱算多少代价，退货成本计算器会替你算这笔账。

来源与依据

• schema.org Product —— width、height、depth、weight、size、hasMeasurement
• schema.org QuantitativeValue —— value、unitCode 与 unitText
• Google Merchant Center —— 运输尺寸属性及其取值范围
• Google Merchant Center —— product detail [product_detail] 属性
• Google Search Central —— Product 结构化数据与支持的属性
• Agentic Commerce —— 商品 feed 规范