Product Schema 實作：電商商品頁欄位、JSON-LD 與驗證流程

Product Schema 是什麼？為什麼電商商品頁需要它？

Product Schema 是用 schema.org/Product 描述商品的結構化資料，讓 Google 更容易讀懂商品名稱、品牌、價格、庫存、評價與購買資訊。對電商商品頁來說，它的價值在於降低搜尋引擎誤判商品資料的機率，並讓頁面具備商品摘要呈現資格。

Product Schema 不等於直接排名因子，也不保證價格、庫存或星等一定出現在搜尋結果。比較精準的說法是，它把頁面上的商品資訊整理成機器可讀格式，可能改善 Google 對商品內容的理解、商品摘要判斷與點擊前資訊呈現。Google 對 Product structured data 的要求可參考 Product snippet structured data 與 Product structured data overview。

Product Schema 會告訴 Google 哪些商品資訊？

Product 結構化資料的核心任務，是把商品頁上原本給人看的資訊，轉成搜尋引擎能穩定解析的欄位。電商網站最常需要標記的是商品本體、銷售條件與評價證據。

商品名稱、品牌、圖片、描述

商品名稱通常對應商品頁 H1 或商品標題，品牌對應商品品牌，圖片對應主要商品圖，描述對應頁面可見的商品說明。我的判斷是，這些欄位看起來基礎，卻最容易因模板抓錯欄位而出問題，例如把系列名稱當商品名，或把分類描述塞進單一商品描述。

價格、幣別、庫存、商品狀態

價格與庫存通常放在 offers 內，包含 price、priceCurrency、availability、itemCondition 與 url。台灣電商常用 TWD 作為 priceCurrency，price 應使用純數字，例如 1280 或 1280.00，不應寫成 NT$1,280。

評分、評論與評論數

aggregateRating 用來描述平均評分，review 用來描述單筆評論。這些欄位只能在商品頁真的有對應評論資料時使用，不能把全站滿意度、店鋪評分或行銷文案包裝成單品評價。

Product Schema 跟搜尋結果商品摘要的關係

商品摘要 rich results 可能使用 Product Schema 內的價格、庫存、評分與評論資訊，但 Google 仍會依頁面品質、資料一致性、查詢情境與系統判斷決定是否顯示。

價格、庫存、星等可能如何出現在搜尋結果

當商品頁符合 Google 的 Product structured data 規範時，搜尋結果可能顯示價格、庫存狀態、評分、評論數等資訊。這會影響使用者在點擊前的判斷，尤其是價格敏感、庫存敏感或品牌比較型查詢。

為什麼它不是保證顯示 rich result

即使 Rich Results Test 顯示通過，也只代表頁面具備資格，不代表 Google 一定展示商品摘要。Google 的 結構化資料一般準則 明確指出，通過測試仍不保證搜尋結果呈現。

什麼頁面適合用 Product Schema？什麼頁面不適合？

Product Schema 最適合用在「單一、明確、可購買或可詢價」的商品頁。分類頁、文章頁、品牌介紹頁通常不應被標成單一 Product，否則 Google 可能無法判斷頁面到底是在賣哪一個商品。

電商網站導入 Schema 時，最先該決定的是適用範圍，而不是先裝外掛。範圍錯了，後面欄位再完整也可能變成錯誤訊號。

適合標 Product Schema 的頁面

單一商品頁

單一商品頁是最標準的 Product Schema 場景，例如一台咖啡機、一件外套、一款軟體方案。Schema 的 name、image、description、offers 都應對應這個商品本身。

有明確價格與購買入口的服務方案頁

有些服務方案可以用 Product 或 Service 描述，例如固定價格的訂閱方案、課程方案或 SaaS 方案。實務上要看頁面是否像商品一樣有明確方案、價格、購買入口與可交付內容。

組合商品或套裝商品頁

組合商品應把套裝當作一個可購買商品處理，價格要用套裝售價，庫存要反映套裝是否可購買。若套裝內每個商品也有獨立頁，canonical 與內部連結要避免互相競爭，可延伸參考 canonical tag 的正規化處理。

不適合或要小心的頁面

商品分類頁

