Schema 結構化資料教學：JSON-LD 入門與驗證

發佈 2026-11-03 · 更新 2026-11-02 · 閱讀約 7 分鐘 · AI 工作術（法芮可有限公司）

這篇 schema 結構化資料教學講清楚幾件事：為什麼選 JSON-LD，Article、FAQ、Product 三種最常用的標記怎麼寫、哪些欄位必填，以及怎麼用複合式搜尋結果測試、Schema Markup Validator 與 Search Console 驗證上線，最後整理常見錯誤。

想學 schema 結構化資料，先記結論：格式一律用 JSON-LD，文章頁掛 Article，商品頁掛 Product，頁面上真的有問答才掛 FAQPage。寫完先用 Google 的複合式搜尋結果測試和 Schema Markup Validator 各跑一次，上線後固定看 Search Console。大多數網站做到這裡就夠了。

結構化資料不會直接把排名推上去，Google 官方也一直這樣講。它有兩個用處。第一，搜尋結果有機會出現星等、價格、庫存這類複合式結果，點擊率會差很多。第二，Google 和各家 AI 搜尋能更準確看懂「這頁在講什麼、誰寫的、賣多少錢」。在 AI 搜尋分走流量的時代，第二點只會越來越重要。

下面直接給三種標記的範本、必填欄位、驗證流程，還有我們自己做內容產線時踩過的坑。

結構化資料是什麼？為什麼一律選 JSON-LD

結構化資料就是用 schema.org 這套共用詞彙，把頁面內容寫成機器讀得懂的格式。同樣是「680」，人一看就知道是價格，爬蟲不一定看得出來。標成 "price": "680"、"priceCurrency": "TWD" 之後，就不會被誤讀了。

寫法有三種，Google 都支援，但官方建議用 JSON-LD：

格式寫在哪維護難度建議
JSON-LD獨立一段 script，放 head 或 body 都可以低，和版型分開首選
Microdata屬性直接寫在 HTML 標籤裡高，改版型容易弄壞舊站沿用即可
RDFa同樣寫在 HTML 屬性裡高不建議新做

JSON-LD 最大的好處是和畫面完全分開。前端改版不會動到標記，後端也能直接從資料庫欄位產生。但有一條鐵律：標記的內容必須是頁面上看得到的。頁面上沒有任何評價卻標了 4.9 顆星，輕則不顯示，重則被 Google 人工處置。

Article 怎麼掛：部落格、知識庫的基本款

Article 標記重點:headline 要和頁面 h1 標題一致、日期用 ISO 8601 並帶 +08:00 時區、dateModified 只在內容實質改動時更新、author 附 url 連到作者介紹頁、image 用絕對網址的封
Article 標記重點

Article 沒有硬性必填欄位，但下面這幾個建議都填：

  • headline：標題，和頁面上的 h1 一致
  • image：封面圖，用絕對網址
  • datePublished／dateModified：用 ISO 8601 格式並帶時區，台灣是 +08:00
  • author：作者，type 用 Person 或 Organization，附上 url 指向作者介紹頁
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema 結構化資料教學",
  "image": ["https://example.com/cover.jpg"],
  "datePublished": "2026-11-03T09:00:00+08:00",
  "dateModified": "2026-11-03T09:00:00+08:00",
  "author": [{
    "@type": "Person",
    "name": "王小明",
    "url": "https://example.com/about"
  }]
}
</script>

新聞網站可以改用 NewsArticle，一般部落格用 BlogPosting 或 Article 都行，差別不大，不用在這裡花時間。

dateModified 是最多人亂填的欄位。有些系統每次重新部署，就把所有文章的日期改成當天，等於告訴 Google 每篇都剛改過，久了這個訊號就沒有參考價值。只有內容真的改了才更新。author 的 url 則和 E-E-A-T 有關，讓作者頁和文章互相連得起來，比只寫一個名字有用。

再進階一點，可以用 @graph 把 Organization、WebSite、Article 放在同一段，再用 @id 互相引用。整站「誰寫的、屬於哪個品牌」的關係會更清楚，對 GEO 優化也有幫助。

FAQPage 怎麼掛：先搞清楚現在還能換到什麼

先講實話：Google 從 2023 年起，只對知名的政府和醫療網站顯示 FAQ 複合式結果。一般商業網站就算掛了，搜尋結果裡也幾乎看不到展開的問答。網路上還在說「掛 FAQ 就能多佔兩行版面」的教學，已經過時了。

那還要不要掛？我們的做法是：內容裡本來就有問答就掛，不要為了掛而硬寫問答。FAQPage 把問題和答案的對應寫得很明確，AI 搜尋擷取答案時比較好抓，而且幾乎不花成本。我們這個知識庫每篇文章最後的常見問題，都用固定格式寫，再由系統自動轉成 FAQPage，不用另外手動維護一份 JSON。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "JSON-LD 要放在 head 還是 body？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "兩邊都可以，Google 都讀得到。"
    }
  }]
}
</script>

掛 FAQPage 的四條規矩：

  • 問題和答案要和頁面上的文字一致，不能標記隱藏起來的內容
  • 一個問題有多位使用者各自回答的頁面（論壇、問答社群），要用 QAPage，不是 FAQPage
  • 一頁放一段 FAQPage 就好，不要在好幾個區塊重複標記
  • 純廣告的問答（「為什麼選我們最划算？」）不建議標

