Google 隱性商品資料層：價格史、圖片索引與排查

更新 2026-10-12

電商從業者多半收過這種信：主管問為什麼商品看起來在特價、Shopping 卻仍顯示舊包裝圖、或 Google 沒問題但 Amazon 廣告卻被拒。你檢查了 feed、schema、官網，仍對不上原因——這往往是碰到 Google 的隱性商品資料層（hidden data layer）的第一個徵兆¹。

Google 不只使用你「此刻」提交的資料，還會長期累積價格、圖片與其他商品訊號，有時跨來源拼接。作者用兩個比喻：像大象一樣記得你站上曾出現過的價格與頁面；像松露豬一樣到你沒在管的 marketplace、第三方頁面覓食。SEO、PPC、開發、電商營運各管一層，稽核很少交叉，直到客訴 email 進來才發現。

目錄（12）

隱性層是什麼

隱性層是 Google 內部生成、隨時間累積的商品認知：你送 feed 說「現在 £169.99、有庫存、這張圖」，這是你的當下真相；Google 同時爬頁面、重訪 feed，建立自己的價格史，並可能參考站外仍公開的舊圖或 listing。平台之間也可能交換資料（後文述及未完全證實的 marketplace API 傳遞）。這不是陰謀，而是 Google 試圖維持「準確、持續更新」的商品圖像；缺口常來自你忘了告知變更，或Google 紀錄尚未追上。

價格追蹤：三種容易混淆的功能

許多人收到「為什麼像在特賣」的信。Google 至少有三類外觀相似、機制不同的價格功能：

1. Sale price 註解（特價徽章）：你在 feed 提交 sale_price 與 sale_price_effective_date；Google 驗證折扣介於 5%–90%，且基準價在 qualifying 期間內曾提交（英國例：過去 200 天內至少 30 天）。重點：Google 會用歷史提交驗證 base price，價格記憶比許多人意識中更活躍。
2. Price drop 註解：你無法直接控制。Google 爬頁後，把目前價與過去 60 天平均價比較，降幅夠大就自動顯示「Price drop」與「Was」參考價——你從未提交那個「Was」數字。
3. Price drop rich snippets（自然搜尋）：Offer schema 需有明確 price，而非僅 AggregateOffer 的 lowPrice／highPrice；但 SERP 上顯示的內容仍可能來自 Google 對頁面價格的歷史紀錄，而非站長在 markup 裡寫死的「Was」。

案例：從未提交 sale_price 卻出現特賣敘事

作者描述客戶在 Shopping 看到「Was £474, now £355」與 sale 類徽章，團隊確認沒有特賣活動。追查路徑：

• 主 feed 只有 £355（未含 VAT 的 ex-VAT 價），沒有 sale_price。
• Merchant Center「Information found on your site」顯示上次爬取 £426（對應 £355 inc-VAT）。
• 前台 HTML 價格區出現「Now」字樣。
• Schema 使用 AggregateOffer 的 priceSpecification 兩層：List price £395、Sale price £355——「List £395 ex-VAT」換算 inc-VAT 即 £474，與「Was」吻合。
• 三個月前的 feed 匯出顯示 price 欄曾為 £474；從未提交 sale_price，但 Google 把 schema 標籤、HTML 用語與 feed 歷史拼成特賣故事。

教訓：人會忘記改過什麼；系統會記得。非特賣期間應避免在 schema／HTML 使用 Sale、Now、Was 等暗示折扣的標籤。

這也說明為何作者強調 feed 不應是 SEO 最被忽略的系統：PPC 以為只改 price 欄位，SEO 以為 AggregateOffer 只是技術細節，前台設計師加「Now」只是 UX——三條線在 Google 端合成促銷敘事。英國 VAT 情境下，ex-VAT feed 與 inc-VAT 頁面若未在 MC 與 schema 一致聲明，「價差約 20%」常是第一條診斷線索；但本案還叠加歷史 £474 與 List／Sale 命名，不能只用 VAT 解釋全部。

圖片索引：大象不會忘舊 URL

