電商Schema怎麼做？商品頁結構化資料欄位與驗證重點

電商 Schema 是什麼？它和電商資料庫 schema 一樣嗎？

電商 Schema 指的是放在網頁上的結構化資料，主要用來讓 Google、AI 搜尋與其他系統理解商品、價格、庫存、評論、配送與退貨資訊。它和電商資料庫 schema 不同，後者是後台資料表設計，前者是搜尋引擎能讀懂的頁面語義標記。

以 9iseo / Kevin Lin 的技術 SEO 實作角度來看，電商網站需要實作哪些 Schema Markup，重點不是把 schema.org 所有屬性塞滿，而是把頁面上真實可見的商品資訊，用 JSON-LD 對應成穩定、可驗證、可維護的資料。Google Search Central 將結構化資料描述為協助 Google 理解頁面內容的明確線索，實作時應以 Google 結構化資料文件 作為搜尋功能判斷依據，schema.org 則作為詞彙來源。

Schema.org、JSON-LD、Google 結構化資料的差別

Schema.org 是詞彙表，JSON-LD 是寫在頁面上的格式，Google 結構化資料文件則是判斷搜尋結果資格的規則。這三者常被混在一起講，但工程交付時必須拆開，否則很容易出現「schema.org 有這個屬性，所以 Google 一定會用」的誤判。

為什麼「電商schema」會有兩種意思

「電商schema」在搜尋時會同時指向兩種需求：一種是 SEO 用的電商 Schema Markup，另一種是工程用的電商資料庫 schema。前者處理 Product Schema、Offer、BreadcrumbList、OnlineStore 等搜尋語義；後者處理商品表、訂單表、庫存表與會員表。這篇只處理搜尋引擎與商品頁 SEO 所需的結構化資料，不展開 SQL table、ERD、金流串接或倉儲系統設計。

電商網站必做的 Schema Markup 架構總圖

電商網站至少要做 Product、Offer、BreadcrumbList、Organization 與 WebSite；成熟網站再補 OnlineStore、ShippingDetails、MerchantReturnPolicy、Review、AggregateRating 與 FAQ。判斷優先順序時，先看是否直接影響商品頁摘要資格、價格庫存理解與交易政策清楚度。

全站層級：OnlineStore、Organization、WebSite

全站層級 Schema 負責描述「這個網站是誰、提供什麼商店服務、網站本身如何被搜尋」。OnlineStore 是 2026 電商實作容易被忽略的缺口，schema.org 將 OnlineStore 定義為 eCommerce site，可用來承接線上商店、付款方式、服務區域、退貨政策與配送服務等語義。

我的判斷是：多數台灣電商先前只放 Organization 與 WebSite，對品牌 SEO 有幫助，但對「商店」這個實體描述偏弱。若網站有明確線上銷售功能，首頁或商店介紹頁應考慮 OnlineStore，並讓它與 Organization 使用一致的品牌名稱、Logo、官方網址與客服資訊。

分類與導覽層級：BreadcrumbList

BreadcrumbList 用來說明分類、子分類與商品頁的階層關係。它不會重設網站導覽 UX，但能讓搜尋系統更清楚理解商品位於哪一個分類脈絡。

商品頁層級：Product、Offer、AggregateRating、Review

商品頁核心是 Product Schema，交易資訊則放在 Offer。Product 描述商品本體，Offer 描述價格、幣別、庫存與銷售狀態，AggregateRating 與 Review 只能在頁面有真實評論時標記。

• Product：商品名稱、圖片、描述、品牌、SKU、GTIN、規格。
• Offer：售價、priceCurrency、availability、itemCondition、seller、商品頁 URL。
• AggregateRating：整體星等、評分數、評論數。
• Review：單則真實評論、評論者、日期、評分與評論內容。

商品頁最常見的錯誤不是少放冷門屬性，而是價格、庫存、頁面可見內容與 JSON-LD 不一致。這種錯誤比少一個建議欄位更麻煩，因為它會直接破壞信任訊號。

交易政策層級：ShippingDetails、MerchantReturnPolicy

交易政策層級用來補足商品購買前最重要的條件：怎麼送、送到哪裡、運費怎麼算、能不能退、幾天內能退。台灣電商常見的宅配、超商取貨、離島配送、免運門檻與退貨天數，都應先在頁面清楚呈現，再判斷是否放入 ShippingDetails 或 MerchantReturnPolicy。

Product Schema 欄位怎麼寫：商品頁最小可行清單