分類頁通常列出很多商品，例如「男鞋」、「保養品」、「筆電配件」。把整個分類頁標成一個 Product，會讓 Google 無法知道價格與庫存對應哪個商品。

純文章、比較文章、品牌介紹頁

文章與品牌介紹頁的主要目的多半是解釋、比較或建立信任，不是直接承載單一商品交易。這類頁面更適合使用 Article、BreadcrumbList 或其他內容型結構化資料。若需要結構化資料基礎，可參考 Article Schema。

沒有實際可購買商品資訊的型錄頁

只有圖片與型號、沒有價格與庫存的型錄頁，可以描述商品，但很難滿足商品摘要或 Merchant listing 的完整資料需求。我的建議是先讓頁面對人清楚，再讓 Schema 對機器清楚。

Product Schema 的核心類型與必備欄位

Product Schema 的核心架構通常由 Product、Offer、AggregateRating、Review 與 BreadcrumbList 組成。商品頁至少要有 name，並依實際情境加入 offers、review 或 aggregateRating；電商商品頁則強烈建議完整提供價格、幣別、庫存與商品狀態。

Product 類型必備欄位

name、image、description、sku、brand

這些欄位讓 Google 知道商品是誰、長什麼樣、屬於哪個品牌，以及如何用 SKU 區分商品。schema.org/Product 的完整屬性可參考 schema.org Product，但實作時不需要把所有屬性都塞進商品頁。

Offer 價格與庫存欄位

price、priceCurrency、availability、itemCondition、url

Offer 描述的是商品如何被銷售。Google Merchant listing 文件要求價格與幣別等欄位要能被明確解析，Merchant Center 對自動更新也特別依賴 price、priceCurrency、availability 與 condition 等資料。

評分與評論欄位

評分與評論能強化商品摘要，但它們也是最容易造成合規風險的區塊。只要沒有真實、可見、對應單一商品的評論資料，就不應加入 aggregateRating 或 review。

aggregateRating 的使用條件

aggregateRating 應來自多筆真實評分，並對應目前商品本身。ratingValue、reviewCount 或 ratingCount 要與頁面可見資料一致，不能因為想顯示星等而自行編造。

review 的合規邊界

review 應包含真實評論者、評論內容、日期與評分。若頁面上看不到該評論，JSON-LD 卻標了 review，這會違反結構化資料的內容一致性原則。

BreadcrumbList 是否要一起做？

BreadcrumbList 不是 Product Schema 的必要欄位，但商品頁很適合一起做，因為它能補充商品位於哪個分類層級，幫助搜尋引擎理解站內結構。

商品頁層級與麵包屑輔助理解

例如「首頁 > 咖啡器材 > 手沖壺 > 某款手沖壺」，BreadcrumbList 能把商品頁放回正確分類脈絡。對大量商品網站來說，這比每頁單獨堆關鍵字更有結構價值。

Product Schema JSON-LD 範例：單一商品頁怎麼寫？

單一商品頁建議使用 JSON-LD，放在 HTML 的 script type="application/ld+json" 中。JSON-LD 應從商品資料庫或頁面可見內容產生，並讓商品名稱、價格、庫存、品牌、評價與頁面顯示內容一致。

完整 JSON-LD 範例

以下範例以台灣電商常見商品頁為情境，使用 TWD、InStock 與 NewCondition。實際使用時，請把商品名稱、圖片、URL、SKU、品牌、價格與評論改成網站自己的資料。

Product 主體

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "山形陶瓷手沖咖啡濾杯",
  "image": [
    "https://www.9iseo.com.tw/media/products/ceramic-dripper-main.jpg"
  ],
  "description": "適合 1 到 2 人份手沖咖啡的陶瓷濾杯，杯身保溫穩定，適用 V60 錐形濾紙。",
  "sku": "DRIPPER-CERAMIC-01",
  "mpn": "DC-2026-01",
  "brand": {
    "@type": "Brand",
    "name": "Yama Coffee Tools"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.9iseo.com.tw/articles/product-schema-example",
    "priceCurrency": "TWD",
    "price": "1280.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "36"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "林小姐"
      },
      "datePublished": "2026-03-12",
      "name": "保溫穩定，出水速度好控制",
      "reviewBody": "濾杯重量剛好，手沖時溫度穩定，對新手來說很好掌握。",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}
