WordPress 結構化資料要先確認每種頁面代表什麼，再讓頁面可見內容、Schema 類型與欄位保持一致。外掛只是輸出工具，裝完不等於設定完成。首頁通常用 Organization 說明品牌主體，服務頁可用 Service 描述實際服務，文章頁用 Article 或 BlogPosting，階層導覽則用 BreadcrumbList。完成後還要測試實際網址、查看 Google 讀到的版本；測試通過，也不保證一定會出現複合式搜尋結果。
內容編輯：安佑編輯團隊｜預定更新：2026 年 8 月 25 日｜資料核對：Google Search Central、Schema.org 與 WordPress 官方開發文件
不知道從哪裡開始時，先找出結構化資料的「唯一輸出者」。它可能是 SEO 外掛、佈景主題、客製外掛或程式碼，但不要在沒盤點現況前四邊都開。檢查首頁、服務頁與文章頁實際輸出的 JSON-LD，再決定哪一份保留、哪一份補欄位、哪一份關閉。
結構化資料能做什麼？不能做什麼？
結構化資料是一種標準格式，用來把頁面中的人、組織、文章、服務、商品或導覽路徑說得更明確。它提供的是「額外線索」，不是替空白頁補內容，也不是排名開關。Google 官方也明確提醒：即使標記正確、通過 Rich Results Test，搜尋結果仍不保證顯示特殊版型。
實作順序很簡單：讀者先看得到，Schema 才跟著標。頁面沒有顯示作者，就不要在 Article 裡虛構一位作者；服務頁沒有公開服務地區，就不要硬填 areaServed；沒有真實可見的評價，也不要為了星等加入 rating。Schema 不該比頁面本身多出一批「未公開的事」。
先做頁型盤點：四種常見 Schema 怎麼分工
常見狀況是網站已有 Schema，卻每一頁都輸出同一套內容。這時先別急著加更多類型，依照頁面任務建立一張對照表會比較好查。以下用來判斷主要實體與輔助標記，不是要你在每一頁全部加上。
| 頁面類型 | 主要 Schema | 應對應的可見內容 | 上線前要確認 |
|---|---|---|---|
| 網站首頁 | Organization | 品牌名稱、Logo、官方聯絡方式、真實社群或品牌網址 | 名稱與 Logo 是否和首頁、關於頁一致 |
| 服務介紹頁 | Service | 服務名稱、內容、提供者、適用對象或服務地區 | 不要填頁面沒有公開的價格、地區或承諾 |
| 文章頁 | Article／BlogPosting | 標題、作者、發布與更新日期、代表圖片、文章主體 | 作者與日期是否跟畫面完全一致 |
| 有階層的內容頁 | BreadcrumbList | 讀者實際看得到、可理解的導覽路徑 | 路徑應反映典型使用路徑，不只是照抄網址 |
要特別區分「Schema.org 有這個類型」和「Google 目前支援這種複合式搜尋結果」兩件事。Service 是 Schema.org 的正式類型，可以描述服務與提供者關係，但它不代表 Google 一定會給服務頁特殊展示。若 Rich Results Test 沒把某個類型列成可預覽項目，不等於語法必然錯誤；此時還要檢查渲染後 HTML，並用 Schema.org 驗證工具查看結構。
Organization：把品牌主體放在首頁說清楚
Organization 適合用來描述網站背後的組織。Google 建議在首頁提供組織資料，幫助系統理解品牌的行政資訊並區分同名組織。實務上可從 name、url、logo 開始，再視網站真正公開的資料加入 telephone、email、address 或 sameAs。不是每個欄位都必填，重點是「適用、真實、一致」。
sameAs 只應連到確實代表這個品牌的官方資料頁或社群帳號。若 Facebook 粉專早已停用、名稱不同，或某個目錄頁不是由品牌維護，就不適合為了增加數量而塞入。Logo 也要用可抓取的正式圖片網址，並確認前台顯示的品牌名稱沒有一會兒寫公司全名、一會兒只剩無法辨識的縮寫。
Service：只描述頁面真的提供的服務
服務頁先把讀者會問的事交代清楚：服務內容是什麼、由誰提供、適合誰、要怎麼詢問。Service 可以使用 name、serviceType、provider、areaServed、audience 或 availableChannel 等屬性，但每一項都要有頁面內容可以對照。想搶哪個關鍵字，不能拿來代替這些基本資訊。
例如，一個「WordPress SEO 顧問」頁面若只說提供網站健檢與內容規劃，就不該自行標記成保證排名、全台到府或固定價格方案。若服務範圍會依專案確認，可以在頁面明白說明「服務方式與範圍於諮詢後確認」，結構化資料也只填已確定的部分。這樣比填滿欄位更可靠。
Article：作者、日期與圖片最容易前後不一致
Article 或 BlogPosting 應描述當前這篇文章。常見資料包含 headline、image、datePublished、dateModified、author 與 publisher。Google 對作者資料的建議很具體：頁面顯示幾位作者，標記裡就應對應幾位；人用 Person，組織用 Organization；author.name 只放作者名稱，不要把「撰文」、「總編輯」或公司名稱全部黏在同一個字串。
日期也要特別小心。若前台只顯示發布日，Schema 卻每天自動改 dateModified，讀者會看不到變更依據。反過來，文章已進行實質更新，前台和結構化資料仍停在舊日期，也會造成資訊不同步。網站應先定義什麼程度的修改才算更新，再讓畫面與資料一起變動。
BreadcrumbList：呈現讀者理解的路徑
麵包屑不是把完整網址切成幾段就好。Google 建議使用可代表典型使用路徑的導覽。例如「首頁 › SEO 服務 › WordPress SEO」比「首頁 › product › custom」更容易讓人理解。每一層要有明確名稱與可用網址，並與頁面可見的麵包屑或導覽關係一致。
若同一篇內容可能從不同分類抵達，不需要把每條路徑都硬塞進畫面。先決定網站真正採用的主分類與內容歸屬，再讓內部連結、麵包屑與 BreadcrumbList 指向相同方向。這會比事後用 Schema 修補混亂分類更有效。
WordPress 實作前，先找出誰正在輸出 JSON-LD
WordPress 的結構化資料可能來自 SEO 外掛、WooCommerce、佈景主題、區塊外掛或客製程式。請在未登入狀態開啟首頁、服務頁與文章頁，查看原始碼並搜尋 application/ld+json、schema.org、@type。把每一段的輸出來源、適用頁型與主要 ID 記下來。
看到兩段 Organization 不代表一定錯，但你必須確認它們是不是同一個實體、資料有沒有衝突、是否使用一致的 @id。如果一段把品牌名稱寫成「安佑」，另一段寫成不同公司；一段 Logo 是新版，另一段仍用舊圖，這才是需要處理的訊號。不要只用「數量很多」判斷好壞。
外掛、自訂外掛或程式碼：怎麼選？
| 做法 | 適合情況 | 優點 | 主要風險與驗證 |
|---|---|---|---|
| SEO 外掛管理 | 一般企業站、文章類型單純 | 更新與欄位映射較集中 | 檢查佈景主題是否重複輸出，並逐頁測試 |
| 功能型外掛補充 | 服務、活動或客製內容類型較多 | 可針對頁型設定條件 | 確認不會覆蓋既有 Article、Organization |
| 客製小外掛 | 欄位來源明確、需要工程控管 | 版本可追蹤，較不受佈景主題更新影響 | 要處理跳脫、條件、快取與回歸測試 |
| 子佈景主題程式 | 既有團隊已用子佈景主題管理 | 可配合版型資料輸出 | 換主題時要移交，避免直接改母主題 |
若採客製方式，WordPress 官方的 wp_head Hook 可以在前台 head 區域輸出腳本或資料；但這只是可用的掛載點，不代表把任何 JSON 貼進去就會正確。實作仍要根據頁型加條件、從正式欄位取值、做安全輸出，並避免主題或外掛更新後出現第二份標記。
7 步實作流程：從頁型盤點到發布監看
- 列出頁型：首頁、關於頁、服務頁、文章、分類、商品與其他客製頁。
- 確認可見資料：每種頁面有哪些真實且公開的名稱、作者、日期、圖片、服務內容與路徑。
- 盤點既有輸出：找出外掛、主題與客製碼目前輸出的 JSON-LD。
- 指定唯一責任：決定哪個系統負責 Organization、Article、Service 與 BreadcrumbList。
- 先測少量頁面：每種頁型挑一到兩頁，不要一開始全站開啟。
- 驗證實際網址：檢查 Rich Results Test、渲染後 HTML 與 URL Inspection。
- 發布後監看：留意 Search Console 可用的強化項目報告、頁面更新與外掛版本變動。
實作案例：企業服務站該怎麼拆？
假設一個企業網站有首頁、關於頁、三個服務頁與二十篇文章。首頁先用 Organization 描述品牌主體；三個服務頁各自用 Service 說明該頁服務，不把所有服務塞成同一個模糊項目；文章則依實際作者、日期與代表圖片輸出 Article。所有深層頁面都可以依可見導覽提供 BreadcrumbList。
接著替主要實體建立穩定識別。首頁的 Organization 可使用固定 @id，例如首頁網址加上 #organization；服務頁的 provider 再指向同一個組織識別，別在每一頁重新創造一間公司。這樣做是為了避免同一品牌在不同頁面出現名稱、Logo 或網址不一致，和程式碼看起來複不複雜無關。
若網站另有「團隊」頁，只有在頁面真的列出成員、職務與資料時，才考慮使用 Person 描述個別人物。沒有公開人物資料，就維持組織編輯或品牌發布者的真實做法。千萬不要為了看起來專業，替內容虛構顧問、審稿者或專業證照。
抽樣階段先挑四個代表網址：首頁一頁、服務一頁、一般文章一頁、分類較深的文章一頁。確認原始碼只有預期的主要實體、Rich Results Test 沒有關鍵錯誤、渲染後 HTML 仍能讀到資料，再擴大到同類頁面。按頁型抽樣，比全站一起開啟後才找錯誤更容易追查來源。
驗證時不要只看一個綠色勾勾
Rich Results Test 適合檢查 Google 支援的複合式搜尋結果類型與主要技術錯誤。若測試 Service 等未提供特殊展示的類型，可再用 Schema Markup Validator 檢查語法與屬性。接著回到 Search Console 做網址審查，確認 Google 取得的頁面沒有被 robots.txt、noindex、登入或其他存取限制擋住。
測試「程式碼」和測試「網址」也不是同一件事。程式碼測試只能證明那段標記本身；網址測試才包含佈景主題、外掛、快取與前端渲染後的結果。正式上線前，建議保留測試日期、網址、主要錯誤與修正紀錄，日後外掛升級才知道差異從哪裡開始。
上線前檢查表
- 頁面可見內容與 Schema 名稱、日期、作者、圖片一致。
- Organization 的品牌名稱、網址、Logo 與官方資料一致。
- Service 沒有標記未公開的服務地區、價格、評價或承諾。
- Article 的作者類型正確，發布日與更新日有明確規則。
- BreadcrumbList 反映讀者實際理解的階層。
- 同一實體若有多段標記，@id 與資料沒有互相衝突。
- 實際網址通過適用工具檢查，且 Google 可以存取頁面。
- 沒有把測試通過寫成「保證顯示」或「保證排名」。
常見問題
WordPress 一定要裝 Schema 外掛嗎？
不一定。外掛、客製小外掛或子佈景主題都能輸出資料，重點是來源單一、欄位正確、容易維護。一般網站可先用可靠外掛處理基本頁型，再針對真正缺少的部分補充。
同一頁可以同時有 Organization、Article 和 BreadcrumbList 嗎？
可以，只要它們描述的是頁面上真實存在的不同關係，而且資料彼此一致。文章頁可包含 Article、發布者 Organization 與 BreadcrumbList，但不應因為「越多越好」加入無關類型。
Service 通過驗證就會有特殊搜尋版型嗎？
不能這樣保證。Schema.org 定義 Service 類型，不等於 Google 一定提供對應的複合式搜尋結果。它的價值在於清楚描述服務實體，實際搜尋呈現仍由搜尋系統決定。
Rich Results Test 沒有錯誤，為什麼 Search Console 還沒看到？
可能是頁面尚未重新檢索、該類型沒有對應報告、實際網址的渲染結果不同，或搜尋結果沒有選擇展示。先用網址審查確認 Google 取得的版本，再等待重新檢索，不要重複堆疊標記。
Schema 要每次改文章都手動更新嗎？
理想上應由 WordPress 正式欄位動態產生，例如標題、作者、發布日與代表圖片。人工固定內容容易過期；但自動化之後仍要抽查，因為欄位映射或外掛更新也可能造成錯誤。
來源與更新說明
本文依據 Google 結構化資料入門、一般結構化資料規範、Organization 文件、Article 文件、Breadcrumb 文件、Schema.org Service 與 WordPress wp_head Hook 整理。功能、欄位與搜尋呈現可能更新，實作時請以官方最新頁面及正式網址測試結果為準。
延伸閱讀
不確定目前是外掛、主題還是客製碼在輸出 Schema？
先盤點再調整，能避免修好一種頁型卻讓另一種頁型重複或失真。
