Schema Markup 實作教學：用 JSON-LD 做好結構化資料

Schema Markup 是什麼？和一般的 schema 有什麼不同？

Schema Markup 是用 Schema.org 詞彙描述網頁內容的結構化資料，主要目的是讓搜尋引擎更清楚理解頁面在說什麼。

「schema」這個字在搜尋結果裡很容易混在一起。工程師可能想到資料庫 Schema，前端或後端可能想到 JSON Schema，心理學內容也會談 schema。SEO 實作時要看的，是 Schema Markup，也就是放在網頁裡給搜尋引擎讀取的結構化資料。

這裡說的 schema 指的是 SEO 結構化資料

SEO 語境下的 schema，通常指用 Schema.org 的標準詞彙，把文章、作者、品牌、產品、FAQ、麵包屑等頁面資訊標記出來。Google 讀到這些標記後，可以用它輔助判斷頁面主題、內容類型，以及是否符合特定搜尋結果呈現資格。

我的判斷是，多數網站做 Schema Markup 失敗，不是因為程式碼太難，而是前面沒有先講清楚「這一頁到底是什麼」。頁面主體不清楚，後面的 JSON-LD 寫得再漂亮也只是格式正確。

Schema.org、JSON Schema、Database Schema 差在哪？

為什麼 Schema Markup 通常建議用 JSON-LD？

Schema Markup 通常建議用 JSON-LD，因為它和 HTML 內容分開，較容易維護，也符合 Google 對結構化資料實作的主流建議。

JSON-LD 的好處是乾淨。工程師可以把一段 <script type="application/ld+json"> 放進頁面，不需要在每個 HTML 標籤上加屬性。對內容團隊來說，也比較容易用欄位對照表檢查資料是否正確。

JSON-LD 的基本結構

JSON-LD 最基本會包含 @context 和 @type。前者指定詞彙來源，後者指定這段結構化資料描述的類型。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup 實作教學",
  "author": {
    "@type": "Person",
    "name": "Kevin Lin"
  }
}
</script>

@context 通常會使用 https://schema.org。@type 則要依頁面內容選擇，例如文章頁用 Article 或 BlogPosting，品牌資訊用 Organization，麵包屑用 BreadcrumbList。

JSON-LD 放在 head 還是 body？

JSON-LD 可以放在 <head> 或 <body>，重點是 Google 抓取與渲染頁面時能讀到，而且資料和頁面內容一致。

實務上，我偏好把全站共用的 Organization、WebSite 放在模板層，文章頁的 Article Schema 放在文章頁模板或後台欄位輸出。不要把重要 Schema 只放在使用者互動後才載入的位置，因為驗證工具看不到時，排查成本會拉高。

實作 Schema Markup 前，要先決定頁面類型

實作前要先判斷頁面類型，再選 Schema 類型。文章頁、產品頁、FAQ 頁與品牌頁需要的欄位不同，不能全部混在一起套用。

Schema Markup 的選型原則很直接：頁面上真的存在什麼內容，就標記什麼內容。這個原則比找最多屬性的範例更重要。亂疊多種 Schema，通常只會讓工程師、行銷和驗證報告一起混亂。

文章頁最常用：Article / BlogPosting

9iseo.com.tw 這種 SEO 知識型文章，通常會以 Article 或 BlogPosting 為主。標記重點是讓搜尋引擎知道這是一篇文章，作者是 Kevin Lin，發布者是 9iseo，並且能對應到頁面上的標題與日期。

如果文章頁沒有顯示作者，卻在 JSON-LD 裡硬填作者，會造成內容不一致。比較穩的做法是先把前台文章資訊補齊，再輸出結構化資料。

網站基礎：Organization、WebSite、BreadcrumbList

Organization、WebSite、BreadcrumbList 是網站基礎型 Schema。它們不需要每篇文章都手工寫一次，適合放在全站模板或固定元件中。

FAQPage 何時該用、何時不要用

FAQPage 只適合用在頁面真的有 FAQ 區塊，而且每個問題都有單一明確答案的情況。為了搶搜尋結果版面而硬塞問答，長期看不是好做法。

• 可以用：文章底部有清楚 FAQ，問題與答案都對使用者可見。
• 可以用：品牌支援頁整理固定問答，且使用者不能提交多個答案。
• 不要用：頁面沒有 FAQ，只在 JSON-LD 裡暗藏問答。
• 不要用：論壇、社群討論串，使用者可以對同一問題提供多種答案。

Google 對 FAQ rich result 的顯示範圍已經比以前嚴格，尤其偏向特定高可信網站類型。FAQ Schema 仍可用來整理內容語意，但不該被當成流量保證。

JSON-LD Schema Markup 實作步驟

JSON-LD 實作順序是確認頁面主實體、選 Schema 類型、撰寫程式碼、放進 HTML、用工具驗證，再上線檢查。

Step 1：確認頁面主實體與內容範圍