</script>

offers 價格與庫存

offers 內的 price 要放純數字，priceCurrency 使用 TWD，availability 使用 schema.org 標準值，例如 https://schema.org/InStock 或 https://schema.org/OutOfStock。庫存若由後台管理，JSON-LD 應由同一個庫存來源動態產生。

aggregateRating 與 review 範例

範例中的 aggregateRating 與 review 只適合用在頁面真的顯示平均評分與評論內容時。若商品頁沒有評論區，請先移除這兩段，保留 Product 與 offers 即可。

Product Schema 要放在 HTML 哪裡？

JSON-LD 可以放在 head 或 body，只要 Google 能讀取且資料與頁面內容一致。Google 一般建議在可維護的情況下使用 JSON-LD，相關格式說明可參考 Structured data markup intro。

head 或 body 皆可，但資料需與頁面一致

實務上，商品頁模板常把 JSON-LD 放在 head 或商品模板底部。位置不是主要問題，真正要檢查的是價格、庫存與變體是否跟使用者看到的內容同步。

Product Schema 會顯示在頁面上嗎？

JSON-LD 本身不會像商品標題或價格那樣顯示在畫面上，但搜尋引擎可以讀取。這也是它適合大量商品頁維護的原因，模板可以從商品系統輸出固定格式。

不直接顯示給使用者，但搜尋引擎可讀取

雖然 JSON-LD 不直接顯示，內容仍必須對應頁面可見資訊。把頁面沒有的評論、價格或庫存塞進 Schema，是高風險做法。

欄位 mapping 檢查清單：資料要從哪裡來？

Product Schema 的每個欄位都應對應到頁面可見內容或商品系統資料來源。最穩定的做法，是讓 JSON-LD 從商品資料庫、CMS 欄位或電商後台動態產生，而非由人工長期手動複製。

基本商品資料 mapping

name 對應商品標題

name 應對應商品頁主標題。若網站為 SEO title 加上「限時優惠」或「官方直營」，不一定要全部放進 name，避免商品名稱變得不穩定。

description 對應商品描述

description 應取自商品描述欄位，並能被使用者在頁面上找到相同或高度一致的內容。只用 meta description 當來源時，要確認它不是行銷摘要到失去商品細節。

sku / mpn 對應內部商品編號

sku 主要由商家內部管理，mpn 則偏向製造商零件編號。兩者不要混用，尤其是多規格商品，錯誤 SKU 會讓 Feed、庫存與結構化資料更難對齊。

價格與庫存 mapping

price 只能放純數字

price 不要含貨幣符號、千分位逗號或中文單位。頁面可顯示 NT$1,280，但 JSON-LD 應寫成 1280.00。

priceCurrency 使用 TWD 等 ISO 幣別

priceCurrency 應使用 ISO 4217 三碼幣別。台灣商品頁通常使用 TWD，跨境電商若同頁顯示多幣別，需確認每個 Offer 的幣別與價格能清楚對應。

availability 使用 Schema.org 標準 URL

availability 應使用標準值，例如 https://schema.org/InStock、https://schema.org/OutOfStock、https://schema.org/PreOrder。這比「現貨」、「可預購」更容易被機器穩定解析。

評價資料 mapping

評價資料要從真實評論系統或商品後台而來，並且能在商品頁上被使用者看見。這一段不宜交給 SEO 外掛自行補假資料。

ratingValue、reviewCount、實際評論內容需一致

如果頁面顯示 36 則評論，Schema 就不該寫 120 則；如果頁面平均 4.6 分，Schema 就不該寫 5 分。我的判斷是，評價欄位寧可少標，也不要因為想拿星等而破壞信任。

不同平台如何實作 Product Schema？

不同電商平台的 Product Schema 來源不同：Shopify 常由 Theme 或 App 輸出，WooCommerce 可能由核心、主題與 SEO 外掛同時輸出，Joomla 仰賴結構化資料元件，客製與 Headless CMS 則應從商品資料庫動態產生 JSON-LD。

Shopify

