商品結構化資料怎麼做：讓頁面、標記和 Merchant Center 的價格與庫存保持一致

商品結構化資料（Product structured data，用 schema.org 詞彙把商品名稱、價格、庫存、運費、退貨政策寫成機器讀得懂的格式）在電商圈談了很多年，最近又被拿出來討論，原因是 AI 搜尋。很多品牌以為要為 AI 準備一套新的標記，Google 的官方說法剛好相反。

Google 說 AI 搜尋沒有專用標記，那商品頁要準備什麼

Google Search Central 的〈AI features and your website〉（2025 年 12 月更新）寫得很直接：出現在 AI Overviews 或 AI Mode 沒有額外的技術要求，不需要新的機器可讀檔案、AI 專用文字檔，也沒有特別要加的 schema.org 結構化資料。

同一頁的 SEO 基本功清單裡，有兩條特別值得電商注意：確認結構化資料與頁面上看得到的文字一致，以及確認 Merchant Center 的資訊是最新的。

這兩條放在一起讀，方向就很清楚：AI 搜尋沒有新增一份考卷，頁面、標記、商品資料彼此對不對得上，仍是那份舊考卷裡的題目。對電商來說，商品結構化資料的重點從「有沒有加」移到「三個地方講的價格和庫存是不是同一個數字」。

檔期第一天，商品頁同時出現三個價格

我們整理這幾份官方文件時，腦中一直浮現一個電商很熟悉的畫面（以下數字為示意）：檔期開跑當天早上，頁面上的價格已經改成 1,280 元，打開原始碼，結構化資料裡還寫著原價 1,580 元，Merchant Center 裡的商品資料則停在前一晚上傳的 1,480 元。

三個數字各有來由：行銷改了頁面、工程的標記沒跟上、商品資料排程還沒跑。尷尬的是，讀這個頁面的機器不知道哪一個才算數；若顧客在搜尋結果看到的價格比點進來的低，就會覺得被騙。

這件小事不需要新工具，需要的是讓同一個商品的事實，只從一個地方產生。

同一個商品的價格，同時寫在頁面、標記和商品資料裡

商品頁的關鍵事實（價格、庫存、運費、退貨）至少寫在三個位置，各有不同的讀者：

Google 的 Product 結構化資料說明（2025 年 12 月更新）把商品標記分成兩類：

1. 商品摘要（product snippets）：給不能直接購買的頁面，例如評測文，重點在評分與優缺點，價格可用 Offer 或 AggregateOffer 表示。
2. 商家資訊（merchant listings）：給顧客可以直接下單的商品頁，可以帶更細的資訊，例如服飾尺寸、運送細節與退貨政策。

同一份文件也說，結構化資料與 Merchant Center 商品資料兩者都提供，可以讓商品符合最多種呈現方式，也幫助 Google 核對資料；部分體驗會合併兩邊，例如頁面標記沒寫價格時，商品摘要可能直接用商品資料裡的價格。

這句「核對」是關鍵。資料不一致時，Google 可能用頁面資料修正部分屬性、拒登商品，或不採用部分標記，實際結果依功能與帳戶設定而異，哪一種都不由品牌決定。

官方文件怎麼處理互相矛盾的商品資料

自動更新會用頁面價格修正上傳資料，但只救偶發錯誤

Merchant Center 的自動更新商品功能說明（2026 年 10 月查閱）寫明，Google 可以用網站上的結構化資料與其他頁面資料，自動更新購物廣告與免費商品資訊裡的價格、特價、庫存狀態與商品狀況。文件舉的例子是：上傳的商品資料寫 4 美元，商品頁寫 3 美元，Google 會把商品更新成 3 美元。

同一份說明也劃了界線：自動更新是為少數商品的偶發錯誤設計，不能取代定期更新商品資料；價格或庫存一天變動超過一次的商品，自動更新可能失效，偵測到不一致時商品也可能直接被拒登，不一致太多時 Google 還可能停止更新。常改價的品牌，文件建議改用 Merchant API 管理商品更新。頁面與上傳資料不一致時，品牌上傳的那一份不一定會被採用，也可能兩份都沒被用上。

退貨政策有明確的優先順序

Google 的退貨政策結構化資料文件（2026 年 9 月更新）建議，把適用全店的退貨政策寫在 Organization（組織）層級，只有個別商品例外時，才在該商品的 Offer 底下另外標記。

文件也列出 Google 採用退貨資訊的優先順序，由強到弱是：Content API for Shopping 的退貨設定、Merchant Center 或 Search Console 裡的設定、商品層級標記、組織層級標記。同時在網站標記與 Search Console 設定退貨政策時，Google 只採用 Search Console 那一份。

所以退貨政策要先決定由哪裡維護。兩邊都寫、條件卻不同（示意：網站標記 7 天、Merchant Center 設定 14 天），依這個順序採用的會是 Merchant Center 那一份。

