先判斷標記描述的是甚麼頁面
產品結構化資料是把商品頁內容整理成機器可讀的描述。Google 把顧客可直接購買的頁面與不能直接購買、例如獨立評測的頁面分為不同類型,前者偏向商家商品資訊,後者偏向產品摘要。因此要先決定頁面用途,才選標記範本。列出多種不相關商品的分類頁並非單一商品詳情頁,評測文章亦不應假稱有本店的即時銷售要約。實際目標是準確描述頁面已提供的資料;搜尋結果可能顯示更豐富內容,但不能承諾一定出現或帶來流量。
每個詳情頁應先確定一個清楚的商品及銷售身分。可見商品名稱、照片、規格、售價和購買操作,應與結構化資料描述同一件貨品。若不同顏色或尺碼的存貨不同,一個沒有說明範圍的 InStock 可能誤導。應先決定規格共用一頁,還是各有網址,再依相應的產品變體指引處理。不能把示例 JSON-LD 複製到所有頁面,只換標題便算完成;範本必須從商品展示及結帳實際使用的資料取得正確規格與要約欄位。
讓標記連接實際銷售資料
若頁面可直接購買,應依商家商品資訊文件選用支援的 Product 及 Offer 欄位。Google 對資格設有必要資料,包括商品名稱,以及要約的價格和貨幣等;其他欄位是建議資料,不能一概視為必填。推出前要讀取當時的欄位表,因要求與支援情況可能更新。標記應從產生可見商品頁的同一份伺服器商品紀錄取得內容。若用 HKD 280 作內部測試價,這只是示例,並非某件真貨的報價;該測試商品的可見售價、Offer 現行價格及結帳金額都應一致。
價格欄位要有明確意思。現行價格應是買家目前可就指定要約支付的商品價格;若運費或有條件折扣另計,頁面要清楚說明。刪線參考價是另一項商業聲稱,須在頁面有真實根據,不能為了令搜尋結果好看而捏造舊價。會員價、推廣期及多貨幣銷售涉及更多模型與可見條件;如公司無法持續同步,先做好普通現價要約。貨幣代碼本身是數字的必要語境,單寫 280 而沒有正確的 HKD、USD 或其他代碼,對海外讀者與搜尋系統都不夠清晰。
把庫存視為會變的狀態
庫存狀態應像價格一樣嚴謹。若頁面寫售罄而標記仍是 InStock,即使語法測試通過或剛提交網站地圖,也不能令聲稱變真。先決定甚麼事件改變公開狀態:保留庫存、付款完成、人手調整,還是供應商確認;再找出事件發生後,哪些快取仍保存舊 HTML 或 JSON-LD。商品很少的網店可以安排人手定期核對;庫存變化頻密時,標記應從目前的庫存紀錄產生。不論方法,預購與後補貨等例外都要有人負責定義及更新。
可以用普通庫存變更演練:網店只餘一件商品,頁面與標記同時顯示 InStock;最後一件被保留後,商品資料庫轉為 OutOfStock。店面或許立即更新,但靜態快取仍可能提供昨天的 JSON-LD。操作員以未登入身分讀取公開頁面,同時檢查可見購買按鈕與標記,按網站既定方法更新過時快取,再重測。這是示範流程,不代表任何搜尋爬蟲已重新抓取;爬蟲稍後實際看見甚麼,仍要另行確認。
同時檢查資格與實際頁面
可用 Google 的複合式搜尋結果測試檢查代表性網址或程式碼,找出缺少的必要欄位與格式錯誤。先修正錯誤;警告則按公司真正擁有的資料評估,不能為消除警告而虛構評分、運送承諾或退貨條款。部署後,使用 Search Console 的網址審查工具,確認 Google 如何讀取公開頁面。測試有效只代表該情境下標記可被理解,並不等於已編入索引、一定出現豐富結果或排名上升。亦應確認 robots 設定、登入限制及標準網址選擇,沒有擋住預期的商品頁。
要檢查網站實際輸出,而非只看範本檔案。有些網站在初始 HTML 送出後才由 JavaScript 組合 JSON-LD;延遲渲染或過時的客戶端資料,會令經常改變的價格和庫存更難讓爬蟲可靠取得。Google 對商家建議在初始 HTML 提供資料,以配合較廣泛的購物情境。實際問題是爬蟲收到的公開回應是否包含目前要約。如有相關商品,至少測試普通商品、售罄商品,以及一個規格或促銷例子,並在同一網址與時間比較可見內容、標記及結帳。記下網址與測試時間,方便日後調查差異。
推出後指定資料負責人
推出當日的測試結果,會隨商品資料變更而失去代表性。應把標記列入日常上架流程:新商品要有正確身分及圖片;改價要同步頁面、標記和商品資料摘要;停售商品要更新可用狀態,並有意識地處理網址。若公司同時使用 Merchant Center,應對照資料摘要與網站,調查不一致之處,不要假定其中一份永遠正確。Google 說明標記與資料摘要可以配合,但兩者也各自可能保留過時資訊。公司應指定一個業務資料來源,寫明每個公開渠道如何從它更新。
對影響顧客決策的變更,保留簡短證據紀錄:商品網址、測試日期、可見價格及貨幣、可見庫存、對應標記數值、結帳結果和快取更新。日後有人反映搜尋結果顯示舊資料,便較容易調查,而不會誤稱 Google 決定了商店售價。搜尋顯示可能落後於網站更新,是否展示豐富結果亦由平台自行決定。對網店而言,更具體可量度的完成標準是:測試商品的即時頁面、標記與購買流程一致,且下次商品變動時有人能重複核對。
先釐清含糊要約,再公開標記
套裝和可配置商品,常暴露商品目錄名稱與買家實際可買要約之間的落差。頁面可能寫「起價」,但目前所有可選組合都更貴。應先判斷頁面代表固定要約、價格範圍,還是多個變體,再依 Google 當時支援的模型處理。編碼價格前先核對頁面可見文字;結構化資料不能修補誤導的銷售描述。同一商品若有批發與零售渠道,不應把批發要約複製到消費者頁面。標記內的網址、賣家及價格,應指向訪客在該網址實際可選的要約。
運送和退貨條件影響購買決定,但機器可讀欄位很容易把條件說得過滿。若免運費只適用於滿額訂單,就不能把每件單品都標作無條件免運。若某類商品有特別退貨規則,也不能未核對便沿用全店預設值。Google 的商家文件支援較豐富的運送與退貨資料,但有指定欄位形式及條件;只有在公開政策與結帳計算一致後才應加入。少量準確欄位,比填滿猜測內容的完整範本更有用。
評分欄位亦容易被當成捷徑。網店或許展示顧客感言、供應商評分或其他平台匯入的分數,但它們不會自動成為該商品頁有效的綜合評價。考慮評分標記前,應先依相關 Google 評價政策處理,並如實展示可核對的評價資料。若公司沒有合資格評價,就省略評分欄位;仍可用真實名稱、圖片和要約描述商品。這做法對買家較有用,也避免提出公司不能證實或持續更新的統計聲稱。
決策檢查
- 這是否可購買的單一商品頁,標記是否描述同一要約?
- 公開頁面、標記與結帳的現價、貨幣及庫存是否一致?
- 團隊是否測試實際網址,並指定往後商品變更的負責人?


