零售品牌經常有數百個 SKU，卻只有一套通用商品敘述：同系列的不同尺寸沒有獨立規格、商品分類依活動隨時更改，官網寫「現貨」而資料 Feed 仍標示缺貨。當搜尋系統需要判斷商品屬於哪個品類、適合什麼用途，這些缺口就會影響資料的可理解性與一致性。
要改善零售商品資料，建議先建立可維護的商品主檔，讓每個商品有穩定識別碼、清楚的分類、可驗證的特色與用途，再同步到商品頁、結構化資料和適用的平台 Feed。這些工作能降低資料衝突、改善商品資訊品質，但不能保證被任何 AI 搜尋服務引用或推薦。
先拆開三種資料：商品主檔、商品頁、平台資料
同一件商品在不同系統中可能有不同用途。商品主檔是品牌內部的事實來源，記錄識別碼、材質、容量與銷售狀態；商品頁把這些資料轉換成消費者看得懂的選購資訊；平台資料則依 Merchant Center 等管道的欄位規範輸出。三者應共享核心事實，卻不必每個文字欄位完全相同。
例如商品主檔存「容量 500 mL、材質 304 不鏽鋼」，商品頁可以說明「適合日常通勤攜帶」，前提是品牌能合理支持這個情境。平台 Feed 的 title、description、availability 等欄位仍須依平台規格填寫，並與落地頁內容一致。
用一份商品資料字典，統一品類、特色與使用情境
商品欄位應分成「識別與分類」、「客觀規格」、「選購情境」、「交易狀態」四層。以下是適合電商主管與工程人員共同討論的內部資料字典建議；它不是任何平台的完整必填規範。
| 資料層 | 建議欄位 | 填寫原則 | 常見錯誤 |
|---|---|---|---|
| 識別與分類 | 商品 ID、SKU、品牌、內部分類、平台分類 | ID 穩定且唯一；內部分類與平台分類分開管理 | 同一 SKU 改名後換 ID；用促銷活動當永久品類 |
| 客觀規格 | 材質、尺寸、容量、重量、顏色、型號 | 使用統一單位與受控選項，保留原始規格依據 | 「大容量」卻沒有數值；顏色同時寫米白、奶白、象牙白 |
| 選購情境 | 適合用途、使用對象、使用限制、保養方式 | 對應可支持的特性，不把推論寫成保證 | 宣稱「適合所有膚質」「百分百防水」卻無證據 |
| 交易狀態 | 價格、幣別、庫存、商品 URL、更新時間 | 由可追蹤的系統維護，避免過期資料 | 官網改價但 Feed 未更新 |
商品分類要同時能支援消費者找商品，也能支援品牌管理商品。以寢具為例，網站導覽可以用「寢具／床包／雙人床包」；材質（純棉、天絲等）、尺寸與顏色則適合作為商品屬性或篩選條件。平台使用的 Google 商品類別與品牌自訂 product_type 是不同欄位，應根據 Merchant Center 規範映射，避免任意混用。
變體不能只靠商品名稱區分
同款商品如果有不同顏色、尺寸或容量，內部應保留「商品家族」與「可銷售變體」的關係。例如「經典保溫杯」為商品家族，黑色 500 mL 與白色 750 mL 為不同 SKU。商品頁的選項、庫存及價格應對應到實際變體，資料 Feed 也應使用適當的 item_group_id 與變體屬性。若品牌有 GTIN，應依官方規範提供正確識別碼，勿自行編造。
商品特色怎麼寫，才能對應真實的搜尋需求？
寫特色時可採用「可驗證規格 → 使用上的意義 → 情境限制」的順序。這種寫法讓經營者把產品知識整理成可檢查的欄位，也讓消費者理解購買條件。
以假設性的保溫杯商品為例：
- 客觀規格：304 不鏽鋼內膽、500 mL、旋蓋設計。
- 使用意義：容量適合日常攜帶；旋蓋的開關方式可在商品照片與操作說明中呈現。
- 情境說明：適合通勤、辦公桌使用；是否適用洗碗機、是否完全防漏，須按實測或商品規格標示。
不建議只有「高品質、必買、超人氣」等形容詞，也不應為了涵蓋搜尋詞而把「露營、育兒、辦公、運動」全部塞入每一個商品。用途必須能連回商品的實際特性與限制。
建立情境標籤的審核規則
品牌可以建立受控詞庫，例如「通勤攜帶」「小坪數收納」「親子旅行」。每個標籤都要記錄採用理由、審核人及證據位置。沒有明確依據的標籤先保留在待確認區，不直接發到商品頁。這能避免不同小編對同一系列商品做出互相矛盾的描述。
一項商品從建檔到發布：誰負責哪一段？
建議使用一張「商品資料責任表」，不要把所有欄位交由文案或工程單獨處理。
| 作業節點 | 主要負責 | 驗收方式 |
|---|---|---|
| 商品建檔與規格 | 採購／商品企劃 | SKU、型號、材質與規格有來源 |
| 分類與情境標籤 | 電商營運／行銷 | 類別一致，情境有可支持的依據 |
| 商品頁展示 | 內容／設計 | 標題、規格、圖片、選購資訊可讀 |
| 結構化資料與 Feed | 工程／電商技術 | 欄位映射正確，網站與資料來源不衝突 |
| 定期抽查 | 電商主管 | 對照庫存、售價、變體與商品 URL |
初次導入不必一次整理全部商品。可先選定一個品類，優先處理銷售重要、變體複雜、常被客服詢問規格的商品；釐清欄位後，再擴大到其他品類。
上線前，對照商品頁、Schema 與 Merchant Center
Google 官方文件說明，可購買商品的頁面可使用 Product／Offer 結構化資料，並須符合商家資訊功能的相關規範；Merchant Center 也有獨立的商品資料欄位要求。兩者可互相補充，但資料一致性是基本前提。
工程驗收時，至少檢查以下項目：
- 商品頁與標記是否相符：名稱、圖片、價格、幣別、庫存狀態與正在銷售的變體是否一致。
- 頁面類型是否正確：商家資訊的 Product 標記應用於符合資格的可購買商品頁，不是把同一組商品標記套在整個分類頁。
- 商品 Feed 是否正確：檢查 ID、title、description、image_link、link、price、availability；依商品型態處理 GTIN、品牌與變體欄位。
- 資料能否被擷取：重要商品頁可供搜尋引擎存取，圖片 URL 有效；使用 Rich Results Test 與 Search Console 對應報表檢查支援的結構化資料問題。
- 異動是否同步：商品改價、停售或換圖後，有可追蹤的更新流程；不要僅更新可見頁面卻遺漏 Feed。
要注意，結構化資料通過測試代表符合部分技術條件，不等於保證取得 Google 複合式搜尋結果，更不能推論一定會被 ChatGPT 等 AI 系統推薦。
用「資料完整度 × 一致性 × 維護責任」來驗收
為避免整理商品資料變成一次性的文案專案，可以建立一張內部抽查表，按每個 SKU 記錄：必備欄位是否齊全、描述是否有依據、變體是否正確、官網與 Feed 是否一致，以及誰負責下一次更新。
建議先把問題分類為三種：缺欄位（例如材質未填）、資料衝突（例如官網與 Feed 價格不同）、內容無依據（例如宣稱防水但缺測試條件）。缺欄位由商品企劃補齊；衝突資料交工程或電商營運查源頭；無依據的賣點則暫緩發布。這個分流方式能把抽象的「AI 搜尋優化」轉成有負責人與驗收條件的實際工作。
可以再以 Search Console 查詢商品頁的搜尋曝光與點擊，以 Merchant Center 診斷報表檢查商品資料問題，並用 GA4 觀察商品頁互動或購買流程。這些資料可評估商品資訊整理後的變化，但無法單獨證明 AI 搜尋引用的因果效果。
從一個品類開始整理，讓後續擴充有共同規格
零售品牌若計畫強化 AI 搜尋中的商品理解，第一個可執行的工作是指定一個商品主檔、統一欄位定義，以及建立網站和平台資料的同步驗收流程。完成後再依實際品類需求補充內容，不必把每項商品都寫成長篇 SEO 文章。
康思迅數位可協助零售品牌盤點商品頁資訊架構、規劃欄位對應與搜尋友善的內容呈現方式。若官網已經有大量商品，但類別與規格管理不一致，可先從一個品類的商品資料健檢開始。
官方參考資料：