Product Schema 最小可行清單包含 name、image、description、brand、sku 或 gtin，以及 offers 裡的 price、priceCurrency、availability、itemCondition 與 url。台灣商品頁應明確使用 TWD，且價格與庫存必須和頁面、後台與 Merchant Center feed 保持一致。

必要欄位與建議欄位

Google 的 Merchant listing structured data 文件指出，Product markup 可讓商品頁有資格出現在商家刊登相關搜尋體驗中，且 merchant listing 可凸顯價格、庫存、配送與退貨資訊。工程實作時，先完成必要欄位，再補高價值建議欄位。

Offer 欄位：TWD、價格、庫存、商品狀態

Offer 是商品頁最容易出錯的區塊，因為價格、庫存與商品狀態都會變動。台灣站應使用 priceCurrency: TWD，availability 需依頁面狀態對應 InStock、OutOfStock、PreOrder、BackOrder 或 Discontinued，不能讓 Schema 顯示有庫存但頁面顯示缺貨。

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "玻尿酸保濕精華 30ml",
  "image": [
    "https://www.example.com/images/hyaluronic-serum-1x1.jpg",
    "https://www.example.com/images/hyaluronic-serum-4x3.jpg"
  ],
  "description": "適合日常保濕使用的精華液，商品頁需顯示同一段核心描述。",
  "brand": {
    "@type": "Brand",
    "name": "Example Beauty"
  },
  "sku": "HB-SERUM-30",
  "gtin13": "4712345678901",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/products/hyaluronic-serum",
    "priceCurrency": "TWD",
    "price": "980",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": {
      "@type": "Organization",
      "name": "Example Beauty"
    }
  }
}
</script>

圖片欄位：不只是塞 image URL

image 欄位應放可檢索、可索引、代表商品本體的圖片 URL。Google 文件建議商品圖片要能代表被標記內容，且可提供多種比例與高解析圖片；對電商來說，主圖、白底圖、情境圖都可以用，但不能用與商品不符的廣告合成圖。

• 圖片 URL 不應被 robots.txt、登入牆或防盜連擋住。
• 主圖要對應實際商品，不要只放品牌 Logo 或分類示意圖。
• 變體商品若有顏色差異，圖片應對應目前 URL 或目前選定變體。
• 圖片更換後，Schema、頁面主圖與 Merchant Center feed 應同步。

AggregateRating / Review：什麼可以標、什麼不能標

AggregateRating 與 Review 只能標記頁面上真實可見、可被使用者查核的評論與評分。沒有評論就不要放 AggregateRating，只有品牌整體評分也不要硬套到單一商品，這是我在電商 SEO 健檢中最常要求移除的風險欄位之一。

後台欄位如何對應 Schema.org 欄位

電商 Schema 的品質取決於後台資料源，不取決於前端模板寫得多漂亮。商品主檔、PIM、ERP、CMS、價格系統、庫存系統、配送政策與退貨政策，必須先有明確欄位責任，再輸出到 Product Schema 與 Offer。

商品主檔對應表

商品主檔是 Product Schema 的核心資料源。若商品名稱、品牌、SKU、條碼、規格、圖片、描述分散在不同後台，應先指定哪個系統是最終來源，避免同一商品在頁面、Schema 與 feed 出現三種版本。

價格與促銷資料對應表

價格欄位要以商品頁目前可見、可購買的價格為優先。原價、特價、會員價、活動價都可能存在，但 Schema 不應輸出使用者在頁面無法取得或未登入看不到的價格，除非頁面清楚說明適用條件。

庫存與商品狀態對應表

庫存狀態應由可購買性決定，而不是只看倉庫是否還有一件。安全庫存、已保留庫存、門市庫存與電商可售庫存不同，Schema 的 availability 應對應前台使用者能否下單。

配送、退貨、發票資料來源

配送與退貨欄位通常不在商品主檔，而是在物流規則、政策頁、客服設定或平台後台。宅配、超商取貨、離島配送、退貨天數與電子發票可以在頁面清楚說明；Schema 只標記能被準確結構化的部分。電子發票通常屬於購買流程與政策說明，若沒有合適欄位，不需要勉強塞進 Product Schema。

變體商品、多 SKU、組合包要怎麼標

變體商品要先判斷每個 SKU 是否有獨立 URL、獨立價格、獨立庫存與獨立圖片。若每個變體都可被單獨選取與購買，應用 Product variant structured data 的思路處理；若只是頁面內選項，則要確保目前選定變體與 Schema 一致。

