多數人以為，只要在商品頁的 JSON-LD 裡填一段 aggregateRating，星星和評分數字就會準時出現在 Google 搜尋結果上。多數店家真正沒注意到的，其實是後面那句常被忽略的但書：那顆星星必須是頁面上讀者真的看得到的評論，不是在程式碼裡自己填一個數字就能做出來的。這份把商品資訊交給 Google 讀懂的標記，就是 Product Schema（產品結構化資料），它跟站上其他結構化資料處理的東西不一樣：FAQ、HowTo、Organization、BreadcrumbList 這幾種標記，處理的是「頁面內容本身」，問答、操作步驟、機構資訊、網站路徑；Product Schema 處理的則是「商品這個實體」，它現在賣多少錢、有沒有貨、有沒有人真的評價過它。
Google 官方在說明結構化資料的效益時，自己就引用了幾組數字：爛番茄（Rotten Tomatoes）替 10 萬個網頁加上結構化資料後，點閱率比沒加的網頁高 25%；Food Network 把 80% 的網頁轉成能顯示搜尋功能的版本，造訪量提升 35%；樂天（Rakuten）的使用者在有結構化資料的網頁上，停留時間是沒有標記網頁的 1.5 倍，啟用搜尋功能的 AMP 網頁互動率更高出 3.6 倍；雀巢（Nestlé）以複合式搜尋結果呈現的網頁，點閱率比一般網頁高 82%。這組數字涵蓋的是各種結構化資料類型，不是專指 Product Schema，但它說明了同一件事：把資訊交給 Google 讀懂，搜尋結果版面能多出來的東西，確實會反映在數字上。
只是要拿到這些效果，前提是標記本身得寫對。選錯類別、漏填必填欄位、或是把不該填的東西填進去，結果往往是複合式搜尋結果完全沒出現，甚至整個網站被判定違規。
Product Schema 是什麼？產品摘要與商家資訊兩種標記
Google 官方文件把 Product 結構化資料分成兩種類別，對應兩種完全不同的商品頁情境。第一種是產品摘要（product snippets），用在顧客沒辦法直接在這個網頁下單購買的頁面，例如第三方比價網站、編輯撰寫的產品評測文章。第二種是商家資訊（merchant listings），用在顧客可以直接在這個網頁下單的頁面，一般電商的商品詳情頁幾乎都屬於這一類。分清楚這兩種，是規劃所有後續欄位之前第一件要確認的事，選錯類別，後面填的欄位再齊全也拿不到對應的搜尋結果樣式。
兩種類別的必填門檻差距不小。產品摘要只要求 name（商品名稱）一定要填，加上 review、aggregateRating、offers 三者裡至少要有一個；商家資訊的要求高出一截，name、image、offers 三個都得有，少一個都不行。實務上不用太糾結該選哪一種，如果商家資訊的必要屬性全部填齊，通常產品摘要的資格也一併符合，兩者是可以疊加的關係，不是互斥的兩條路。
產品摘要，給顧客不能在這頁直接買的商品頁用
產品摘要鎖定的是那種讀者只能「看」不能「買」的頁面，第三方比較網站的評測文章、部落格式的開箱評論，這類頁面本身沒有購物車，商品的最終購買動作發生在別的網站上。這也是為什麼它的必填門檻相對寬鬆：只要有 name，再搭配一則評論、一組彙總評分，或是一組報價資訊，三選一就符合資格。
它多出一個商家資訊沒有的功能，就是優缺點標記（positiveNotes／negativeNotes）。這組欄位巢狀寫在 review 底下，用 ItemList／ListItem 表示，規定至少要提供兩則關於產品的陳述，正面、負面的組合不限，可以兩則都是優點，也可以一則優點配一則缺點。但這項功能只對編輯性質的產品評論頁面開放，一般電商商品頁或顧客自己留的評論都不符合資格，把它想成「專業測評的加分項」會比較好理解，不是每種 Product 頁面都用得到。
商家資訊，給顧客可以在這頁直接下單的商品頁用
商家資訊是本篇後面各節主要圍繞的類別，理由很直接：一般電商的商品詳情頁幾乎都屬於這一種，讀者在頁面上要看到的星級、價格、庫存，都要靠這個類別的欄位撐起來。它的標記選項也比產品摘要更多，可以進一步指定服飾尺寸、運送細節、退貨政策這些跟買不買得成直接相關的資訊。
要注意的是它「僅支援以單一產品（或同一產品的多個子類）為主的網頁」，像是「我們店裡的鞋子」這種商品清單頁或分類頁，不算特定產品，不符合資格，得是講清楚某一件商品的頁面才算數。另一個容易忽略的規定是幣別：如果同一件商品用不同幣別販售，每種幣別要各自對應一個獨立網址，不能共用一個頁面靠切換鍵顯示不同幣別的價格。
星級評分不是自己填的，得是頁面上看得到的真實評論
很多人在規劃 Product Schema 的時候，把 aggregateRating 當成一個可以自己決定的數字，覺得只要商品夠好，填個 4.5 分上去，搜尋結果就會出現漂亮的星星。Google 對 Review 和 AggregateRating 有一條明確的規範：標記的內容必須是使用者在這個頁面上真的看得到的東西，不能無中生有，更不能從別的平台把分數搬過來湊數。
官方指南寫得很直接，「請確保使用者可從標記頁面查看您標記的評論內容，且必須一眼就能看出該頁面含有評論內容」，如果用了 AggregateRating，「使用者應該可以在頁面上看到累計評分」。換句話說，aggregateRating.ratingValue 這個數字不是寫給 Google 一個人看的，頁面上真的要有個地方，比如商品星星圖示旁邊，顯示同一個平均分數，兩邊對得起來才算數。
評論作者的姓名格式也有規定。Google 要求作者必須是一個有效的姓名，長度要少於 100 個半形字元，而且不能是促銷句偽裝成的人名。官方給的反例是「週六前購票可享 5 折優惠」這種句子不能拿來當評論者名稱——換句話說，這個欄位要放的是一看就知道是真實人物或單位的名字，不是行銷文案。
另一條常被忽略的規定是「請勿匯總其他網站的評論或評分」，把 Google 商家檔案上的評論分數、或是 Facebook 評論外掛累積的星等，直接搬進自己商品頁的 aggregateRating，是明文禁止的做法，即使那些評論看起來一樣真實。
還有一條限制常被誤解成「電商不能放評論」，其實不是。官方規定是「如果接受評論的實體能控制自身獲得的評論，其使用 LocalBusiness 或任何其他類型 Organization 結構化資料的網頁皆無法使用星級評論功能」，這一條限制的是「公司幫自己整個機構打星等」，例如某公司用 Organization 類型替自己的品牌形象評分。它不是在禁止電商在自己的商品頁上放真實顧客留下的產品評論，Product 頁面放自家顧客評論是官方範例明確示範、允許的正常做法，不要把這兩種情況混為一談。官方也建議只接受附有評論留言與作者姓名的評分，雖然這不是必要做法，但有助於使用者理解評分背後的補充資訊。
一旦違規，後果不是被扣一點分數這麼輕微。如果網頁遭到結構化資料人工判決處罰，系統會直接忽略該網頁上的結構化資料，網頁仍會出現在搜尋結果中，但複合式呈現，也就是星星、價格這些額外樣式會整個消失；情節重大或重複違規時，處罰範圍甚至可能擴大到整個網站的複合式搜尋結果資格。
name、image、offers 三個必填欄位決定搜尋結果內容
搞懂兩種類別的差別之後，真正決定搜尋結果內容的，是 name、image、offers 這幾個必填欄位各自規範了什麼；欄位含意釐清之後，才輪到怎麼把它們組成一份完整可以貼進頁面的 JSON-LD。
name 是商品名稱，兩種類別都要求必填，這個沒有懸念。image 只有商家資訊要求必填，Google 建議提供能清楚看到產品本身的照片，比如白色背景的商品照，而且可以用陣列同時提供多種比例。官方範例是同時給 1×1、4×3、16×9 三種比例的圖：
"image": [
"https://example.com/photos/1x1/photo.jpg",
"https://example.com/photos/4x3/photo.jpg",
"https://example.com/photos/16x9/photo.jpg"
]Code language: JSON / JSON with Comments (json)offers 是巢狀掛在 Product 底下的 Offer 物件，裡面必填 price（或是寫在 priceSpecification.price）與 priceCurrency，幣別要用 ISO 4217 的三個英文字母格式，例如台幣寫 TWD。官方範例長這樣：
"offers": {
"@type": "Offer",
"price": 39.99,
"priceCurrency": "USD"
}Code language: JSON / JSON with Comments (json)免費項目可以把 price 寫成 0，但這個寫法只在產品摘要成立，前面提過，商家資訊要求現行價格必須大於零，這是兩種類別之間一個容易忽略、卻會直接讓標記失格的差異。
價格的字串格式也有硬性規定，這條規定來自 Google Merchant Center 的技術文件，但跟結構化資料指南共用同一套邏輯：價格一律用句點當小數分隔符，不能用逗號；而且顯示給使用者看的價格，必須跟結構化資料裡填的數字一致，兩邊兜不起來會被判定違反開發人員規範。正確寫法是 "39.99"，不能寫成帶貨幣符號的 "$39.99"，也不能寫成帶千分位逗號的 "1,350"。
把 JSON-LD 寫進商品頁的五個步驟
前面兩節把哪些欄位是必填講清楚了；接下來把它們組成一套可以直接貼進商品頁的完整 JSON-LD。Google 官方建議把結構化資料寫成 JSON-LD 格式，理由是這種格式不會跟頁面上使用者看得到的文字交錯在一起，巢狀資料，像是掛在 Product 底下的 Offer、AggregateRating 這種物件，也比其他格式更好表達。標記可以放在網頁的 <head>，也可以放在 <body> 裡，都用同一種 <script type="application/ld+json"> 的區塊包起來。
有一個地雷要先提醒：如果標記是靠 JavaScript 動態產生的，官方明確提醒動態產生的標記可能會導致購物檢索頻率降低且較不可靠，尤其會影響價格、庫存這種變動快速的內容；如果真的一定得用 JavaScript 產生，伺服器的運算資源要能撐得住 Google 流量增加時的負擔。Google Merchant Center 的技術文件講得更絕對，結構化資料標記必須出現在網頁伺服器回傳的 HTML 中，不能是網頁載入後才由 JavaScript 產生，換句話說，寫死在伺服器端輸出的 HTML 裡才是最保險的做法。
接下來五個步驟，從盤點頁面現有資料開始，一路走到部署與驗證。
步驟一，盤點頁面上原本就有的四類資料
在動手寫任何一行 JSON-LD 之前，你要先確認頁面上本來就顯示了哪些對應的資訊：商品名稱與圖片、目前的售價與貨幣、庫存狀態，以及有沒有星級評分和實際的評論文字。這一步呼應的正是第二節那條「必須使用者看得到」的規範，schema 裡要填的每一個值，都得先在頁面上找得到對應的地方，不是先寫好標記再回頭想頁面要不要加東西。
庫存狀態這欄要特別盤點清楚，因為 availability 的可能值不只「有貨」跟「沒貨」兩種，常見值包括 https://schema.org/InStock（有現貨）、OutOfStock（缺貨）、PreOrder（預購）、BackOrder（缺貨可訂，到貨後出貨）。Google 支援不含網址前綴的簡稱寫法，但填完整的網址值是最保險的做法，可以少一個踩雷的可能。把這四類資訊在頁面上逐一核對過一遍，才輪到下一步真正動手寫程式碼。
步驟二，寫出 Product 主體節點
有了盤點清單，第二步是把 @context、@type: "Product"、name、image、description 這幾個欄位寫出來，這是整份標記的骨架，其他節點，像是 offers、aggregateRating、review，都會巢狀掛在它底下。這一步不涉及太複雜的邏輯，重點是把第一步盤點到的商品名稱、圖片網址、商品描述文字，原封不動地填進對應欄位，這幾個值不是拿來寫得漂亮的行銷文案位置，是給 Google 讀取比對用的資料欄位，跟頁面上顯示的內容一致最重要。
描述文字（description）這個欄位常被誤會成加長版的行銷文案位置，其實它的功用只是讓 Google 更清楚知道這個頁面在講哪一件商品，把商品本身是什麼、有什麼特色寫清楚就好，不必額外堆砌關鍵字或誇張的形容詞。把這個主體節點寫完之後，後面每一步都只是往同一個物件裡繼續加東西，不會另外開一個新的節點。
步驟三，把 Offer 巢狀放進 price、priceCurrency、availability 與 itemCondition
第三節講過的必填欄位，這一步真正寫進程式碼：offers 是掛在 Product 底下的巢狀物件，類型是 Offer，裡面填 price、priceCurrency，再補上兩個建議欄位讓資訊更完整，availability（用步驟一盤點到的庫存狀態）與 itemCondition（商品狀況）。itemCondition 的可能值包括 https://schema.org/NewCondition（全新）、UsedCondition（二手）、RefurbishedCondition（整新品），同樣建議填完整網址值而不是簡寫。
如果商品有明確的價格有效期限，可以再加一個 priceValidUntil，用 ISO 8601 日期格式標明這個價格什麼時候到期，常見於檔期限定的促銷價。這幾個建議欄位單獨看都不起眼，但少填一項，搜尋結果能顯示的細節就少一分，像是庫存沒填，讀者在搜尋結果頁就看不到這件商品現在有沒有貨可以買。
走到這裡，已經可以組出一份能夠通過基本檢查的最小可行版本，把前三步累積的欄位放進同一個節點：
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "商品名稱",
"image": ["https://example.com/photos/1x1/photo.jpg"],
"description": "商品說明文字",
"sku": "ABC-12345",
"brand": { "@type": "Brand", "name": "品牌名稱" },
"offers": {
"@type": "Offer",
"url": "https://example.com/products/abc-12345",
"priceCurrency": "TWD",
"price": "1280",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}Code language: JSON / JSON with Comments (json)這是改編自官方範例、置換成台灣情境 TWD 幣別的版本。
步驟四，把 AggregateRating 與 Review 巢狀放進同一個節點
這一步把第二節建立的評分必須真實可見這項原則，轉成實際的巢狀寫法。aggregateRating 和 review 是平行掛在 Product 底下的兩個節點，aggregateRating 是這件商品的彙總評分，review 則可以是單一則評論，也可以是一個陣列，裡面放多筆各自獨立的評論。
填這兩個節點之前，先確認一件事：步驟一盤點到的評論內容跟評分數字，務必跟頁面上實際顯示的一致，不能標記端寫一個數字，頁面顯示又是另一個，這正是前面兩節反覆強調、也是 Google 判斷違規與否最先看的地方。組進上一步的最小可行版本後，含評分的完整版本大致長這樣：
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "商品名稱",
"image": ["https://example.com/photos/1x1/photo.jpg"],
"description": "商品說明文字",
"sku": "ABC-12345",
"brand": { "@type": "Brand", "name": "品牌名稱" },
"offers": {
"@type": "Offer",
"url": "https://example.com/products/abc-12345",
"priceCurrency": "TWD",
"price": "1280",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"review": [
{
"@type": "Review",
"author": { "@type": "Person", "name": "王小明" },
"datePublished": "2026-06-12",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
}
}
],
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"bestRating": "5",
"ratingCount": "89"
}
}Code language: JSON / JSON with Comments (json)步驟五，部署到 head 並用複合式搜尋結果測試驗證
整份 JSON-LD 組好之後，先貼進頁面的 <head>，用「複合式搜尋結果測試」工具檢查有沒有重大錯誤，有錯誤一定要修正，工具標記的非重大問題雖然不影響顯示資格，但修正了有助於提升結構化資料的整體品質。接著實際部署到正式網頁，再用「網址檢查工具」確認 Google 實際讀到、轉譯出來的版本，跟你預期的一不一樣；同時確認這個頁面沒有被 robots.txt 或 noindex 擋住，也沒有設登入限制。為了讓 Google 更快掌握後續的異動，建議額外提交 Sitemap。
最後一件事要有合理的期待：標記部署完不代表下一秒搜尋結果就會變。Google 需要時間重新檢索網頁、重新建立索引，複合式搜尋結果通常不會馬上生效，這是排查階段最容易被忽略、卻最該先有的心理準備。
AggregateRating 與 Review 的必填欄位，作者名稱不能隨便填
前面兩節建立的是心態：評分要真實、要看得到。落到實際欄位，AggregateRating 與 Review 這兩個 schema.org 類型各自有必填屬性，欄位名稱寫錯或漏填，就算頁面上真的有評論，星級照樣不會出現在搜尋結果裡。
AggregateRating 的必填屬性是 ratingValue（商品品質的平均評分，可以是數字、分數，也可以是百分比），加上 ratingCount（這個項目收到的評分總數）與 reviewCount（留下評論的使用者總數，不論有沒有附評分），這兩個欄位至少要有一個，不必兩個都填。如果 AggregateRating 不是巢狀寫在被評論項目底下，才需要額外填 itemReviewed；巢狀寫在 Product 節點底下時，上層的 name 已經指明評論對象，itemReviewed 可以省略。建議屬性是 bestRating／worstRating，標明評分系統的最大值與最小值，沒有特別填的話，系統預設是 5 分制、最低 1 分，這點在你自己家的評分系統不是 5 分制時特別重要，沒填清楚 Google 會用預設值去理解你的分數，反而算錯。
Review 的必填屬性是 author（評論作者，姓名格式限制就是前面第二節講的那條規定）與 reviewRating（這則評論給出的評分，是一個巢狀的 Rating 類型，底下必填 ratingValue）。跟 AggregateRating 一樣，itemReviewed 只有在評論不是巢狀寫的情況下才需要額外填。建議屬性則是 datePublished（用 ISO 8601 日期格式標明評論發布時間）與 reviewRating.bestRating／worstRating。
小數點的格式也有規定，容易在複製貼上時出錯：評分數字一律用半形句點表示小數，例如 4.4，不能寫成 4,4，這個規則其實跟前面第三節價格欄位不能用逗號當小數點是同一套邏輯，兩處都容易在中文輸入習慣或歐洲慣例的影響下寫錯。
review 底下如果有多筆評論，可以直接寫成陣列，每一筆各自有不同的 author 與 reviewRating.ratingValue；同一個 Product 節點底下，再平行放一個彙總過的 aggregateRating，裡面帶 ratingValue、bestRating、ratingCount。這正是前一節那份含評分完整版本 JSON-LD 用的結構，多筆個別評論搭配一個彙總分數，是官方文件裡最常用來說明這兩個類型如何搭配的寫法。
brand、sku、gtin 這類建議欄位，決定能不能進 Google 購物免費商品資訊
前面幾節談的都是不填就沒資格顯示的必填欄位，接下來這幾個屬於另一種類型，不填不會讓標記失敗，但填了才有機會拿到更完整的曝光，尤其是能不能出現在 Google 購物分頁的免費商品資訊裡，關鍵常常就落在這幾個識別碼欄位有沒有填齊。
brand 用 Brand 物件包裹一個 name，標明這件商品是哪個品牌的；sku 是商家自己給商品的自訂編號，規定最多只能指定一個值，不能一次塞好幾組；mpn（製造商零件編號）則是專門用來識別特定製造商生產的產品。這三個都是建議屬性，不是必填，但少了它們，Google 比較難把同一件商品跟其他管道，例如 Merchant Center 的商品資料表，的紀錄對起來。
gtin 系列（gtin、gtin8、gtin12、gtin13、gtin14、isbn）是全球貿易識別碼，官方文件特別強調這個屬性應包含所有適用的全球識別碼，換句話說，如果一件商品同時有條碼編號跟 ISBN，兩個都填比只填一個更完整。書籍類產品還有一個小提醒：建議同時把 @type 標成 ["Product", "Book"] 兩種類型，讓 Google 同時用兩套規則去理解這件商品。
category、color、material、size、pattern 這幾個描述性屬性可以直接接受純文字字串，官方文件明確指出它們對應的是 Google Merchant Center 產品資料規格裡的同名欄位。把這些結構化資料填進網頁本身，Google 就能直接從網頁自動擷取這些資訊，不必額外手動維護一份 CSV 格式的商品資料表，對於商品數量多、SKU 常常異動的店家來說，這是省掉重複維護工作的實際好處，不只是多幾個欄位而已。
原價特價、退貨與運費資訊也能一起出現在搜尋結果
把必填跟建議欄位都填齊之後，還有幾個可以再加值的延伸屬性：折扣、特價期間、退貨與運費資訊，都能一起出現在搜尋結果裡，讓呈現的銷售條件更完整。
第一個是折扣的標記方式。想讓搜尋結果顯示原價劃線、特價醒目的樣式，做法是在 Offer 底下的 priceSpecification 放一個陣列，裡面擺兩個 UnitPriceSpecification，一個不帶 priceType，代表現在的實際售價；另一個把 priceType 設成 https://schema.org/StrikethroughPrice，代表原價：
"priceSpecification": [
{ "@type": "UnitPriceSpecification", "price": 10.00, "priceCurrency": "TWD" },
{ "@type": "UnitPriceSpecification", "priceType": "https://schema.org/StrikethroughPrice", "price": 15.00, "priceCurrency": "TWD" }
]Code language: JSON / JSON with Comments (json)特價期間則用 validFrom（開始時間）搭配 validThrough 或 priceValidUntil（結束時間），都採 ISO 8601 格式，例如 2025-12-31T23:59:59+08:00。官方的最佳做法特別提醒，開始的日期時間必須早於或等於結束的日期時間，順序寫反了標記等於白寫。
退貨政策（hasMerchantReturnPolicy）跟運費（shippingDetails／OfferShippingDetails）這兩個屬性，建議的做法都是設在 Organization 層級，整個網站共用一份標準政策，不必每個商品頁都重複寫一次；只有某件商品有非標準的特殊政策時，才在該商品的 Offer 底下用同名屬性覆寫。退貨政策必填的部分是二選一：一種是 applicableCountry 加上 returnPolicyCategory（例如 MerchantReturnFiniteReturnWindow 代表有限退貨期限、MerchantReturnUnlimitedWindow 代表無限期退貨）；另一種是直接給 merchantReturnLink，也就是退貨政策頁面的網址。運費的核心必填是 shippingConditions，用來指定運費或運送天數適用的條件，例如運送地區、訂單金額範圍。
如果同時在好幾個地方設定退貨與運費政策，Google 會照一套固定的優先順序去採用，由高到低依序是：Content API for Shopping 的帳戶層級設定，其次是 Merchant Center 或 Search Console 裡的設定，再來是產品層級的商家資訊標記，最後才是機構層級的標記。實務上最常見的踩坑情境是，同時在 Search Console 設定了退貨政策，又在網頁上標記了 hasMerchantReturnPolicy，這種情況下 Google 只會採用 Search Console 裡的設定，網頁上寫的那份標記等於被晾在一邊。
標記寫對了，複合式搜尋結果卻沒出現的常見原因
前面每一節都在講怎麼把標記寫對，但很多讀者真正遇到的狀況是，明明照著規範寫了，搜尋結果還是沒有出現星星、沒有價格。問題通常不在欄位規則本身，而是官方文件點名的幾個常見原因，各自對應要去哪裡查。
最基本的可能性是語法本身有錯，這一項用「複合式搜尋結果測試」就能先抓出來，工具會標出所有重大錯誤，這些一定要修正；工具同時也會標出一些非重大問題，雖然不影響顯示資格，但修正了有助於提升結構化資料的整體品質，不是可以完全忽略的雜訊。
第二個常見原因是標記由 JavaScript 動態產生。前面第四節提過，這種做法會讓 Google 的檢索頻率降低、結果較不可靠，尤其影響價格與庫存這種變動快速的資訊，如果排查了半天語法都沒錯，回頭檢查一下標記是不是要等頁面載入完才由前端程式碼組出來，往往就是問題所在。
第三個要排查的是頁面本身有沒有被擋住。確認網頁沒有被 robots.txt 或 noindex 標記封鎖，也沒有設登入才能瀏覽的限制；用網址檢查工具確認 Google 實際讀到的版本，如果看起來一切正常，可以主動要求 Google 重新檢索這個網址。
第四個原因回扣到第二節的核心規範，評分不可見或造假。標記的評分如果頁面上根本找不到對應的地方，或是被判定為造假、自刊評論，會直接觸發結構化資料人工判決處罰，系統忽略整個網頁的結構化資料，情節重大時甚至可能擴大到整個網站。
第五個容易忽略的原因是沒守住「單一產品」這條規則，把商品清單頁或分類頁當成單一產品去標記，或是同一產品的不同幣別共用同一個網址，都不符合商家資訊的技術規範，這種情況下標記語法可能完全正確，卻還是拿不到資格。
最後要有一個心理準備，Google 官方文件明白指出，即使頁面標記完全正確，也不保證一定會顯示在搜尋結果中，能不能出現還牽涉到內容政策是否違反、以及演算法依搜尋歷程、地區、裝置類型等變數對結果所做的整體調整。把這件事想清楚，能少走很多明明寫對了為什麼還是沒有星星的排查冤枉路。
排查這幾件事，靠三個工具就夠用：複合式搜尋結果測試，貼網址或 JSON-LD 進去，能檢查哪些欄位符合規範、哪些有錯誤或缺漏，但只驗證 Google 官方支援的類型；Schema Markup Validator，這是 schema.org 官方提供的工具，驗證的是語法本身有沒有符合 schema.org 規範，不限於 Google 支援的類型；還有 Search Console 的「強化項目」報告，部署後、大改版後，以及平常定期都建議看一眼，能看到哪些頁面的結構化資料有效、哪些出現錯誤或警告。
Product Schema 不是寫一次就能放著不管的標記。商品換季調價、評論持續累積、退貨政策跟著調整，每一次異動都牽動標記裡對應的欄位要不要跟著更新，把它當成頁面資料的另一種呈現方式，而不是一次性做完的 SEO 任務，才撐得住系統長期的檢查。真正決定複合式搜尋結果會不會出現的，從來不是填了多少欄位，而是那些欄位有沒有跟頁面上讀者實際看到的東西對得起來。