AI 購物的商品資料規格，對缺漏一樣不寬容

這套邏輯不只出現在 Google。截至 2026 年 10 月，OpenAI 的 ChatGPT 商品資料上架仍只開放給核准合作夥伴，台灣品牌未必能直接提交，但規格很適合當資料整理的參考。OpenAI 的 Agentic Commerce 商品資料規格列出九個必填欄位，其中庫存狀態是必填，沒填、空白或填了無法辨識的值，那一筆商品會被整列退回；不知道庫存時要明確填 unknown，不能用 null、n/a 這類占位字。規格也提醒，標題要精簡、描述用純文字，商品可被搜尋也不保證會被顯示，特價開始或結束時要更新資料。

不同平台、同一個方向：機器讀者要完整、即時、和頁面一致的商品事實。

為什麼「一致」比「完整」更早被檢查

機器讀者沒辦法打電話問客服

資料互相矛盾時，機器讀者沒有人可以問。顧客看到價格不一致，可以問客服、可以加入購物車確認；Google 與 AI 購物服務只能依規則修正、擇一採用或乾脆不用。Google 的結構化資料一般規範（2026 年 7 月更新）明列：不要標記讀者在頁面上看不到的內容，也不要用結構化資料誤導使用者。

違反規範的後果，文件也講清楚：結構化資料的人工處置會讓頁面失去複合式搜尋結果的資格，但不影響一般網頁搜尋排名；同時 Google 也不保證標記正確就一定會顯示。可能失去的，是商品在搜尋結果裡顯示價格、評分、運費的機會。

用前端腳本補標記，價格可能跟不上

價格和庫存的標記，最好跟頁面一起由伺服器端輸出。不少電商用 Google Tag Manager 或前端 JavaScript 在頁面載入後才產生 JSON-LD，因為不必動網站程式。Google 的 JavaScript 產生結構化資料說明（2025 年 12 月更新）特別提醒：商品標記用動態產生，可能讓購物相關的檢索變得較不頻繁、也較不可靠，對價格和庫存這類變動快的內容會是問題。

價格要分清楚「現在賣多少」和「原本賣多少」

Google 商家資訊結構化資料文件（2026 年 9 月更新）列出三種價格：目前售價、劃線原價與會員價。商家資訊的必填欄位是商品名稱、圖片與含價格的 Offer，而且必須是 Offer，因為商家本身要是賣家。

做特價時，正確寫法是把目前的售價放在 price，另外再提供一個標成劃線價（StrikethroughPrice）的原價，目前售價本身不要加價格類型標記。把原價放在 price、特價只寫在畫面上，等於告訴機器商品還在賣原價；會員價也要和頁面上的說法一致。

每一個價格都要有明確身分，身分不清的價格，機器只能自己猜。標記做對之後，頁面在 AI 回答裡有沒有被引用、引用後有沒有帶來生意，是另一道題，可以參考〈AI 搜尋能見度怎麼量？曝光不等於被引用，被引用不等於有生意〉；被引用之後能不能被挑中，則在〈當 AI 替顧客決定：AI 成為新貨架，品牌要怎麼被選中〉有更完整的討論。

顧客從 AI 搜尋與購物頁進站之後，資料要接得住

商品事實要一致，顧客資料也要一致。商品頁標記處理的是讓機器看得懂、信得過；顧客點進來之後，品牌要回答的是這個人是誰、從哪裡來、看過哪些商品、最後有沒有買。進站來源記在流量工具、瀏覽紀錄在網站後台、購買在訂單系統、門市消費在 POS，四份資料對不起來，品牌就說不清楚 AI 搜尋與購物頁帶來的到底是新客、老客，還是本來就會買的人。

91APP CDMP 的做法是把這些第一方數據整合進同一個會員輪廓，讓進站來源可以和瀏覽過的商品、購買紀錄、線上線下消費放在一起看。我們在〈Google AI Mode 如何改寫電商流量規則〉提過，把「AI 搜尋進站」當成會員標籤，是品牌觀察這批流量品質的起點。

商品主檔也是同一回事：商品屬性欄位不完整，站內推薦也會跟著不準，對外的結構化資料只是同一份主檔的另一個出口。

商品頁標記上線前，照這個順序檢查