Google 的 Product variant structured data 文件指出，變體標記可協助 Google 理解哪些商品屬於同一個父商品群組。實務上最怕的是一個 URL 顯示紅色商品，JSON-LD 卻輸出藍色 SKU 的價格與庫存。

每個變體都要一個 Product 嗎？

每個變體不一定都要一個完整 Product，但每個可獨立銷售、獨立庫存、獨立 URL 的 SKU 應被清楚表示。若商品有父層與子變體，可評估使用 ProductGroup、hasVariant、isVariantOf 或 inProductGroupWithID。

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "機能外套 黑色 M",
  "sku": "JACKET-BLK-M",
  "color": "黑色",
  "size": "M",
  "isVariantOf": {
    "@type": "ProductGroup",
    "name": "機能外套",
    "productGroupID": "JACKET-2026",
    "variesBy": ["https://schema.org/color", "https://schema.org/size"]
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "TWD",
    "price": "2680",
    "availability": "https://schema.org/InStock"
  }
}

缺貨、預購、補貨通知、停售商品

缺貨商品可以保留 Product Schema，但 availability 必須反映前台狀態。預購、補貨通知與停售不是同一件事，若全部標成 InStock，短期看似完整，長期會讓價格庫存一致性變成風險。

組合商品與加購品

組合商品要標記使用者實際購買的主商品組合，不要把贈品、加購品、滿額禮都混成同一個 Product。若組合包有獨立 SKU、獨立價格與獨立商品頁，可以作為一個 Product；若只是購物車規則或短期活動，優先在頁面說明，不要讓 Schema 承擔訂單規則。

台灣電商平台的 Schema 檢查清單

Shopify、SHOPLINE、WooCommerce、91APP、Cyberbiz、WACA 多半會有部分預設 Schema，但預設不等於完整。平台店家應檢查商品頁是否有 Product、Offer、價格 TWD、庫存、圖片、BreadcrumbList，以及是否重複輸出互相矛盾的 JSON-LD。

Shopify / WooCommerce

Shopify 與 WooCommerce 的 Schema 風險通常來自佈景主題、SEO 外掛、評論外掛與商品外掛同時輸出 JSON-LD。我的實務建議是先檢查原始碼與 Rich Results Test，再決定要改 theme、關閉外掛輸出，或由自訂程式集中管理。

• 預設常見有：Product、Offer、Organization、BreadcrumbList 的部分輸出。
• 常缺：配送政策、退貨政策、變體一致性、評論欄位正確對應。
• 要工程補：重複 JSON-LD 整併、會員價排除、變體 URL 與 canonical 對齊。

SHOPLINE、91APP、Cyberbiz、WACA

台灣 SaaS 平台的重點不是比較誰排名比較好，而是確認後台欄位能不能輸出到正確 Schema。若平台預設欄位有限，店家至少要問清楚商品名稱、品牌、SKU、GTIN、價格、庫存、評論、配送與退貨政策各自從哪裡輸出。

如何檢查頁面是否重複輸出 JSON-LD

重複輸出 JSON-LD 的排查方式很直接：看原始碼、看渲染後 DOM、跑 Rich Results Test，再比對每一段 Product 的 name、sku、price、availability 是否一致。如果同一頁出現兩份 Product，一份 TWD 980、一份 TWD 1280，應先停下來修模板，不要只看工具是否通過。

1. 開啟商品頁，檢視原始碼並搜尋 application/ld+json。
2. 用瀏覽器開發者工具檢查渲染後 DOM 是否又注入一份 JSON-LD。
3. 把 URL 放入 Rich Results Test，確認偵測到幾個 Product。
4. 比對每個 Product 的 name、sku、price、availability。
5. 移除外掛、佈景或客製碼中重複且不準確的輸出。

Schema、Merchant Center 與 AI 購物引用的關係

Schema、Merchant Center 與 AI 購物理解都依賴穩定的商品屬性，但 Schema 不保證排名，也不保證 AI 搜尋引用。它的價值在於讓商品名稱、品牌、規格、價格、庫存、圖片、評論與政策更容易被機器正確理解與交叉驗證。

商品摘要與 Merchant listing 差在哪裡

Google 的 Product structured data 說明中，Product snippet 偏向商品摘要，Merchant listing 則偏向可購買商品頁，能承接更細的商品、配送與退貨資訊。電商自有站通常應優先滿足 Merchant listing 的資料需求，因為商品頁本身就是購買頁。