Theme 可能已輸出 Product Schema

不少 Shopify Theme 已內建 Product Schema。導入新 App 前，應先用 Rich Results Test 或檢視原始碼確認是否已有 Product、Offer、AggregateRating。

注意變體價格與庫存是否同步

Shopify 商品常有尺寸、顏色與不同售價。若 JSON-LD 固定輸出第一個變體價格，使用者選到其他變體時，Google 讀到的資料可能與頁面狀態不一致。

WooCommerce

WooCommerce 會自動輸出部分 Schema

WooCommerce 通常會輸出部分商品結構化資料，但完整度會受主題、外掛與商品欄位影響。不要只因為有輸出就視為完成，仍要檢查欄位是否符合 Google 需求。

主題、SEO 外掛、Review 外掛可能重複輸出

WooCommerce 最常見問題是多套外掛各自輸出 Product、Offer 或 Review，造成欄位衝突。實務上應選定主要來源，其他來源關閉 Product Schema 功能。

Joomla

可透過結構化資料元件建立 Product Schema

Joomla 可透過結構化資料元件或模板方式建立 Product Schema，但不要只把功能開啟。每個欄位要能對應到商品名稱、價格、庫存與品牌資料。

重點在欄位 mapping，不是只開啟功能

很多平台問題不是缺工具，而是工具抓錯資料。若價格要人工填，庫存又由另一套系統管理，長期就很容易過期。

客製電商與 Headless CMS

建議從商品資料庫動態產生 JSON-LD

客製電商最好的做法，是由商品資料庫或商品 API 直接產生 JSON-LD。這能減少人工維護錯誤，也能讓價格、庫存與 SKU 一起更新。

前端渲染後仍需確認 Google 可讀取

Headless CMS 或前端框架網站要確認 JSON-LD 是否在 Google 可讀取的 HTML 或渲染結果中。若 Merchant Center 需要比對落地頁資料，初始 HTML 的穩定性也很重要。

Product variants 怎麼標記？尺寸、顏色、容量、不同庫存怎麼辦？

商品變體要讓 Schema 對應使用者目前能購買的變體資料。若尺寸、顏色、容量有不同 SKU、價格或庫存，就不能用同一個固定價格與庫存狀態代表所有變體。

Google 已支援使用 ProductGroup 搭配 Product 來描述商品變體，包含 variesBy、hasVariant、productGroupID 等屬性，詳見 Product variant structured data。

同一頁選尺寸或顏色

Schema 應反映預設商品或可購買變體資料

如果同一頁預設顯示黑色 M 號，Schema 就應對應黑色 M 號的 SKU、價格與庫存。若使用者切換變體後 URL 不變，前端狀態與 Schema 的關係要由工程端明確定義。

每個變體有獨立 URL

每個 URL 的 Schema 要對應當前變體

若每個變體都有獨立 URL，該 URL 的 Product Schema 應標示當前變體，不要所有 URL 都輸出主商品的同一組 SKU。canonical 也要配合索引策略，避免明明想讓變體被理解，卻全部指回不含變體資訊的主頁。

不同變體價格或庫存不同

變體最容易出錯的地方，是價格與庫存不同。尤其服飾、電子配件、容量型商品，某些顏色有貨、某些顏色缺貨，Schema 必須能反映這種差異。

避免用錯誤平均價格或固定庫存狀態

不要用平均價格代表所有變體，也不要全部固定標成 InStock。這會讓 Google、Merchant Center 與使用者看到的資訊互相矛盾。

Product Schema、Merchant Center 與商品 Feed 的關係

Product Schema、商品 Feed、Merchant Center 是三個不同層次：Schema 幫助 Google 從商品頁理解內容，Feed 批次提交商品資料，Merchant Center 管理商品資料品質與 Shopping 生態呈現。

只做 Product Schema，不能取代商品 Feed；只上傳 Feed，也不能讓商品頁本身的結構化資料自動正確。對有規模的電商，三者應該互相對齊。

Product Schema 負責什麼？

Product Schema 主要存在於商品頁 HTML 中，讓 Google 從頁面讀取商品名稱、價格、庫存、品牌、評價與其他商品屬性。

協助 Google 從商品頁理解頁面內容

