Schema 結構化資料教學：SEO 標記、類型與檢查
Schema 結構化資料可以幫搜尋系統理解頁面類型、主體實體與 rich result 資格，但不能取代內容品質。這篇教你判斷 Article、FAQ、HowTo、Product、LocalBusiness、Breadcrumb 等 schema 何時該用，如何用 JSON-LD 實作與驗證。
Schema 結構化資料是什麼？
Schema 結構化資料是寫在網頁裡的標記，目的是讓搜尋系統更準確理解頁面類型、主體實體、作者、產品、問答、步驟與網站層級關係。它常用 JSON-LD 格式呈現，詞彙來源多半是 Schema.org，Google 則會依自己的支援規則判斷哪些標記能進一步觸發 rich results。
把 schema 想成給搜尋引擎看的資料標籤會比較準。正文是給人讀的，schema 是把正文裡已經存在的事實翻成機器比較好解析的格式。它可以降低理解成本，但不能替代內容品質、技術可爬取性、內部連結或品牌信任。
| 層級 | 主要工作 | 常見誤解 |
|---|---|---|
| 正文 | 讓讀者看懂主題與答案 | 只要 schema 有寫，正文就可以很薄 |
| Schema | 標記頁面類型與已出現的事實 | 加了就能保證排名或 rich snippet |
| 搜尋呈現 | Google 依資格、品質與查詢情境決定呈現方式 | 測試通過就一定顯示特殊結果 |
Google 的 結構化資料說明也把重點放在理解與搜尋功能資格，而不是把 schema 寫成單一排名按鈕。這是做 technical SEO 時最重要的邊界。
什麼頁面需要 schema
需要 schema 的頁面通常有清楚的主體、可見的事實欄位，以及 Google 或其他搜尋系統能使用的內容類型。文章頁、FAQ 區塊、教學步驟、商品頁、在地商家頁、麵包屑、作者頁和組織資訊頁，都比單純的薄內容頁更適合標記。
判斷順序要從頁面任務開始。這個頁面是在解釋一個主題、回答常見問題、教一套步驟、展示商品、介紹商家，還是只是一般形象頁？頁面任務不清楚，schema 也會跟著失焦。
- 頁面有明確主題與可見主體，適合 BlogPosting 或 Article。
- 頁面真的有問答區塊，才考慮 FAQPage。
- 頁面有連續步驟和明確完成結果，才考慮 HowTo。
- 頁面有商品名稱、價格、庫存或評價等欄位，才考慮 Product。
- 在地商家頁有地址、電話、營業時間與服務範圍，才考慮 LocalBusiness。
- 全站有清楚階層時，BreadcrumbList 幾乎是基本項。
如果頁面只是為了湊 SEO 字數，沒有清楚的事實欄位，先補內容與站內結構。Schema 應該標記已存在的資訊，不該拿來替空內容化妝。
JSON-LD 怎麼寫才不會過度標記
JSON-LD是 Google 建議使用的結構化資料格式，通常放在頁面 HTML 的 script 區塊或由前端模板注入。它的重點不是把所有欄位都塞滿，而是用最少且可信的欄位說清楚這個頁面的主體是什麼、由誰發布、主要內容類型是什麼。
一個穩定的 BlogPosting schema，通常會包含 headline、description、image、datePublished、dateModified、author、publisher、mainEntityOfPage、inLanguage、keywords、about 和 mentions。FAQPage 則必須和頁面上真的看得到的 FAQ 一致。
- 先列出頁面可見內容，包含標題、作者、日期、分類、FAQ、圖片與主實體。
- 再決定 schema type，不要一開始就套外掛預設。
- 只標記頁面看得到或模板能可靠提供的欄位。
- about 放主實體，mentions 放支援實體，沒有可信 sameAs 的弱實體可以不放。
- 部署後用測試工具確認語法與 Google 支援資格。
最常見的過度標記，是把服務頁硬標成 Product、把沒有步驟的文章標成 HowTo、或把頁面沒有出現的 FAQ 寫進 JSON-LD。這些做法短期看起來像優化，長期會降低 schema 可信度。
常見 schema 類型怎麼選
選 schema 前先看頁面任務和可見資訊，不是把所有類型都套上去。
schema 類型選擇要看頁面主要任務和可見內容，不是看哪個類型聽起來比較能拿曝光。Google 支援的 structured data 類型很多，但 SEO 文章和企業網站常用的其實集中在幾個類別。
| 類型 | 適合頁面 | 使用條件 |
|---|---|---|
| BlogPosting / Article | 文章、教學、觀點內容 | 有標題、作者、日期、主圖與正文 |
| FAQPage | 可見 FAQ 區塊 | 問題與答案必須真的出現在頁面上 |
| HowTo | 步驟式教學 | 有可完成的任務、步驟、工具或材料 |
| Product | 商品頁 | 有商品資料、價格、庫存或評論等欄位 |
| LocalBusiness | 在地商家或服務據點 | 有 NAP、營業時間、地區與服務資料 |
| BreadcrumbList | 有階層的網站 | 前端或 CMS 能穩定輸出麵包屑 |
| Organization / Person | 品牌、作者、關於頁 | 有一致的名稱、URL、sameAs 與描述 |
選錯類型比不做更麻煩。舉例來說，服務頁如果沒有價格、庫存或可購買商品，硬套 Product schema 只會讓語意變髒。這種頁面更常需要 Organization、Service 或清楚的內容結構，而不是追逐商品 rich result。
想查 Google 目前支援哪些搜尋功能，可以對照 Search Gallery。它不是 schema 全部詞彙表，而是 Google Search 可能使用的 structured data 功能清單。
AK Schema Entity Alignment Matrix：正文、schema 與 knowledge graph 對齊
這張圖把 schema 從單次標記改成內容、實體與驗證狀態的對齊契約。
AK Schema Entity Alignment Matrix是一張發布前檢查表，用來確認正文、schema type、主實體、about、mentions、sameAs、驗證工具與維護責任彼此一致。這能避免內容團隊寫一套，工程模板輸出另一套，最後 Google 看到第三套。
這個 matrix 的核心判斷很直接：schema 只能翻譯頁面已經清楚呈現的事實。如果頁面正文沒有說作者是誰，schema 裡卻寫了完整 Person。若頁面沒有產品價格，Product schema 卻填了價格欄位。這些都會讓 structured data 變成噪音。
| 檢查欄位 | 要回答的問題 | 失敗訊號 |
|---|---|---|
| 正文可見內容 | 讀者看得到這些事實嗎？ | schema 有，頁面沒有 |
| Schema type | 類型符合頁面任務嗎？ | FAQ、HowTo、Product 被濫用 |
| 主實體 | about 指向的主題是否唯一？ | about 放太多不相干概念 |
| mentions | 支援實體是否真的被討論？ | 為了塞關鍵字列一堆實體 |
| sameAs | 是否能幫助消歧？ | 指到錯誤品牌、錯誤人物或空泛頁 |
| 驗證狀態 | 語法和 Google 功能資格是否通過？ | 只在本機看起來正常，沒有正式驗證 |
| 維護責任 | 改標題、作者、FAQ 時誰同步 schema？ | 內容改了，schema 還是舊資料 |
在大型網站，這張表比「再加一個 schema 外掛」有用。外掛能產生標記，但不會知道你的內容策略、作者 entity、服務頁邊界和 topical map。這些需要 SEO、內容與工程共同維護。
Rich Results 能不能出現
Rich Results能不能出現，取決於 Google 是否支援該 structured data 類型、頁面是否符合內容與品質規範、查詢情境是否適合，以及 Google 當下是否選擇展示。測試工具通過只代表有資格被理解，不代表每次搜尋都會出現特殊樣式。
這也是為什麼「schema 會提升排名」這句話容易誤導。更準確的說法是，schema 可能讓頁面更容易被正確分類，並在某些查詢中取得更豐富的搜尋呈現。它影響的是理解、資格和呈現機會，不是直接把排名往上推。
- Article schema 可以補強文章標題、日期、作者、主圖和發布者。
- FAQPage 只有在頁面真的有 FAQ 且符合 Google 政策時才有意義。
- Product schema 需要真實商品資料，不適合硬套在一般服務頁。
- BreadcrumbList 幫助搜尋系統理解站內階層，也有機會影響 SERP 顯示。
- Organization 和 Person schema 更偏向 entity disambiguation，不應用 rich snippet 心態看待。
如果 rich result 沒出現，先檢查資格和品質，再看 Google Search Console 是否有 enhancement 報表或錯誤。相關報表的判讀可以接到 Google Search Console 教學，但本文的主軸仍是 schema 本身。
Schema 怎麼驗證
驗證 schema 要同時看語法、Google 支援資格、部署後的 Search Console 回報。
Schema 驗證要分三層：語法是否有效、Google 是否支援這種 rich result、部署後搜尋系統是否真的讀到。只跑一個測試工具不夠，因為 Schema.org 的合法性和 Google Search 的功能資格不是同一件事。
- 用 Schema Markup Validator檢查標記是否符合 Schema.org 語法。
- 用 Rich Results Test檢查 Google 支援的 rich result 資格。
- 部署到正式網址後，再測一次 live URL，不只測本機 HTML。
- 等待 Google 重新爬取後，在 Search Console enhancement 或索引相關訊息中觀察問題。
- 改 FAQ、作者、日期、產品欄位或模板時，把 schema 納入發布檢查。
若頁面本身還沒被正常爬取或索引，schema 測試通過也不代表搜尋能使用。這種情況要回到 爬取與索引診斷，先解決 Google 能不能看到頁面，再處理 structured data。
另一路常見問題是 canonical 指到別頁，導致 Google 使用的版本不是你測試的版本。這時要檢查 Canonical 標籤設定和 URL 結構設計，避免 schema 被放在非 canonical 頁面上。
CMS、Astro、WordPress 怎麼管理 structured data
成熟的 schema 流程會把欄位、模板和驗證責任固定下來，避免每篇文章靠人工記憶。
structured data 管理最好放在模板與內容欄位之間，而不是每篇文章手動貼一段 JSON-LD。WordPress 可以靠外掛快速上線，Astro 或自建站通常適合用模板從 CMS 欄位產生 schema，重點是讓內容更新時標記同步更新。
WordPress 的 Rank Math、Yoast 這類工具適合入門，但要檢查它們產出的 type 和欄位是否符合你的頁面。Astro、Next.js 或 Directus 這類自建內容系統，則應該把 title、description、cover image、author、date、FAQ、category、about 和 mentions 做成可控欄位，由模板統一注入 JSON-LD。
| 環境 | 建議做法 | 主要風險 |
|---|---|---|
| WordPress | 外掛產生基礎 schema，重要頁人工抽查 | 外掛預設和頁面任務不一致 |
| Astro / 自建站 | 模板由 CMS 欄位產生 JSON-LD | 欄位缺漏或部署後沒有重新驗證 |
| Headless CMS | 把 FAQ、作者、主圖、實體欄位結構化 | 內容編輯改正文，schema 沒同步 |
Schema 也會受網站技術品質影響。如果頁面很慢、圖片載入不穩、主內容被 JS 擋住，標記再完整也很難形成穩定搜尋品質。效能和體驗問題可以接到 PageSpeed Insights 教學，schema 則負責把頁面事實說清楚。
不確定網站 schema 該從哪裡開始？我們可以從頁面類型、CMS 欄位、GSC 報表與 topical map 一起檢查，找出哪些標記值得先做。了解我們的 SEO 顧問服務，看技術 SEO 和內容系統是否需要一起整理。
成熟的流程會把 schema 放進發文 gate，而不是等排名掉了才補。新文章發布、FAQ 更新、作者頁調整、產品欄位變更、網站改版和 canonical 變更，都是該重測 structured data 的時間點。
FAQ
Schema 結構化資料會直接提升排名嗎？
不應該把 schema 當成直接排名因素。它主要幫搜尋系統理解頁面類型、實體與可用欄位，並讓頁面有資格參與某些 rich results。排名仍取決於內容、技術、連結、使用者需求和整體品質。
JSON-LD、Microdata、RDFa 要選哪一種？
多數 SEO 情境建議用 JSON-LD，因為它比較容易由模板或 CMS 管理，也不需要把標記混進每個 HTML 元素。Microdata 和 RDFa 仍可用，但維護成本通常較高。
每篇文章都需要 FAQ schema 嗎？
不需要。只有頁面真的有可見 FAQ 區塊，且問題和答案對讀者有幫助時，FAQPage schema 才合理。為了 schema 硬塞 FAQ，常會讓文章尾段變得很水。
WordPress 外掛產生的 schema 可信嗎？
可以作為起點，但不能完全不查。外掛可能會依預設套用 Article、Organization、Breadcrumb 或 FAQ，你仍要確認 type、作者、日期、圖片、FAQ 和頁面內容一致。
Schema 和 Google Search Console 有什麼關係？
Schema 是頁面標記，Google Search Console 是觀察 Google 是否讀到問題的工具。部分 structured data 問題會出現在 GSC enhancement 報表，但 schema 的選型和實作仍要先在頁面和模板層處理。
Rich Results Test 通過就一定會顯示 rich snippet 嗎？
不一定。通過測試代表 Google 能解析並判斷有資格，但實際 SERP 是否顯示，還會受到查詢、裝置、頁面品質、政策和 Google 當下版位設計影響。
Product schema 可以用在沒有價格的服務頁嗎？
通常不建議。沒有價格、庫存、商品識別或可購買資訊的服務頁，硬套 Product schema 容易造成語意錯配。服務頁應先處理清楚的服務內容、案例、組織資訊和轉換路徑。
Organization schema 和 Person schema 要放在哪裡？
Organization 通常放在品牌、全站或關於頁相關 schema 裡，Person 則用於作者或專家實體。重點是跨頁使用一致的 @id、url 和 sameAs，讓搜尋系統能把同一個實體串起來。
Schema 寫錯會被懲罰嗎？
一般語法錯誤多半是標記失效或 rich result 資格消失。若刻意標記頁面不存在的內容、偽造評價或誤導搜尋系統，就可能被視為 spammy structured data，風險會高很多。
做 Schema 需要工程師嗎？
小型 WordPress 站可先用外掛完成基礎 schema，但自建站、Headless CMS、多語系網站或大量模板頁，通常需要工程師把 JSON-LD 接到資料欄位和部署流程，才不會每次改版都壞掉。