價格與庫存一致性為什麼會影響購物曝光

價格與庫存一致性會影響 Google 對商品資料的信任。若頁面顯示 TWD 980，Schema 顯示 TWD 1280，Merchant Center feed 又顯示缺貨，系統很難判斷哪個資料才是目前可購買狀態。我的判斷是，電商 Schema 的維護成本主要不在初次上線，而在促銷、缺貨、預購與檔期切換時的同步。

AI 搜尋如何使用商品屬性理解商品

AI 搜尋不需要被寫成玄學。商品屬性越完整，包含品牌、SKU、GTIN、規格、圖片、真實評論、TWD 價格、庫存、配送與退貨政策，系統越容易判斷商品是什麼、能不能買、適合什麼情境、與同類商品有何差異。這只能提高可理解性與資料可信度，不能保證 AI 摘要一定引用。

上線前與上線後驗證 SOP

電商 Schema 驗證要分成上線前單頁測試與上線後監控。上線前用 Rich Results Test、Schema Markup Validator 檢查語法與資格；上線後用 Search Console、Merchant Center 診斷與抽樣爬查確認模板沒有在價格、庫存與評論上漂移。

上線前：單頁測試

單頁測試的目標是抓語法錯誤、必填欄位缺漏、頁面可見內容不一致與重複 JSON-LD。不要等全站部署後才發現商品模板把所有商品都輸出同一個 SKU。

1. 選 3 種商品頁測試：現貨、缺貨、預購。
2. 用 Rich Results Test 檢查 Product 與 Offer 是否被偵測。
3. 用 Schema Markup Validator 檢查 schema.org 語法。
4. 人工比對頁面文字、價格、庫存、圖片、評論與 JSON-LD。
5. 檢查原始碼與渲染後 DOM，確認沒有重複或矛盾輸出。

上線後：Search Console 與 Merchant Center

上線後要看 Search Console 的商品摘要與 Merchant listings 報告，也要看 Merchant Center 的價格、庫存與商品資料警示。建議每週檢查錯誤與警告，每月抽樣高曝光與高營收商品，確認活動價、缺貨、預購與退貨政策沒有失準。

批次錯誤排查優先順序

大站不要用逐頁修法處理 Schema 錯誤，應先找模板問題與資料源問題。若同一類錯誤出現在大量商品，通常是佈景、外掛、後台欄位映射或價格庫存同步造成。

常見錯誤：哪些 Schema 做了反而沒有幫助

錯誤的 Schema 可能不會帶來幫助，還會讓搜尋系統降低對頁面資料的信任。最常見的問題是標記頁面看不到的內容、假評論、價格錯誤、重複輸出、缺品牌、缺 SKU，以及平台預設 Schema 沒有和實際商品資料同步。

頁面看不到的資訊不要標

Schema 必須描述頁面上的真實內容。頁面看不到的價格、庫存、評論、退貨條件、配送費用，不應只藏在 JSON-LD 裡。這條紅線很清楚：使用者看不到、無法查核、或與頁面主內容衝突的資訊，不應成為結構化資料。

平台預設 Schema 不完整不是沒效，而是訊號不足

平台預設 Schema 不完整，不代表完全沒效。它通常能提供基本商品名稱、價格與圖片，但在品牌、SKU、GTIN、變體、評論、配送、退貨與重複輸出上容易不足。平台店家的重點是補欄位與修一致性，而不是把平台預設全部推翻重寫。

Schema 不是排名保證

Schema 能協助搜尋系統理解頁面，並讓頁面有資格爭取某些複合式搜尋結果，但它不是排名保證。Google 文件也將結構化資料定位為提供明確線索與搜尋結果增強資格，而不是直接保證排名。我的判斷是，電商 Schema 最實際的價值在於降低商品資料被誤解的機率，並讓高品質商品頁有更好的展示條件。

Out of Scope：本文不處理的內容

電商 Schema 的邊界是搜尋語義與商品資料對應，不處理完整電商資料庫 ERD、金流串接、倉儲管理、廣告投放策略或 Merchant Center 完整操作教學。若要建立穩定架構，優先完成五件事：Product / Offer、BreadcrumbList、資料源一致性、平台重複檢查、Rich Results Test 與 Search Console 監控。延伸閱讀可連到 結構化資料 / Schema Markup 完整指南，再分流到 Product Schema、FAQ Schema 與 Search Console 商品摘要錯誤修復主題。