同樣排在第三名，為什麼有些商品在 Google 搜尋結果裡帶著金色星星、價格區間與「現貨供應」，旁邊的競爭對手卻只是一行藍色標題？差別往往不在排名，而在於頁面有沒有把商品 schema 優化做到位。星等、庫存、價格這三塊資訊一旦被搜尋引擎正確讀到，同一個排名位置就能換到明顯更高的點擊率。
多數 WooCommerce 教學講到 Product 結構化資料就停在「裝個外掛、勾一勾」，但真正讓商品摘要長出星星、讓變體商品顯示價格區間、讓缺貨時不誤導消費者的細節，都藏在 aggregateRating、AggregateOffer 與 availability 這幾個屬性的填法裡。這篇會把進階寫法逐一拆開，並說明哪些是 Google 真的會採用的欄位、哪些填了只是浪費力氣。
商品 schema 是什麼，三種觸發條件怎麼選
商品 schema 是寫在頁面裡的一段 Product 結構化資料，用 schema.org 的詞彙告訴 Google「這頁在賣什麼、賣多少錢、有沒有現貨、評價如何」。Google 讀懂後，就可能把這些資訊直接放進搜尋結果，形成所謂的商品複合式搜尋結果。
根據 Google 搜尋中心的官方文件，一段 Product 標記要取得商品摘要資格，除了 name（商品名稱）這個必填欄位外，還必須至少包含 review、aggregateRating、offers 三者其中之一。換句話說，這三個欄位是「鑰匙」，少了全部就不可能長出任何複合式結果。
實務上的選擇邏輯很單純。想顯示星等就放 aggregateRating，想顯示價格與庫存就放 offers，兩者通常一起放。review（單則評論）則適合編輯型評測頁面，例如媒體寫的開箱文。一般 WooCommerce 商店頁面，主力應該放在 aggregateRating 加 offers 這組搭配上。
商品摘要與商家資訊有什麼不同
商品摘要（Product snippet）與商家資訊（Merchant listing）是兩種不同的呈現，兩者的資格門檻、出現位置、Search Console 報表都分開，搞混會讓你對著錯的報表除錯。
商品摘要出現在一般自然搜尋結果裡，門檻較低，頁面有合格的 Product 標記就可能取得。它適合的是「無法直接購買」的頁面，例如評測文、比較文、聚合頁。商家資訊則針對「可以直接下單購買」的頁面，除了 Product 標記，還更看重 price、priceCurrency、availability 這些交易資訊是否齊全，能延伸到 Google 購物分頁顯示。
這個區分在除錯時特別重要。Search Console 裡有兩份獨立報表，一份叫「商家資訊」、一份叫「商品摘要」。Google 文件特別說明，商家資訊報表已經涵蓋帶有 Offer 的商品摘要檢查，所以只有非商家型的頁面（評測、聚合）才需要去看商品摘要那份報表。看錯報表，常常會誤判某個警告該不該理會。
評分星等怎麼寫才會被 Google 採用
要讓搜尋結果長出金色星星，核心是 aggregateRating 這個巢狀物件，裡面至少要有平均分數與評論數量兩個值。Google 官方範例的標準寫法如下，這段直接放進頁面的 JSON-LD 即可。
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "2847",
"bestRating": "5",
"worstRating": "1"
}
四個屬性各有用途。ratingValue 是平均分數；reviewCount 是有寫文字評論的則數，ratingCount 則是含純評分的總數，兩者擇一或併用都可以。bestRating 與 worstRating 用來宣告評分級距，預設是 5 與 1，如果你的評分制度本來就是五星制，這兩個其實可以省略，但明寫出來能避免 Google 誤判級距。
最容易踩雷、也是多數教學沒提的一條紅線在於「自我吹捧的評論」。根據 Google 自 2019 年 9 月起實施、後續持續沿用的規範，當被評價的對象就是頁面擁有者自己時，套用 Organization 或 LocalBusiness 類型的頁面不再有資格顯示星等。簡單說，你不能在自家公司簡介頁掛一個「本公司 4.9 星」的 AggregateRating 期待它長出星星。
關鍵差別在於：商品頁面的「商品評論」不在這條限制內。消費者對你販售的某項商品留下的評分，依然可以正常透過 Product 的 aggregateRating 顯示星等。所以寫法上務必把評分掛在 Product 物件底下、針對的是「商品」，而不是掛在代表「你這家店」的 Organization 底下。WooCommerce 預設的商品評論機制剛好就是針對單一商品，方向是對的。
庫存狀態的 availability 該填哪些值
availability 用來告訴 Google 商品目前是現貨、缺貨還是預購，它接受一組固定的列舉值，不能自己亂打字串。Google 文件列出的可用選項主要有以下幾種，建議使用完整的 schema.org 網址形式。
https://schema.org/InStock：現貨供應，是最常見的狀態https://schema.org/OutOfStock：已售完、暫無庫存https://schema.org/PreOrder：尚未上市、開放預購https://schema.org/BackOrder：已售完但接受延後出貨的訂單https://schema.org/Discontinued：商品已停產、不再販售
填值有兩個常見錯誤。第一是把缺貨商品仍標成 InStock，這會讓使用者點進來才發現買不到，傷害信任、長期也影響 Google 對頁面的評估；availability 必須跟頁面實際狀態同步。第二是格式寫錯，雖然 Google 也接受省略網址前綴的短名稱（例如直接寫 InStock），但混用大小寫或拼錯字就會讓這個欄位失效。
在 WooCommerce 環境裡，庫存狀態通常會由系統自動對應到 schema 的 availability，前提是你有正確設定每件商品的庫存管理。問題常出在「動態載入」：如果價格與庫存是靠 JavaScript 事後塞進頁面的，Google 文件明白提醒，動態產生的標記會讓購物爬蟲抓取得較不頻繁、也較不可靠，對庫存與價格這類變動快的資訊尤其不利。最穩的做法是讓 Product 標記出現在最初的 HTML 裡。
價格區間如何用 AggregateOffer 標記
單一固定價格用 Offer，但當一件商品有多個變體、各自價格不同（例如同款衣服不同尺寸、不同容量的訂閱方案）時，要改用 AggregateOffer，靠 lowPrice 與 highPrice 標出價格區間。Google 官方的聚合頁範例寫法如下。
"offers": {
"@type": "AggregateOffer",
"offerCount": 5,
"lowPrice": 119.99,
"highPrice": 199.99,
"priceCurrency": "USD"
}
其中 lowPrice（最低價）與 priceCurrency（幣別）是 AggregateOffer 的必填項，highPrice（最高價）與 offerCount（報價數量）則是建議填。台灣商店記得把 priceCurrency 設為 TWD。價格一律用半形小數點當分隔符號，不要加千分位逗號，否則會被判讀錯誤。
這裡有個極易混淆的觀念要釐清。Google 文件明確指出，AggregateOffer 是用來表示「同一商品被多個賣家販售」的價格聚合，不應該拿來描述「同一商品的多個變體」。商品變體有專門的變體結構化資料寫法（product variant），每個變體最好有各自的網址。對大多數 WooCommerce 可變商品來說，比較務實的折衷是：用 AggregateOffer 在商品主頁呈現「NT$119 起」這類價格區間，確實能讓搜尋結果顯示區間，但若要精準對應每個變體，仍應評估變體標記。
至於單一價格的 Offer，除了 price 與 priceCurrency，還有兩個值得補的屬性。一是 itemCondition（商品狀況，新品填 https://schema.org/NewCondition），二是 priceValidUntil（此價格的有效截止日，用 ISO 8601 日期格式）。priceValidUntil 在沒有設定特價時經常顯示「缺少欄位」警告，但它屬於非必要，Google 官方說明不填並不會傷害商品在搜尋結果的呈現，所以遇到這個警告不必緊張。
完整 JSON-LD 範本與各欄位優先順序
把前面拆開的區塊組起來，一段涵蓋星等、價格、庫存的完整 Product 結構化資料大致長這樣。實務上放進頁面 <head> 或 <body> 的 <script type="application/ld+json"> 標籤內即可。
{
"@context": "https://schema.org",
"@type": "Product",
"name": "無線降噪耳機 Pro",
"image": ["https://example.com/images/headphones-main.jpg"],
"description": "支援主動降噪、續航 30 小時的旗艦耳機。",
"sku": "WBH-PRO-001",
"brand": { "@type": "Brand", "name": "AudioTech" },
"offers": {
"@type": "Offer",
"priceCurrency": "TWD",
"price": "4990",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "2847"
}
}
各欄位投入心力的優先順序可以這樣排。name 與圖片是基礎，缺了複合式結果會不完整。offers 裡的 price 與 priceCurrency 是顯示價格的關鍵，availability 則是庫存指示，這三個對「商家資訊」資格幾乎是必備。aggregateRating 屬於強烈建議，因為星等對點擊率的拉抬最直觀。sku、brand、商品識別碼（gtin、mpn）則有助於跟 Google 購物整合，行有餘力再補。
下面這張對照表把每個欄位的必要程度與效果整理在一起，方便排定實作順序。
| 屬性 | 必要程度 | 帶來的效果 |
|---|---|---|
| name | 必填 | 複合式結果顯示商品名稱 |
| image | 必填 | 結果中顯示商品圖片 |
| offers.price | 顯示價格所需 | 摘要中出現價格 |
| offers.priceCurrency | 顯示價格所需 | 標明幣別，台灣填 TWD |
| offers.availability | 顯示庫存所需 | 出現現貨／缺貨指示 |
| aggregateRating | 強烈建議 | 摘要中長出星等 |
| sku、brand、識別碼 | 建議 | 利於 Google 購物整合 |
| review | 選填 | 評論摘要與信任訊號 |
寫完之後怎麼驗證與持續監控
標記寫完不等於就會顯示，必須先用 Google 的複合式搜尋結果測試工具驗證、再透過 Search Console 長期追蹤實際成效，整個流程缺一不可。
第一步是拿商品網址丟進複合式搜尋結果測試工具，確認沒有「重大錯誤」（critical errors）。重大錯誤會讓頁面直接失去資格，必須修掉；至於非重大的「警告」，例如前面提到的 priceValidUntil，可改善但不影響資格，依情況決定要不要處理。Google 也建議測完後用網址審查工具看 Google 實際怎麼看這個頁面，確認沒有被 robots.txt 或 noindex 擋住。
第二步是部署後到 Search Console 看報表。如前所述，商家型頁面看「商家資訊」報表，評測或聚合頁看「商品摘要」報表。剛上線、改版、或更新模板後都該回來檢查：理想狀況是有效項目增加、無效項目沒有增加。如果某次改版後無效項目突然變多，多半是新模板沒套好；如果有效項目莫名減少，可能是頁面不再正確嵌入標記。
要特別留意的是，結構化資料正確不代表 Google 一定會顯示複合式結果。Google 從不保證消費結構化資料的功能會出現在搜尋結果裡，標記只是「取得資格」的前提。把該填的填對、跟頁面實際狀態保持同步、避免動態載入造成抓取不穩，是把商品 schema 優化的價值真正換成點擊的可靠路徑。先從 aggregateRating 與 offers 這組核心搭配做起，驗證沒有重大錯誤後上線，再依 Search Console 的回饋逐步補齊識別碼與運送資訊。