商品尺寸結構化資料：沒人填的那幾個欄位

商品尺寸結構化資料是你 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 規範