先問一個問題：這一頁主要在描述誰或什麼？文章頁的主實體通常是文章本身，作者、發布者、主題是輔助資訊。產品頁的主實體才會是 Product，在地商家頁才會是 LocalBusiness。

• 確認頁面主題是否明確。
• 確認作者、發布日、更新日是否在頁面可見。
• 確認品牌名稱、網址、麵包屑是否和站內實際狀態一致。
• 不要把頁面沒有講到的服務、價格、評分塞進 Schema。

Step 2：選擇最符合頁面的 Schema 類型

選型時不要追求最多類型，而是選最能代表頁面用途的類型。教學文章通常從 Article 或 BlogPosting 開始，再視頁面是否有麵包屑加入 BreadcrumbList。

如果同一頁同時有文章、FAQ、麵包屑，可以放多段 Schema，但每段都要對應頁面上的真實區塊。我的實務判斷是，文章頁常見的穩定組合是 Article 加 BreadcrumbList，FAQPage 則看頁面是否真的需要。

Step 3：撰寫 JSON-LD 程式碼

先寫最小可用版本，再補建議欄位。不要一開始就複製大型 @graph 範例，因為欄位越多，出錯與內容不一致的機率越高。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首頁",
      "item": "https://9iseo.com.tw/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "文章",
      "item": "https://9iseo.com.tw/articles"
    }
  ]
}
</script>

Step 4：放進網頁 HTML

把 JSON-LD 放進頁面 HTML 的 <head> 或 <body> 皆可。常見做法是由網站後台或模板系統輸出，避免每篇文章手動貼錯。

1. 確認文章欄位有標題、作者、發布日、更新日。
2. 在文章頁模板輸出 Article JSON-LD。
3. 在有麵包屑的頁面輸出 BreadcrumbList。
4. 部署到測試環境後先驗證，再推到正式站。

Step 5：用工具驗證

發布前至少用 Google Rich Results Test 和 Schema Markup Validator 檢查。前者看 Google 支援的 rich result 資格，後者看 Schema.org 語法與解析結果。

• Google Rich Results Test：檢查 Google 可辨識的結構化資料與問題。
• Schema Markup Validator：檢查 Schema.org 結構與屬性解析。
• Google Search Console：上線後看 Google 是否抓到頁面與結構化資料狀態。

Article Schema JSON-LD 範例

Article Schema 的最小可用範例應包含文章標題、作者、發布者、發布日期、更新日期與網址，並且每個欄位都要能對應頁面內容。

最小可用 Article Schema 範例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://9iseo.com.tw/articles/schema-markup-json-ld"
  },
  "headline": "Schema Markup 教學：用 JSON-LD 實作結構化資料",
  "author": {
    "@type": "Person",
    "name": "Kevin Lin"
  },
  "publisher": {
    "@type": "Organization",
    "name": "9iseo",
    "url": "https://9iseo.com.tw/"
  },
  "datePublished": "2026-01-15",
  "dateModified": "2026-01-15"
}
</script>

這段範例刻意保持短。正式上線時，可以依頁面實際內容補上 image、about、description 等欄位，但不要補不存在的資料。

欄位怎麼對應頁面內容

常見 Schema Markup 錯誤與修正方式

常見 Schema Markup 錯誤包括 JSON 格式錯、必要欄位缺漏、結構化資料和可見內容不一致，以及期待富摘要一定出現。

JSON 格式錯誤

JSON-LD 最常見的語法錯誤是多一個逗號、少一個引號、括號沒有關好。這類問題不需要猜，用驗證工具通常很快就能定位。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup 教學",
}

上面最後一個欄位後方多了逗號，會造成 JSON 格式錯誤。修正後應移除尾端逗號。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup 教學"
}

Schema 內容和頁面可見內容不一致

結構化資料描述的內容，應該和使用者在頁面上看得到的內容一致。頁面沒有評論，就不要標 Review；頁面沒有價格，就不要標 Offer；頁面沒有 FAQ，就不要標 FAQPage。

這裡的風險不是只有驗證失敗而已。Google 的一般結構化資料指南明確要求標記內容要代表頁面內容，違反時可能失去 rich result 資格。行銷端要驗收 Schema，不該只看工具顯示綠燈，也要看前台內容是否對得上。

加了 Schema 卻沒有富摘要

加了 Schema 不代表搜尋結果一定會顯示富摘要。Schema 只能幫助 Google 理解頁面與判斷資格，最後是否顯示仍由搜尋系統依查詢、裝置、頁面品質與政策判斷。

• 頁面類型不符合 Google 支援的 rich result。
• Schema 有警告或缺少建議欄位。
• 頁面內容品質不足，Schema 只是補充，不能替代內容。
• 查詢本身不觸發該類搜尋結果呈現。
• FAQ 類型在目前 Google 搜尋中的顯示範圍受限。

Schema Markup 對 SEO 和 AI 搜尋有什麼幫助？

Schema Markup 的 SEO 價值在於幫助搜尋引擎理解頁面實體、內容類型與關係，但它不是直接排名保證。

