WordPress Schema 結構化資料實作，文章、商品、FAQ、Breadcrumb 的設定與驗證

搜尋結果像一個櫥窗，同樣一篇文章或一個商品頁，有人只看到藍色標題，有人卻能在結果裡拿到星等、價格、庫存、麵包屑路徑，甚至 FAQ 展開。差別常常不在內容多寡，而在你有沒有把 WordPress 結構化資料 做對。

結構化資料不是魔法，也不保證一定出現 rich results，但它能把「你頁面上本來就有的重點」用搜尋引擎讀得懂的方式說清楚。2026 年實務上仍以 JSON-LD 最好維護，錯誤也比較少。想快速補觀念，可以先看一篇偏入門的整理，例如這篇網站結構化標記實作概念。

下面用兩條路線帶你完成文章、WooCommerce 商品、FAQ、Breadcrumb 的設定與驗證，同時把常見錯誤直接對照給你，方便上線前一次排乾淨。

實作前先抓住三個硬規則，少走很多冤枉路

第一個規則是結構化資料必須和頁面可見內容一致。你在 JSON-LD 寫了「特價 999」，頁面上卻顯示「1,199」，很容易被判定資料不可信。FAQ 也一樣，Q/A 必須真的出現在頁面上，不是藏在後台或用 JS 點擊後才載入的隱藏內容。

第二個規則是別重複輸出同一種 Schema。很多站會同時啟用佈景主題內建 Schema，加上 SEO 外掛又再輸出一次，結果變成 duplicate structured data。這種狀況不一定會立刻報錯，但 rich results 常常就不上，或是 Search Console 出現一堆提示，最後你還得回頭抓到底是誰輸出的。

第三個規則是用對類型，不要貪多。文章用 Article 或 BlogPosting，商品用 Product，FAQ 用 FAQPage，麵包屑用 BreadcrumbList。把欄位填完整，比塞十種不相干 Schema 更實在。若你希望外掛端的 Schema 設定更系統化，可以參考這篇偏 Rank Math 操作向的整理Rank Math Schema 與模組設定。

外掛路線，上線最快，但要知道去哪裡改什麼

外掛適合「先讓 80 分跑起來」，再針對電商與自訂欄位補強。以下以常見 SEO 外掛的介面習慣描述，實際名稱會因版本略有差異，但找法一致。

文章（Article 或 BlogPosting）

設定位置常見路徑

• 全站預設：SEO 外掛 → 標題與 Meta(或 Titles) → 文章類型(Posts) → Schema 類型
• 單篇覆寫：文章編輯器 → SEO 外掛區塊/側欄 → Schema(或 結構化資料)

實務提醒：作者名稱要和頁面作者區塊一致，日期要和文章顯示的發布或更新日期一致，不要一邊顯示「2023」一邊在 Schema 填「2026」。

WooCommerce 商品（Product）

設定位置常見路徑

• 外掛全域：SEO 外掛 → WooCommerce(或 商品) → Product Schema 開關
• 單品覆寫：商品編輯器 → 產品資料(Product data) 與 SEO 外掛的 Schema 區塊

WooCommerce 這裡最常踩雷的是「外掛抓到的資料是對的，但頁面顯示是錯的」。比方說你用變體商品，頁面預設顯示最低價，但 Schema 卻輸出最高價，或促銷結束了頁面已恢復原價，Schema 還留著促銷價。這些都會造成 invalid value 或資料不一致。

FAQ（FAQPage）

設定位置常見路徑

• 單頁建立：頁面或文章編輯器 → FAQ 區塊(或外掛 FAQ 模組) → 自動輸出 FAQPage Schema
• 注意：有些外掛要先在「模組 Modules」把 FAQ 啟用

FAQ 的底線很簡單：使用者在頁面上看得到問與答，搜尋引擎才會信。

Breadcrumb（BreadcrumbList）

設定位置常見路徑

• SEO 外掛 → 一般設定(General) → Breadcrumbs → 啟用
• 佈景主題端：在文章模板輸出麵包屑導覽(若外掛要求你插入短代碼或函式)

如果你的頁面麵包屑是「首頁 > 商店 > 外套」，Schema 也要是同一條路，不要自作主張改成「首頁 > 商品分類 > 外套」。

