商品變體 SEO 不是把每個顏色、尺寸都硬塞成獨立關鍵字頁，而是先讓搜尋引擎、購物結果與 AI 摘要看懂「哪些頁面是同一個商品的不同版本」。台灣電商可以用三個層次處理：每個可購買變體要有可直接開啟的狀態與唯一 ID；頁面上的 Product 與 ProductGroup 結構化資料要描述父商品與變體；Merchant Center feed 的 item_group_id 要和網站邏輯一致。這樣做的目標是減少重複內容、避免價格庫存訊號分裂，並讓顏色、尺寸、材質等差異更容易被搜尋和 AI 正確引用。
商品變體 SEO 先判斷：單頁商品，還是多頁變體？
第一個決策不是先寫 JSON-LD，而是先決定網址策略。Google 的電商 URL 指南說，當商品有尺寸或顏色等變體時，應讓每個變體能被獨立 URL 識別，常見做法包含路徑片段或查詢參數；同一份文件也提醒內部連結、sitemap 與 canonical 要使用一致 URL。參考：Google ecommerce URL structure。
對多數台灣中小型 Shopify、WooCommerce 或自架電商來說，若同一頁可以用選項切換顏色尺寸，仍要確認網址能預選正確變體，例如打開紅色 M 號網址時，頁面就顯示紅色 M 號的圖片、價格、庫存與加入購物車狀態。若平台把所有變體都藏在前端狀態，搜尋引擎和商品資料抓取系統可能只看到父商品，而不是可購買的具體 SKU。
| 情境 | 建議做法 | 風險 |
|---|---|---|
| 只有顏色或尺寸差異，內容幾乎相同 | 使用一個主要商品頁，讓變體可用參數或選項預選，canonical 指向一致主 URL | 若變體沒有可開啟狀態，Google 可能難以理解庫存與價格差異 |
| 每個變體有不同搜尋需求，例如材質、規格、用途差很多 | 可使用多個可索引變體頁，但每頁要有自我完備內容、唯一 SKU、正確內部連結 | 若只是複製文案，會造成重複頁與權重分散 |
| 同時投放 Merchant Center 或免費產品刊登 | 網站 ProductGroup、Product 與 feed item_group_id 要對齊 | 資料不一致時，搜尋結果、購物結果與廣告學習訊號可能各自分裂 |
ProductGroup 結構化資料要描述父商品與每個變體
Google 的 Product Variant structured data 文件建議使用 Schema.org 的 ProductGroup，搭配 variesBy、hasVariant、productGroupID 等屬性，幫助 Google 理解哪些 Product 是同一個父商品的變體。這不是取代 Product 結構化資料，而是在 Product 之外補上變體群組關係。參考：Google Product variant structured data 與 Google Product structured data。
實作時，ProductGroup 放共享資訊，例如品牌、通用描述、父 SKU、共同評價；每個 Product 放變體資訊，例如顏色、尺寸、SKU、GTIN、價格、庫存與該變體 URL。Schema.org 對 ProductGroup 的定義也強調，它代表一組只在尺寸、顏色、材質等清楚維度上不同的 Product；ProductGroup 本身通常不是直接販售對象，真正可購買的是各個變體 Product。參考：Schema.org ProductGroup。
單頁與多頁的差別
如果你的商品是單頁切換變體，Google 文件要求整個 ProductGroup 只能有一個 distinct canonical URL，通常是沒有預選變體的基礎商品頁。如果是多頁變體，Google 文件說每個頁面都要有完整且自我完備的標記，不能只在一頁定義 ProductGroup，然後期待其他頁面跨頁引用就能被完整理解。這一點對台灣電商很重要，因為很多系統會把共用資料放在父商品，但變體頁的 HTML 只輸出一小段前端資料。
Merchant Center 的 item_group_id 要和網站父 SKU 對齊
若你有上傳 Merchant Center feed，變體資料還要和網站上的 ProductGroup 對齊。Google Merchant Center 說 item_group_id 用來群組不同版本的同一商品，並建議同一組變體使用相同 item_group_id、每個變體仍要有自己的唯一 ID；同時不要把父 SKU 當成另一個可購買商品提交。參考：Merchant Center item group ID 與 Merchant Center product data specification。
實務上，可以建立一張「父商品與變體對照表」：父 SKU 對應 productGroupID 和 item_group_id；變體 SKU 對應 URL、顏色、尺寸、價格、庫存、圖片、GTIN。這張表不只是給工程師，也要給營運、廣告投手、商品 PM 使用。當價格、庫存、圖片或命名規則改變時，所有系統都用同一張表檢查，才不會網站說紅色 M 號有貨，feed 卻送出藍色 L 號的圖片。
台灣電商上線前檢查清單
1. 每個可購買變體都有可直接開啟的狀態
打開變體 URL 時，頁面應預選正確顏色、尺寸或材質，並顯示該變體的圖片、價格、庫存與購買按鈕。Google Product Variant 文件也提到，站點必須能用不同 URL 直接預選各變體，讓 Google 可以抓取並辨識各版本。
2. canonical 不要和商業需求打架
若變體只是同頁選項，canonical 可以集中在父商品主 URL；若某些變體本身有明確搜尋需求，例如「防水黑色後背包」和「兒童粉色後背包」的受眾、圖片、文案、價格都不同，就不要只靠 canonical 把所有頁面壓回父頁。先判斷變體是否有獨立內容與搜尋價值，再決定索引策略。
3. 結構化資料放在初始 HTML 更穩
Google 文件提醒，如果 Product markup 由 JavaScript 動態產生，購物相關爬取可能較不穩定，尤其價格和庫存這類快速變動資訊。對中小企業來說，最務實的做法是讓商品名稱、價格、availability、SKU、圖片、ProductGroup 關係在伺服器輸出的 HTML 或可穩定渲染的內容中出現。
4. 用 Rich Results Test 與 Search Console 監控
Google 在 Product Variant 支援公告中提到，Search Console 的 Product snippets、Merchant listings 報告與 Rich Results Test 已加入變體相關驗證。上線前先測一個父商品和兩個變體；上線後看 Search Console 是否出現無法剖析、缺少必要欄位、SKU 不唯一或 merchant listing 不合格。參考：Google Search Central product variants announcement。
適用對象與不適用情境
這套做法適合有顏色、尺寸、材質、款式、容量、包裝數等變體的台灣電商，特別是服飾、鞋包、居家用品、3C 配件、美妝保養與食品禮盒。若你只有少量商品、沒有 Merchant Center、變體不影響價格庫存，也可以先只整理 URL 與 Product 基礎結構化資料，不必一次把所有 ProductGroup 細節做滿。
不適用的情境包括：客製化商品有大量不可枚舉組合、每個組合都沒有固定 SKU、或平台無法讓變體 URL 預選正確狀態。這時應先處理商品資料架構與前端狀態，不要只把 JSON-LD 補上去；結構化資料必須反映頁面實際內容，否則可能被忽略，甚至引發結構化資料品質問題。
資料更新與適用限制
本文依據 2026-05-10 可查的官方文件整理，重點來源包含 Google 的 Product Variant structured data、ecommerce URL structure、Product structured data、Merchant Center 的 item_group_id 說明，以及 Schema.org ProductGroup。這些文件可能更新欄位要求、支援國家或 Search Console 報告名稱；正式上線前，請用你自己的商品頁、目標國家、feed 狀態與 Search Console 報告再次驗證。
結論
商品變體 SEO 的本質，是把「人看得到的商品選項」變成搜尋引擎、購物系統與 AI 摘要也能理解的資料關係。先決定單頁或多頁策略，再統一 URL、canonical、ProductGroup、Product、SKU、item_group_id、圖片與庫存。做完這些基礎後，長尾搜尋、購物結果、站內營運和 AI 引用才有一致的證據可以使用。
FAQ
商品變體 SEO 一定要做 ProductGroup 嗎？
如果商品有多個顏色、尺寸、材質或款式，而且你希望搜尋和購物結果理解它們屬於同一父商品，ProductGroup 會比只放多個 Product 更清楚。若商品量很少，可先處理 URL、唯一 SKU、Product 基礎欄位。
所有變體都需要獨立網址嗎？
Google 建議每個變體能被獨立 URL 識別，常見做法是路徑或查詢參數。重點不是每個變體都要索引，而是打開該 URL 時能預選正確變體並呈現對應價格、圖片與庫存。
變體頁 canonical 應該指向父商品頁嗎？
如果變體只是同一頁的顏色尺寸選項，canonical 通常集中到父商品主 URL。若某個變體有獨立內容、需求和商業價值，就要評估是否讓它成為自我引用 canonical 的可索引頁。
item_group_id 和 productGroupID 可以不同嗎？
技術上它們屬於不同系統欄位，但營運上最好用同一個穩定父 SKU 邏輯管理。這能降低網站結構化資料、商品 feed、廣告與庫存系統對不上號的風險。
商品變體結構化資料上線後要看哪裡？
先用 Rich Results Test 測父商品與代表性變體，再到 Search Console 的 Product snippets、Merchant listings 或無法剖析結構化資料報告追蹤錯誤；有 feed 的店家也要同步檢查 Merchant Center 診斷。