Schema 是頁面理解層。它能幫助 Google 對照使用者看到的內容，但不能負責商品帳戶審核、購物廣告設定或 Feed 目的地管理。

商品 Feed 負責什麼？

商品 Feed 是批次提交商品資料的格式，通常包含商品 ID、標題、描述、價格、庫存、圖片連結、商品頁 URL 與變體分組資料。

批次提交商品價格、庫存、連結與屬性

對大量商品網站來說，Feed 是商品資料管理的主幹。Google Merchant Center 的 Product data specification 對價格、庫存、商品識別碼與其他屬性有自己的格式要求。

Merchant Center 負責什麼？

Merchant Center 負責商品資料品質、免費刊登、Shopping 相關呈現與部分商品資料診斷。它會使用 Feed、網站資料與其他信號來判斷商品資訊是否可靠。

管理商品資料品質與 Shopping 生態呈現

Merchant Center 的重點是商品資料能不能被 Google 商品生態使用。Google 也提供 Merchant Center structured data setup，說明頁面結構化資料與商品資料比對的重要性。

三者資料不一致會發生什麼事？

當 Schema、Feed 與商品頁顯示內容不一致，可能造成商品摘要不穩定、Merchant Center 診斷問題、價格或庫存更新延遲，也會降低系統對資料的信任。

價格、庫存、網址不一致會造成信任與顯示問題

例如商品頁顯示 980 元，Schema 寫 1280 元，Feed 又提交 1080 元，Google 很難判斷哪一個才是最新可用價格。這類問題不應靠 SEO 文字補救，應回到商品資料源頭修正。

Product Schema 產生器可以用嗎？什麼時候不該全靠產生器？

Product Schema 產生器可以用來學習 JSON-LD 格式、製作少量商品頁範例或快速測試欄位，但不適合用來長期維護大量、常變價、常缺貨或多變體商品。

適合使用產生器的情境

產生器的價值是降低入門門檻。當網站只有少量商品，或團隊需要先看懂 Product Schema 長什麼樣，產生器能提供可修改的草稿。

少量商品頁、測試範例、初步學習

若只有幾個固定價格的商品頁，手動產生 JSON-LD 後貼到頁面模板或 CMS 區塊，仍可能可行。但每次價格、庫存、商品圖變動時，都要同步更新。

不該全靠產生器的情境

大量商品頁若靠人工產生，很快會出現資料過期。價格、庫存、變體與評論一旦頻繁變動，Schema 就必須由系統自動產生。

大量商品、價格常變、庫存常變、多變體商品

有上百或上千商品的網站，應從商品資料庫、電商後台或 API 產生 JSON-LD。我的判斷是，這時候產生器只能當開發參考，不能當正式維護流程。

產生器輸出後要檢查什麼？

產生器輸出的 JSON-LD 要經過欄位完整性、URL、價格格式、資料一致性與驗證工具檢查。不要因為語法看起來正確，就直接上線。

欄位完整性、URL、價格格式、資料一致性、驗證結果

檢查重點包含：name 是否對應商品、url 是否為商品頁、price 是否純數字、priceCurrency 是否為 TWD、availability 是否為 schema.org 標準值、評論是否真實可見，最後再用 Rich Results Test 驗證。

驗證、除錯與大量商品頁監控流程

Product Schema 驗證應分三層：上線前用 Rich Results Test 與 Schema Markup Validator 測單頁，上線後用 Search Console 觀察錯誤與有效頁面，大量商品頁則用模板檢查與抽樣監控價格、庫存、變體同步。

上線前：單頁測試

上線前先挑一個代表性商品頁測試。若網站有一般商品、缺貨商品、特價商品與多變體商品，至少各挑一頁測。

Rich Results Test 檢查 Google rich result 資格

Rich Results Test 可檢查 Google 是否能讀到頁面上的 Product structured data，以及是否具備商品摘要或其他 rich result 資格。

Schema Markup Validator 檢查語法

Schema Markup Validator 適合檢查 schema.org 語法與結構。它能幫助找出 JSON 格式、類型與屬性問題，但 Google rich result 資格仍應以 Google 測試工具為準。