Product 怎麼掛：電商最該先做的一種

Product 標記三大地雷:標記的價格必須和頁面售價一致、幣別寫 TWD，不是 NTD、平台內建加上外掛會變兩份衝突、沒有真實評價就不放星等
Product 標記三大地雷

如果你做電商，Product 的效益最高，星等、價格、庫存可以直接出現在搜尋結果上。Google 把商品結果分成兩種情況：只有評測內容的頁面（商品摘要），以及可以直接下單的頁面（商家資訊）。可以下單的頁面要求比較嚴，欄位細節以 Google Search Central 官方文件為準。

欄位用途重要程度
name商品名稱必填
offers（price、priceCurrency、availability）價格、幣別、庫存可下單頁面必備
image商品圖強烈建議
aggregateRating／review星等與評價有真實評價才放
sku、gtin、brand辨識是哪一件商品建議，有國際條碼就填 gtin
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "手沖咖啡濾杯 02",
  "image": ["https://example.com/dripper.jpg"],
  "sku": "DRP-02",
  "brand": { "@type": "Brand", "name": "範例咖啡" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/p/drp-02",
    "price": "680",
    "priceCurrency": "TWD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "128"
  }
}
</script>

最常見的三個坑：

  1. 價格和頁面對不上：頁面顯示特價 590，標記還是原價 680。或是幣別寫成 NTD，正確的 ISO 4217 代碼是 TWD。
  2. 同一頁有兩份標記：不少開店平台和佈景主題（例如 Shopify 的許多主題）已經內建 Product 標記，你再裝外掛或自己貼一段，頁面上就有兩組互相衝突的資料。動手前先用驗證工具看現況。
  3. 評價造假或搬運：從別的平台複製評價，或把星等寫死在模板裡，都違反規範。沒有評價，就不要放 aggregateRating。

驗證工具與上線流程：三個工具各管一段

驗證工具怎麼分工:上線前：每個模板跑複合式結果測試、查語法拼字：Schema Markup Validator、上線後：每週看 Search Console 報表、每次改版後一定重跑驗證
驗證工具怎麼分工
工具檢查什麼什麼時候用
複合式搜尋結果測試（Rich Results Test）這頁能不能拿到 Google 支援的複合式結果，列出錯誤與警告上線前，每種模板測一次
Schema Markup Validator（validator.schema.org）語法和 schema.org 詞彙對不對，不限 Google 支援的類型用到 Google 不支援的類型，或要查欄位名稱有沒有拼錯時
Google Search Console已檢索頁面的結構化資料狀態，以及錯誤數量的變化上線後每週看一次

建議的上線流程：

  1. 先決定每種頁面模板（文章、商品、分類）要掛哪些類型，列成一張表
  2. 從資料庫欄位自動產生 JSON-LD，不要每頁手動貼
  3. 每個模板挑一頁，用複合式搜尋結果測試跑過，錯誤一定要修，警告視情況處理
  4. 上線後，在 Search Console 用網址檢查功能，對幾個重要頁面要求重新建立索引
  5. 之後固定看 Search Console 報表，錯誤數突然增加，通常是某次改版弄壞了模板

第五步最常被漏掉。結構化資料最常見的壞法，不是一開始就寫錯，而是三個月後改版時壞掉卻沒人發現。頁面看起來一切正常，所以沒人察覺。我們經營工具站也遇過一樣的問題：標記跟著模板走，模板一改就要重新驗證。所以我們把這一步寫進上線檢查清單，不靠人記。

常見問題

Q：結構化資料會直接提升 Google 排名嗎？
不會，Google 官方明確說過結構化資料不是排名因素。它的效果是間接的：拿到星等、價格這類複合式結果後點擊率會提高，搜尋引擎也更容易看懂你的頁面。把它當成讓機器讀懂網站的基本功，而不是衝排名的捷徑。

Q：叫 ChatGPT 幫我寫 JSON-LD 可以嗎？
可以，打草稿很快，但一定要丟進驗證工具跑過。AI 常見的錯是編出不存在的屬性名稱、日期少了時區，或把頁面上沒有的評分也寫進去。最穩的做法是讓 AI 寫模板，數值由系統從資料庫帶入。如果你在意 AI 搜尋怎麼讀你的網站，也可以一起看 llms.txt 實戰。

Q：JSON-LD 要放在 head 還是 body？用 JavaScript 動態插入可以嗎？
head 或 body 都可以，Google 都讀得到。用 JavaScript 動態插入 Google 也能處理，但要多經過一道渲染，而且其他搜尋引擎和不少 AI 爬蟲不一定會執行 JavaScript。能在伺服器端直接輸出，就盡量這樣做。

Q：掛好之後多久會出現在搜尋結果？
要等 Google 重新檢索那一頁，通常要幾天到幾週，可以用 Search Console 的網址檢查加快。另外，標記正確不代表一定會顯示，Google 會依搜尋字詞和網站品質決定要不要給複合式結果。

Q：一頁可以同時掛好幾種類型嗎？
可以。商品頁同時掛 Product 和 BreadcrumbList，文章頁同時掛 Article 和 FAQPage，都很常見。重點是每一種描述的都是頁面上真的有的內容，而且同一種類型不要出現兩份互相矛盾的資料。

← AI 知識庫 · AI 工具庫