手動 JSON-LD 寫法，可直接貼用(含繁中註解鍵)

手動適合兩種情況：外掛輸出的欄位不夠，或你要避免外掛與主題打架。放置位置建議在該頁面 HTML 的 head(或頁面底部也可)，重點是每個頁面輸出對應自己的 JSON-LD。需要更完整的 WooCommerce 與 WordPress 結構化資料補充概念，可參考WordPress 與 WooCommerce 結構化資料做法。

文章 Article(或 BlogPosting)

{
  "@context": "https://schema.org",
  "@type": "Article",
  "_note": "必須與頁面可見標題、作者、日期一致",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/post-slug/"
  },
  "headline": "文章標題",
  "description": "文章摘要(建議與頁面 meta 描述一致或更精簡)",
  "image": [
    "https://example.com/wp-content/uploads/2026/02/cover.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "作者姓名"
  },
  "publisher": {
    "@type": "Organization",
    "name": "網站或公司名稱",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/wp-content/uploads/logo.png"
    }
  },
  "datePublished": "2026-02-10",
  "dateModified": "2026-02-10"
}

WooCommerce 商品 Product(單一價格示例)

{
  "@context": "https://schema.org",
  "@type": "Product",
  "_note": "name、price、availability 要和頁面顯示一致，缺貨就別硬寫 InStock",
  "name": "商品名稱",
  "image": [
    "https://example.com/wp-content/uploads/2026/02/product.jpg"
  ],
  "sku": "SKU-001",
  "brand": {
    "@type": "Brand",
    "name": "品牌名稱"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product/product-slug/",
    "priceCurrency": "TWD",
    "price": "1290",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

變體商品建議改用 AggregateOffer 表達價格區間，並讓頁面也呈現「最低價至最高價」或清楚的價格邏輯。促銷價要和 WooCommerce 的「促銷價格」一致，促銷結束要同步清掉。評論也要小心，aggregateRating 與 review 的內容必須來自該商品頁可見的真實評論，不要搬運第三方評分或自己填假星等，這最容易被判定不可信。

FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "_note": "Q/A 必須在頁面上看得到，文字要一致",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "問題 1：退貨流程怎麼走？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "你可以在收到商品 7 天內提出退貨申請，並依頁面說明寄回。"
      }
    },
    {
      "@type": "Question",
      "name": "問題 2：缺貨會補貨嗎？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "部分款式會補貨，會在商品頁更新到貨時間。"
      }
    }
  ]
}

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "_note": "路徑要與頁面麵包屑導覽一致",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首頁",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "商店",
      "item": "https://example.com/shop/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "外套",
      "item": "https://example.com/product-category/jackets/"
    }
  ]
}

驗證與除錯，從 0 到上線一次做完

上線前不要靠感覺，先做兩次驗證：一次用 Rich Results Test 看是否符合 rich results 資格，一次用 Search Console 看 Google 實際抓到什麼。

從 0 到上線檢查清單

1. 先決定每種頁型「由誰輸出 Schema」，主題或外掛只能選一個主力。
2. 文章確認作者、日期、精選圖片在頁面可見且一致。
3. 商品確認價格、幣別、庫存狀態、促銷價在頁面可見且一致。
4. 變體商品確認 Schema 價格邏輯和前台顯示一致。
5. FAQ 的每一題 Q/A 都在頁面上看得到，別用隱藏折疊內容騙。
6. Breadcrumb 的路徑與麵包屑導覽完全一致。
7. 跑 Rich Results Test，修到沒有 Error 再上線。
8. 上線後用 Search Console 重送 sitemap 或要求重新索引。

常見錯誤訊息通常集中在三類，先對照就能更快定位：

如果你想把「外掛自動」和「手動精準控制」結合，又不想花時間追重複輸出、欄位對不到、變體價格跑掉這種瑣事，可以把需求交給WPTOOLBEAR協助規劃頁型規則與落地驗證。把 Schema 做到一致、可驗證，rich results 才有機會穩定出現。最後問自己一句就好：你的結構化資料，真的有把頁面上看得到的資訊說清楚嗎？