上線後：Search Console 觀察

上線後不要只看單頁測試結果。Search Console 能觀察 Google 實際抓取後的結構化資料狀態，包含錯誤、警告與有效頁面變化。

錯誤、警告、有效頁面數變化

若有效頁面突然下降，通常代表模板變更、外掛更新、商品欄位缺漏或 Google 重新判斷。警告不一定會讓頁面失效，但它常提示欄位不足，值得排進技術 SEO 檢查清單。

大量商品頁：批次與抽樣檢查

大量商品頁不可能每頁人工看，應用抽樣與模板檢查。先確認模板輸出規則，再針對高風險商品抽查。

抽樣高流量、高營收、常變價、常缺貨商品

抽樣名單應包含高流量商品、高營收商品、常促銷商品、常缺貨商品、多變體商品與新上架商品。這些頁面最容易出現價格過期或庫存不同步。

監控價格過期與庫存不同步

若商品頁、Schema、Feed、結帳頁價格不同，就要回到資料源頭檢查。Schema 錯誤常只是表面症狀，真正問題可能在快取、API 更新頻率或外掛輸出順序。

常見錯誤與合規風險

Product Schema 常見風險包含同頁重複輸出、價格格式錯誤、庫存不同步、亂加 aggregateRating、評論不可見與欄位對應錯誤。這些問題可能讓 rich result 資格不穩，也可能違反結構化資料品質準則。

同一頁輸出多組互相衝突的 Product Schema

Theme、外掛、模板重複輸出的處理

處理重複輸出時，不要急著刪掉所有 Schema。先確認哪一套資料最完整、最能同步商品後台，再保留那一套。

價格、幣別、庫存格式錯誤

price 不要含貨幣符號或逗號

price 欄位給機器讀，不是給使用者看。頁面可以寫 NT$1,280，Schema 應寫 1280.00，幣別交給 priceCurrency 處理。

亂加 aggregateRating 或 review

不能把全站評分套到單一商品

店鋪服務評分、品牌滿意度或全站平均分數，不能直接套到每個 Product。單一商品的 aggregateRating 必須對應該商品本身。

評論內容需真實、可見、對應商品

review 應對應頁面上的真實評論。若使用者看不到該評論，搜尋引擎卻讀到 review，這就是典型的資料不一致。

2026 年 Product Schema 對 AI 搜尋與商品引用的影響

Product Schema 在 AI 搜尋中的價值，是提升商品屬性被抽取與核對的清楚度。它不能保證 AI Overview、ChatGPT Shopping 或 Perplexity 引用商品，但能讓價格、品牌、規格、庫存與評論證據更容易被機器理解。

AI 搜尋需要可抽取的商品屬性

AI 搜尋若要比較商品，通常需要清楚的商品名稱、品牌、價格、規格、用途、庫存與評價證據。Schema 能提供結構化信號，但頁面本身也要有足夠可見內容。

價格、品牌、規格、用途、庫存、評論證據

商品頁若只有圖片與一句短標，JSON-LD 再完整也很難支撐複雜查詢。規格表、商品描述、適用情境與真實評論，都是商品屬性被理解的基礎。

Schema 不能取代頁面內容品質

Product Schema 應該是頁面內容的結構化版本，而不是頁面內容的替代品。AI 搜尋與傳統搜尋一樣，都需要能被驗證的頁面證據。

頁面可見內容仍要支撐 JSON-LD

如果 JSON-LD 寫了品牌、材質、容量與保固，頁面上也應清楚呈現相同資訊。這會讓人與機器看到一致的商品證據。

商品頁要讓人與機器都看得懂

2026 年的商品頁不能只靠後台欄位，也不能只靠漂亮前端。好的商品頁應同時具備清楚內容、穩定資料、正確 Schema 與可驗證的價格庫存。

Schema、表格、規格區、FAQ 要互相一致

商品規格表寫 500ml，Schema 不應寫 300ml；FAQ 說缺貨，offers 不應標 InStock。這種一致性，是電商技術 SEO 很實際的基本功，也能延伸到 AI 搜尋可引用性，相關觀念可參考 GEO 生成式搜尋優化 與 電商 SEO 2026 指南。