摘要
商品資料寫「有貨」，買家點進去卻無法加購；頁面顯示折扣價，到了結帳才發現價格不同。這種落差不只是搜尋資料問題，還會讓客服、商品營運與網站工程師各看一份不同的數字。
解法是挑一個具體 SKU 和購買情境，沿著商品 feed、可見頁面、結構化資料、購物車及結帳逐站核對。先找出哪一站開始分歧，再修資料來源與更新順序。
核心結論：同一個可購買品項，要有同一套事實
Google 的 Merchant Center 商品資料規格要求提交的價格與幣別對得上落地頁、結構化資料和結帳；庫存狀態也要與落地頁、結帳及結構化資料相符。這是 Google 商品資料及購物呈現的要求，不能推定符合後就會被收錄、出現在 AI 答案或完成購買。
| 核對站點 | 價格與幣別 | 庫存與可購買狀態 | 留存證據 |
|---|---|---|---|
| 商品 feed | id／SKU、price、適用促銷價與幣別 | availability、資料更新時間 | 匯出一筆原始資料與更新批次 |
| 商品頁可見內容 | 買家實際看到的價格、幣別與促銷條件 | 缺貨訊息、數量選擇、購買按鈕 | 手機與桌機截圖、商品 URL |
| Product／Offer 標記 | price、priceCurrency | availability、對應商品 URL | 抓取頁面標記與驗證結果 |
| 購物車 | 加入的 SKU、單價、折扣條件 | 能否加入、數量是否受限 | 購物車截圖或測試紀錄 |
| 結帳 | 實際應付商品價格與幣別 | 是否仍能完成該品項購買 | 到付款前的測試紀錄 |
五站不必儲存完全相同的資料格式，但要指向同一個可買的品項與清楚可解釋的價格。運費、稅費與配送限制另有條件；不能把結帳總額直接當成商品單價比較。
先固定對帳的 SKU、地區和時間
若只說「這款包包價格不對」，團隊很難重現。請先記下：商品 ID、變體 SKU、顏色或尺寸、目標國家與幣別、是否登入會員、促銷碼是否套用、檢查時間及商品 URL。若特定變體 URL 開啟後未選到同一款，先依商品變體連結檢查表修入口，再做跨系統對帳。
建議挑三筆代表品項：一般售價且有貨、正在促銷、有庫存邊界或剛售完。每筆用同一個測試身份與配送地區走完五站，避免把會員價、區域價或不同時間的快取誤判成單一錯誤。
十五分鐘五站對帳流程
1. 讀商品資料的原始值
先從商品資料來源或 Merchant Center 匯出該 id 的 price、sale_price、availability、link 和最後更新時間。不要只看管理後台的商品主檔：提交給平台的 feed 可能晚一批，或由另一套促銷規則覆蓋。若同一商品有多個顏色尺寸，確定比較的是同一個 SKU。
2. 以買家身份打開商品連結
從 feed 的 link 直接開頁，記錄實際可見的售價、幣別、促銷條件與庫存訊息。手機、無痕視窗和已登入會員視窗至少各檢查一種；若價格不同，先確認是不是刻意設計的會員或地區價格。Google 的商品資料規格也要求可購買價格與提交資料一致，特殊價格方案需依該規格另行設定。
3. 對照頁面的 Product／Offer 標記
檢查這個 URL 的 Product／Offer 是否描述同一品項、價格、幣別及可售狀態。Google 的商品結構化資料文件說明商品資料可支援購物相關呈現，但標記通過測試不等於買家畫面正確。尤其頁面用 JavaScript 更新價格時，要檢查初始 HTML、渲染後畫面與標記是否採用同一筆資料。
4. 加購並核對購物車
確認加入的 SKU、數量、單價和折扣與商品頁一致。缺貨品項若仍可加購，要釐清是允許預購、保留庫存時間，還是前端及後端狀態不同步。請保留伺服器回應與購物車紀錄供工程師追查，不能只改按鈕上的「有貨」文字。
5. 走到付款前核對結帳
檢查商品單價、折扣、幣別和是否仍可下單；再分開看運費、稅費與服務費。遇到價格變動，清楚告知買家並讓他重新確認，避免在付款前悄悄換價。測試可停在付款前，不需建立真實訂單。
出錯時先判斷哪一站是第一個分歧
| 症狀 | 優先檢查 | 修復後回測 |
|---|---|---|
| feed 是舊價，頁面和結帳已是新價 | 匯出排程、促銷生效時間、商品資料覆寫 | 再匯出同 SKU，核對 price／sale_price 與目標地區 |
| 頁面是新價，Offer 標記仍是舊價 | 模板、快取、前後端共用資料來源 | 抓取初始 HTML 與渲染後標記 |
| 頁面有貨，購物車拒絕加購 | 庫存保留、倉別、SKU 映射與 API 回應 | 重新進站、加購、移除、再加購 |
| 加購成功，結帳變價或無貨 | 促銷條件、幣別轉換、付款前庫存重查 | 分一般／會員／促銷情境走到付款前 |
把修復紀錄寫成「哪個 SKU、哪個地區、哪個時間、哪一站開始錯」，比籠統寫「同步失敗」更容易讓資料、網站與營運團隊找到共同原因。若庫存快速變動，可縮短同步間隔並設異常告警；仍需讓結帳端以當下可售狀態做最後確認。
常見問題
Product／Offer 驗證通過，是否代表價格沒問題？
不是。驗證只確認標記格式與部分欄位，仍須與買家畫面、feed、購物車及結帳比較同一 SKU 的實際價格與庫存。
促銷價與原價應怎麼比？
先確認促銷的開始與結束時間、地區、會員資格和折扣條件。Google 商品資料規格區分一般 price 與 sale_price；提交的促銷價仍須與落地頁和結帳相符。不要把只對特定會員有效的價格當成所有買家可用的公開售價。
商品資料寫有貨，但結帳時剛好賣完怎麼辦？
高周轉品項可能在兩次更新之間售完。應檢查 feed 更新延遲、頁面快取、購物車保留與結帳即時庫存重查，並讓買家看到清楚的缺貨或替代選擇。不能因為 feed 來不及更新就讓結帳接受不可履行的訂單。
做完對帳就會被 AI 搜尋推薦嗎？
不能推定。本文引用的是 Google 商品資料與商品標記文件，目標是讓商品資訊可信且購買流程一致；其他搜尋與 AI 服務的抓取、展示與引用規則不由這份檢查表決定。
參考來源與資料時間
以下 Google 第一方文件於 2026-10-14 查核。本文的五站對帳表是 FlyPig AI 的營運驗收方法；實際稅費、會員價、促銷和目標地區要求請依當時官方規格與商店設定重新核對。
- Google Merchant Center：商品資料規格：價格、幣別、促銷價與庫存須與落地頁、結帳及結構化資料一致。
- Google Search Central：商品結構化資料：
Product與Offer的商品資訊及 Google 搜尋可能呈現的方式。
下一步
今天選一個主力 SKU、一個促銷 SKU 和一個剛缺貨 SKU，請商品營運、網站與客服共同填完五站對帳表。先修會讓買家看到錯價或下到錯單的分歧，再調整 feed 與標記更新節奏。需要把商品頁放回整體搜尋與購買路徑時，可從行銷與轉換主題導覽繼續檢查。