在 2026 年的搜尋環境裡，結構化資料更像是網站的語意輔助層。它可以讓品牌、作者、文章、麵包屑、FAQ 等資訊更容易被機器解析。這和 GEO 生成式引擎優化、精選摘要優化、Google 排名因素 都有關，但不能把它當成單一解法。

Schema 幫助搜尋引擎理解，不是排名魔法

Schema 的主要功能是提供明確線索，例如這是一篇 Article、作者是 Kevin Lin、發布者是 9iseo、頁面位於文章分類下。這些線索有助於 entity understanding 和頁面分類。

如果文章本身沒有回答搜尋意圖，Schema 不會把內容變強。我的看法是，Schema 應該排在「內容已經完整、標題結構清楚、頁面可被正常抓取」之後處理。標題與段落架構可以搭配 H1 標題結構 一起檢查。

2026 年 AI 搜尋下的 Schema 角色

AI 搜尋與 AI Overviews 需要從網頁抽取可理解的實體與關係。Schema Markup 可以幫助品牌名稱、作者、文章主題、組織身分更清楚，但不會保證被 AI 引用。

對台灣網站來說，最有價值的是品牌消歧。像 9iseo 這類站點，如果全站都能穩定標記 Organization、Article、BreadcrumbList，搜尋系統比較容易把內容、作者與網站來源連在一起。這種基礎工作不性感，但很實用。

發布後如何檢查 Schema 是否被 Google 讀到？

發布後要用 Search Console 的 URL Inspection 和結構化資料報告檢查 Google 抓到的版本，不能只看本機或測試環境驗證結果。

用 URL Inspection 看 Google 抓到的版本

URL Inspection 可以檢查 Google 已索引版本與即時測試版本。若測試工具通過，但 Google 沒讀到，通常要回頭看頁面是否被正確渲染、是否被 robots 阻擋、canonical 是否指到別頁。

1. 在 Search Console 輸入文章 URL。
2. 查看 Google 已索引頁面的狀態。
3. 執行即時測試，確認目前頁面可被抓取。
4. 比對測試結果中的結構化資料項目。
5. 修正後再要求重新檢查或等待 Google 重新抓取。

看 Search Console 的結構化資料報告

Search Console 會依 Google 支援的結構化資料類型顯示有效、警告與錯誤狀態。這裡適合用來追蹤上線後的模板問題，尤其是大量文章共用同一套 Article Schema 時。

• Valid：目前可被 Google 解析的項目。
• Warning：不一定失效，但可能缺少建議欄位。
• Error：需要修正，否則可能不符合資格。
• 趨勢變化：若大量 URL 同時出錯，多半是模板或後台欄位輸出問題。

哪些情況不適合加 Schema？

頁面內容太薄、資料不存在、模板亂套、想用 Schema 包裝虛構資訊時，都不適合先加 Schema。

Schema Markup 是描述頁面內容的工具，不是補內容的工具。該頁沒有足夠內容，就先補內容；資料來源不可靠，就先整理資料；模板還不穩，就先修模板。硬上 Schema 只會讓錯誤更一致地出現在全站。

頁面內容不足時，先補內容再加 Schema

如果文章只有幾段概念說明，卻標了完整 Article Schema、FAQPage、HowTo、Review，搜尋引擎讀到的是形式，不是價值。真正該優先處理的是內容是否回答了搜尋者的問題。

• 頁面沒有清楚 H1，先整理標題。
• 文章沒有作者與日期，先補前台資訊。
• FAQ 問答只是為了塞關鍵字，先刪掉或重寫。
• 產品資料不完整，先補真實價格、庫存與規格。

沒有真實資料時，不要偽造評論、價格、FAQ

Review、Offer、FAQPage 這幾類最容易被濫用。沒有真實評論就不要填評分，沒有價格就不要填 Offer，頁面沒有問答就不要填 FAQPage。

短期看，偽造結構化資料好像只是多幾個欄位；長期看，它會降低網站資料可信度。SEO 技術不是用來美化不存在的內容，而是讓已存在的內容更容易被正確理解。

Schema Markup 實作順序結論

Schema Markup 的正確順序是先釐清頁面類型，再用 JSON-LD 標記真實內容，發布前驗證，發布後用 Search Console 追蹤。

• 先消歧：確認這裡講的是 SEO 的 Schema Markup，不是 JSON Schema 或資料庫 Schema。
• 先選型：文章頁優先 Article 或 BlogPosting，網站基礎可補 Organization 與 BreadcrumbList。
• 再寫碼：從最小可用 JSON-LD 開始，不要複製過度複雜的範例。
• 再驗證：用 Rich Results Test 和 Schema Markup Validator 檢查。
• 再上線：部署後用 Search Console 的 URL Inspection 和結構化資料報告追蹤。
• 守邊界：Schema 不保證排名，不保證富摘要，也不能標記頁面不存在的內容。