下架商品時，各公司處理舊圖方式不同：刪檔案→404 給 Google 明確「消失」訊號；週期性清理 orphan；或 CDN 永久保留 URL（Shopify CDN 設計即如此，刪商品不等於刪圖）。Magento 媒體目錄、WooCommerce 媒體庫也常有未 purge 的舊檔。若新圖用新檔名上傳，Google 可能索引兩個 URL，未必選你以為的「現行」那張。

Google 對商品圖有獨立於 feed g:image_link 與 on-page 標記的索引與分類，結果通常不會出現在你熟悉的 feed／schema 稽核報表。作者客戶在 MC 看到錯圖，站內、feed、規則皆正常，直到從「索引」角度思考：舊 URL 仍 200，週期 purge 空窗期讓 Google 在清理前抓到舊圖並當 primary。

結構化資料顧問 Jarno van Driel 分享的案例：客戶 feed／網站／schema 都正確，暢銷品仍顯示錯圖，直到用檔名搜尋發現兩年前員工在 Amazon 手動建的 listing 仍留舊圖——高權重第三方頁面被 Google 認為重要。多數 SEO 不會先查 Amazon。

跨平台資料交換（未完全證實）

van Driel 提到業界對話：大型 marketplace 可能付費以 API 交換 feed 資料。他遇過 MC feed 與 Amazon feed 表面無關，卻因不一致同時導致 Google Ads 與 Amazon 廣告拒登——無公開文件證實此機制，屬邊緣案例，但知道可能性可省下數十小時追查。Google 2024 宣布的 Amazon MCF 整合至少證明 Google 與 Amazon 在 fulfillment 資料上有正式管道，與「商品 feed 是否互通」仍是不同問題。

卡住時怎麼查：價格層

• MC → Products → 單品 → Product details 底部「Information found on your site」：看爬蟲獨立紀錄的價格與日期，對照 feed。
• 若爬取價與 feed 差約 20%，可能是 VAT ex／inc 不一致。
• 用 MC 依 badge 類型篩選（作者提醒有時 Shopping 有徽章但篩選列表沒有該 SKU）。
• 檢 schema 與 HTML（含原始碼）是否含 Sale／Now／Was；檢當前 feed，並設計性保存歷史 feed 匯出（作者考慮用 private Git repo）。

卡住時怎麼查：圖片層

• 除 campaign 素材、feed、live 站外，在 MC 看 Google 實際存了哪些圖 URL。
• 對 URL 打 status code；用 Google Images 搜檔名，找 marketplace／遺忘頁面。
• 問營運流程：前台移除圖時是否 404？orphan 稽核誰做？跨渠道（Amazon、eBay）是否同步更新？

卡住時怎麼查：跨平台

若同時跑 Google 與 Amazon 且拒登／異常無法用單邊 feed 解釋：並列兩邊 feed 匯出，比 price、availability、title、image URL；比對最後處理時間戳；匯出時日期標記成習慣。

組織缺口：feed、schema、頁面「邪惡三位一體」

隱性層不是創造碎片化，而是疊在原本就 fragmented 的內部流程上：SEO 不登 MC、feed 被當 PPC 資產、schema 被當 SEO 資產、PPC 沒看 structured data、開發兩邊都不匯報、營運管 catalog 卻不在 channel 會議。各團隊只稽核「自己送出的那一層」，沒人擁有 Google 實際使用的合併視圖。

Google 也在推 schema 與 MC feed 的統一商品模型；Shopping Graph 宣稱逾 500 億 listing、每小時刷新逾 20 億筆，來源含 MC、Manufacturer Center、YouTube、製造商站、PDP、測試資料、評論等，並與 Knowledge Graph 交叉驗證——衝突訊號如何加權未公開。Agentic checkout 等能力要求即時、單一可信的商品真相；資料仍來自多團隊衝突來源時，自動購買的代價會更高。

作者呼應 SEO 社群近年討論：網路正在長出「第二層」資料（AI 與購物圖譜），與傳統可爬 HTML 並存；多數 SEO 仍只優化可見頁面，未追蹤 Google 內部記憶。對電商而言，這代表「AI 能見度」不是單一問題，而是 feed 層、渲染層、第三方 listing 層可能各自出錯——需要分層排查，而非只改 meta description。