1. 先分清楚頁面類型，再選標記：可以直接下單的商品頁用商家資訊（merchant listings），評測、比較、選購指南這類不能直接買的頁面用商品摘要（product snippets）；有尺寸、顏色等變體的商品，確認每個變體的網址、編號與價格指向同一個版本。（預期效果：避免把不能下單的頁面標成商家資訊，或在商品頁漏掉運費與退貨資訊；建議週期：新版型上線前一次盤點。）
2. 讓價格與庫存只從一個來源輸出：頁面顯示、JSON-LD 與商品資料的價格、特價、庫存，都從同一份商品主檔產生。行銷端可以向工程團隊確認兩點：結構化資料是否由伺服器端直接輸出、而非靠 Tag Manager 事後補；一天改價多次的檔期，商品資料是否提高更新頻率或改走 Merchant API。（預期效果：檔期改價時三處同步，減少拒登或標記失效；建議週期：每次檔期前抽查熱賣品。）
3. 特價與會員價照規則標：目前售價放 price，原價用劃線價類型另外標，會員價要和頁面上的會員價說法一致；貨幣寫 TWD。（預期效果：搜尋結果顯示的價格與顧客點進來看到的一致；建議週期：檔期規則確定後、開跑前。）
4. 退貨與運送政策先決定由哪裡維護：全店通用的退貨政策寫在組織層級，或統一在 Merchant Center／Search Console 設定，只選一個主要來源，個別例外商品才在 Offer 底下覆寫。退貨條件改版時，也順便對照退貨原因分析裡最常出現的爭議，把頁面說明寫清楚。（預期效果：搜尋結果與商品頁的退貨天數、運費說法一致；建議週期：政策異動時。）
5. 用官方工具驗證，再看報表追蹤：上線前用複合式搜尋結果測試（Rich Results Test）與網址檢查工具確認 Googlebot 讀到的標記，上線後追 Search Console 的商家資訊報表與 Merchant Center 的商品診斷，錯誤優先修，警告依商業影響排入補強。（預期效果：在流量受影響前抓到失效頁面；建議週期：每月一次，檔期前加一次。）

這五步都不必為 AI 另外寫東西，只是把既有的商品事實整理成同一個版本。

結語：讓機器讀到的價格，就是顧客付的價格

回到檔期第一天那個畫面：頁面 1,280、標記 1,580、商品資料 1,480。三個數字各自都沒錯，合在一起就成了問題。

AI 搜尋與 AI 購物把「誰的資料比較可信」這件事放大了。商品頁不必為 AI 準備特別的稿子，只要確定機器讀到的價格、庫存與退貨條件，就是顧客結帳時看到的那一份。

這件事做起來不起眼，卻決定了品牌被機器讀到的那一刻，自己的資料會不會互相打架。

品牌最常問的商品結構化資料問題

Q1：商品結構化資料是什麼？

A1：商品結構化資料是用 schema.org 的 Product、Offer 等詞彙，把商品名稱、圖片、價格、庫存、運費與退貨政策寫成機器讀得懂的格式，通常以 JSON-LD 放在商品頁原始碼裡，讓頁面有機會在 Google 搜尋結果呈現價格、庫存與評分等資訊，實際是否顯示由 Google 決定。

Q2：為了 AI Overviews 或 AI Mode，需要另外加 AI 專用的標記嗎？

A2：不需要。Google 官方文件說明，AI Overviews 與 AI Mode 沒有額外技術要求或特別的 schema.org 標記，建議的是基本功：結構化資料與頁面文字一致、Merchant Center 資訊保持最新。

Q3：已經有 Merchant Center 商品資料，網站還需要加結構化資料嗎？

A3：建議兩者都做。Google 表示兩者同時提供，能讓商品符合最多種呈現方式，也幫助 Google 核對資料。前提是兩邊的價格、庫存與退貨條件一致，否則可能被自動更新修正，或被拒登。

Q4：用 Google Tag Manager 產生商品標記可以嗎？

A4：技術上可以，但不建議用在價格與庫存。Google 提醒，動態產生的商品標記可能讓購物相關檢索較不頻繁、較不可靠，常改價的品牌最好由伺服器端輸出。

Q5：小品牌沒有工程人力，要從哪裡開始？

A5：先挑營收前段的熱賣商品頁，用複合式搜尋結果測試看標記是否存在、價格是否和頁面一致，再檢查退貨政策是否統一在一個地方維護。先把少數重要商品頁做對，再逐步擴到全站。

Q6：結構化資料寫錯會影響排名嗎？

A6：依 Google 一般規範，結構化資料違規的人工處置會讓頁面失去複合式搜尋結果資格，但不影響一般網頁搜尋排名。Google 也不保證標記正確就一定顯示。對電商可能的損失，是搜尋結果裡少了價格、評分與運費等資訊。

延伸閱讀

1. 當 AI 幫顧客比價，忠誠度還值錢嗎：品牌信任的新訊號
2. 商品轉換率怎麼算、怎麼用？流量進來不買，先把商品頁分成該推、該修、該下架
3. Google Search Console 生成式AI 成效報告：曝光、點擊、成交，品牌只拿到曝光看不到轉換

想討論商品頁、商品資料與會員資料怎麼對齊，歡迎透過 91APP 官網與我們聯繫。