Theme、評論 App、SEO App 與自訂程式都可能在 Shopify 商品頁輸出 JSON-LD。單一片段通過 Rich Results Test，不代表整頁正確；常見問題是重複 Product、價格幣別不同、已缺貨仍標 InStock，或評價屬於另一個 variant。
審計需先取得完整 rendered HTML，再將每個 entity 和顧客看到的商品逐欄對照。
盤點所有輸出來源
查看原始 HTML 與渲染後 DOM，搜尋 application/ld+json、microdata 和 RDFa。記錄 Theme、App、GTM、headless server 與 client script 各自輸出什麼。能移除重複來源就不要靠搜尋引擎猜主版本。
建立 schema owner。App 更新或 theme 上線後，固定測試能立刻發現第二套 Product 被加回來。
Product 對應單一商品或變體組
Google merchant listing 指南以可購買的單一商品，或同一 parent 的多個 variant 為主。核對 name、image、description、brand、SKU、GTIN、category 和 variant 關係。圖片 URL 可抓取，且真的呈現標記商品。
Variant 有獨立 URL 時，每頁 canonical、選中選項、價格、availability 和 structured data 都要對應。主頁涵蓋多 variant 時，依官方 ProductGroup/variant 文件實作，不自創欄位。
Offer 使用當下可購買資料
price、priceCurrency、availability、condition、URL、有效時間、shipping 和 return policy 要和可見頁面及 checkout 一致。Market、會員價、subscription 和促銷可能讓價格依顧客不同，標記必須描述該 URL 一般可取得的 offer，不抓內部最低價。
Google 建議快速變動的商品資料盡量在初始 HTML 提供。若 client 才生成，測 crawler 能否穩定取得，並監控 cache 導致的舊價和舊庫存。
評價與評論來源要真實
AggregateRating 的 count、value 和 review 必須屬於頁面商品，顧客也能看到。不能把全站公司評價套到每個商品，不能只標記五星評論而忽略完整集合，也不能在商品下架後保留錯誤 count。
評論 App 與商品合併、SKU 變更時抽樣對帳。Moderation 不等於只留下正評，揭露來源與政策。
Breadcrumb 和 Organization 另行驗證
BreadcrumbList 反映顧客可見階層與 canonical URL，位置順序、名稱和 item 可互相抵達。商品同時出現在多 collection 時，選一條穩定主要路徑，不跟著 tracking context 隨機改變。
Organization 可集中品牌名稱、logo、聯絡、退貨、配送與 loyalty 等全域資訊。個別 Offer 只有在政策不同時覆寫，避免每頁複製後逐漸不一致。
三層工具交叉檢查
先用 schema parser 找語法和 entity graph，再用 Google Rich Results Test 看支援功能，最後在 Search Console enhancement 與 URL Inspection 看 production。警告不一定等於錯誤，仍需逐項判斷是否為商業必要資料。
Merchant Center feed 和頁面 structured data 一起提供時，抽查 ID、title、price、currency、availability、link 和 image。Google 可能交叉驗證，來源衝突會影響資格與顧客體驗。
用測試矩陣涵蓋狀態
至少測單 variant、多 variant、折扣、原價、缺貨、預購、subscription、不同幣別、無評論、有評論、特殊退貨和不同市場。每個案例保存 URL、預期值與實際 JSON-LD，自動比較關鍵欄位。
結構化資料改版驗收可放進 Shopify SEO 改版清單。發布後監看 error 趨勢與抽樣實際頁面，不能只確認 build 產生一段 JSON。
Schema 的目的，是讓機器讀到和顧客相同的商品事實。若頁面、Shopify、feed 與 JSON-LD 無法對上，先修資料與 owner，再追求更多 rich result 欄位。