若你負責修復而非預防：先固定單一 SKU 時間線（feed 匯出日期、MC crawl 日期、schema 變更 ticket、圖片 CDN URL 生命週期），再比對 Shopping 截圖與 SERP rich result。沒有時間線時，團隊容易在「現行 feed 已正確」的假象下爭論，而忽略三個月前的 £474 或兩年前的 Amazon 圖才是根因。

常見問題

• 沒送 sale_price 為什麼還有特價徽章？Price drop 註解與歷史價格記憶可自動產生；HTML／schema 含 Sale、Now、Was 等字樣也可能與舊 feed 價一起被拼成特賣敘事。
• feed 與網站都改新圖了，Shopping 為何仍舊圖？Google 可能仍索引舊圖 URL（尤其仍 200 或出現在第三方 listing）；需查 MC 存檔 URL 與 404／跨平台清理。
• SEO 為什麼要會 Merchant Center？隱性層的價格與圖片紀錄常只在 MC「站外資訊」面板可見；只稽核 on-page 看不到 Google 合併後的「真相」。
• Amazon 與 Google feed 會互相影響嗎？作者引述未證實的 marketplace API 交換與 van Driel 邊緣案例；至少應並列匯出比對，不可假設完全隔離。

編輯解讀

一句話重點：Google 對商品有獨立於你當前 feed 的價格史與圖片索引；特賣徽章與錯圖常是 multi-signal 拼裝，需 MC＋schema＋HTML＋歷史 feed 合併稽核。

這對你的網站意味著什麼：

• 建立「商品真相」單一 owner：每月 MC crawl 價 vs feed vs PDP schema 三角對照。
• 非促銷期清理 Sale／Now／Was 文案與 priceSpecification 命名。
• 下架圖片策略寫成 SOP：404 或明確替換，並查第三方 marketplace。
• feed 匯出版本化（Git 或 dated archive）。

適用與不適用的情境：適用已跑 Shopping／free listings 且多團隊分工的電商。小站可先做到 VAT 一致與圖片 404。

需要注意的限制：案例來自英國 VAT 情境；跨平台 API 交換為推測；Shopping Graph 數字引用 Google 公開宣稱。

延伸閱讀：

• 價格資訊對 SEO 的意外影響
• 商品列表與 GMC 測試
• 電商 Google SEO 專題

可沉澱規則 · 供站點自檢2 條

從本文提煉，可供人工對照或 AI 分析站點時作為依據。全部規則

1. 1 排查 Shopping 特價徽章或錯價時，須三角對照 MC「Information found on your site」爬取價、feed 提交價與 PDP schema／HTML；非促銷期避免 Sale／Now／Was 與 AggregateOffer 的 Sale 命名，並版本化 feed 匯出。

   適用 客訴「沒特賣卻顯示 Was／折扣」
   排除 不要只改現行 feed 而不看歷史 price 與 VAT ex／inc
   • MC badge 篩選與 SERP 是否一致
   • private repo 是否存 dated feed

2. 2 Google 對商品圖有獨立索引；舊 CDN URL 仍 200 或第三方 marketplace 留舊圖時，feed 更新未必改 primary 圖。下架流程須含 404 或跨渠道更新，並用 MC 存檔 URL＋Google Images 搜檔名。

   適用 Shopping 顯示過期包裝圖
   排除 不要假設改 g:image_link 即立即生效
   • orphan 圖稽核週期
   • Amazon／eBay listing 是否同步

名詞與資料來源

1. 隱性商品資料層 — Search Engine Journal：〈Google’s Hidden Data Layer〉 https://searchenginejournal.com/googles-hidden-data-layer-what-is-it-and-what-to-do-about-it/590234/（Emina Demiri-Watson，2026-10-05；檢索：2026-10-12）
2. Sale price 與 promotions — Google Merchant Center：〈Sale price and promotions〉 https://support.google.com/merchants/answer/6324470（檢索日期：2026-10-12）
3. Price drop 註解 — Google Merchant Center：〈Automated discounts and price drop labels〉 https://support.google.com/merchants/answer/7052112（檢索日期：2026-10-12）