TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
結構化資料測試工具：查語法、搜尋資格與上線狀態
結構化資料測試工具該怎麼選？依用途分清 Rich Results Test、Schema.org Validator 與 Search Console，說明 Article 欄位、WordPress 重複標記、Lighthouse 人工檢查，以及測試通過仍沒有搜尋版位的原因。
用 AI 摘要這篇文章：
想檢查結構化資料，先分清三件事：標記能不能解析、是否符合 Google 搜尋功能要求，以及上線後有沒有被讀到。
我會把結構化資料測試工具分成三個用途：Rich Results Test 查 Google 的複合式搜尋結果條件，Schema.org Validator 查標記，Search Console 追蹤正式網站的偵測狀態。看到綠色通過訊息時，先確認通過的是哪一關，才不會一直修改已經正確的程式碼。
| 你要確認什麼 | 適合的工具 | 輸入與判讀範圍 |
|---|---|---|
| Google 支援的搜尋功能有沒有技術錯誤 | Rich Results Test | 網址或程式碼；通過不保證實際展示 |
| 頁面標了哪些 Schema.org 資料、語法能否解析 | Schema.org Validator | 網址或程式碼；不等於符合 Google 搜尋資格 |
| Google 已偵測的標記有哪些問題 | Search Console | 有權限的網站資源；報表不是所有標記的完整清單 |
結構化資料是附在網頁上的資料標記，用來交代「這是一篇文章」「作者是誰」等資訊。Schema.org 定義可使用的類型與屬性；Google 再為自己支援的搜尋功能訂定條件。Google 的結構化資料入門說明也區分這兩者，不能把它們的檢查範圍畫上等號。
Rich Results Test：先查 Google 能使用哪些標記
如果你的目標是文章、產品或麵包屑等 Google 搜尋呈現，從 Rich Results Test 開始。它會列出偵測到的支援類型，以及相關錯誤與改善建議；只有部分類型提供搜尋樣式預覽。工具支援 JSON-LD、Microdata 與 RDFa，並不是只接受 JSON-LD。這些範圍可在 Google 測試工具說明查到。
改標記之前可以貼程式碼，部署後則應測正式網址。前者確認送入的片段，後者還能發現頁面或必要資源抓不到的問題。程式碼測試成功，不能代替正式網址檢查；需要登入的頁面，也不能期待測試工具沿用你的帳號讀取。
不要把客戶個資、密鑰或未公開內容貼進測試框。Google 說明，測試結果可透過連結分享，知道連結的人不必取得額外權限就能查看。排查時只提供足以重現問題的公開內容。
Schema.org Validator：查閱標記類型與語法
如果你想確認整頁寫了哪些 Schema.org 標記，或 Rich Results Test 沒有列出預期類型，就換用 Schema.org Validator。依 Schema.org 官方說明，它能擷取 JSON-LD、RDFa 與 Microdata，整理資料之間的關係並找出語法錯誤；範圍聚焦 Schema.org，不會解析任意外部 @context。
例如標記能在 Validator 中被讀出，卻沒有出現在 Google 測試結果，先查 Google 是否支援對應搜尋功能。不要為了讓另一個工具也亮綠燈，硬把文章改標成產品或食譜。標記能解析、內容描述正確、符合搜尋功能條件，是不同的判斷。
Search Console：追蹤 Google 已經讀到的版本
網站上線後，使用 Search Console 查看支援類型的複合式搜尋結果報表。它適合發現同一模板造成的多頁錯誤，再追蹤修正狀態。官方報表說明特別提醒，清單只包含部分偵測項目，數量也以資料項目計算，不能直接當成頁面數。
看不到某個報表，不代表網站沒有那種標記。Google 必須支援對應報表，並在網站偵測到相關資料；不是每個 Schema.org 類型都有專屬報表。想查特定頁面，改用網址審查，分清 Google 已索引的版本與即時測試結果。
修好網站來源後，先用正式網址重新測試，再針對 Search Console 已列出的問題啟動修正驗證。如果只是補上新文章的標記，沒有既有錯誤可驗證，就檢查頁面抓取與索引狀態。報表反映的是 Google 的處理結果，不會隨後台儲存立即同步。
缺欄位、語法錯誤與 Lighthouse 分數要分開看
先處理會讓資料項目無效的重大錯誤，再看非重大問題。後者通常是改善資訊完整性的建議，不代表整頁失去搜尋資格；實際要求仍以該類型的 Google 文件為準。不要為了消掉所有提醒，填上不存在的評分或作者。
Article 並不是每個欄位都必填。Google 的 Article 文件明確表示沒有必填屬性，建議填入適用的作者、標題、圖片與日期等資料。其他搜尋功能可能有必填要求，應查對應的 Google 文件，不能拿一份通用欄位表套全部頁面。
若工具顯示無法解析，先處理 JSON 的引號、逗號或括號問題。連資料都讀不出來時，後面的欄位錯誤可能尚未顯示。Google 的無法剖析的結構化資料說明也提醒，修好語法後，才可能浮現其他需要處理的問題。
Chrome DevTools 可協助查看頁面實際輸出的 JSON-LD，但不是完整驗證器。Lighthouse 的結構化資料項目是人工檢查，不計入 SEO 分數；滿分不能證明標記正確。想快速盤點，也可使用 Detailed SEO Extension，正式判讀仍回到對應測試工具。
WordPress 有多份 Schema，先找矛盾再停用來源
同頁同時有 Article、BreadcrumbList 與作者 Person，不一定有問題。Google 的結構化資料指南允許一頁描述多個相關事物。真正要查的是：主題、SEO 外掛與手動程式碼，是否重複描述同一篇文章，卻填了不同作者、標題或網址。
我會先在測試站確認輸出來源，再調整重複的設定，而不是看見多個 script 就刪除。保留修改前設定，改完確認文章與麵包屑資料仍在；如果必要標記一起消失，就還原再查。使用 WordPress 快取外掛的網站，還要清除相關快取，再用正式網址確認收到的是新內容。
若你遇到的是分享連結時標題或圖片不對，先查 Open Graph 等社群資料。這類問題可從 metatags.io 的社群預覽著手，不要把所有預覽錯誤都歸到 Schema。
測試通過沒有搜尋版位，還有哪些原因？
先確認頁面能被抓取與索引，標記與可見內容一致，且符合該搜尋功能的規則。即使這些條件都滿足，Google 仍會依搜尋情境決定呈現方式；官方指南不保證正確標記一定產生複合式搜尋結果。固定提高多少點擊率、保證幾天出現，都不適合作為驗收承諾。
也要確認期待的版位是否仍存在。Google 自 2026 年 5 月 7 日起不再顯示 FAQ 複合式搜尋結果，並於 6 月移除相關文件，詳見官方變更紀錄。頁面上的實用問答可以保留，但不能再靠 FAQPage 標記取得這個 Google 版位。
至於 AI 搜尋，Google 的生成式 AI 搜尋指南沒有要求專用 schema。把資料寫準、讓正文可讀，並回答讀者真正要解決的問題，比額外堆上標記更實在；Schema 測試也無法證明文章一定被 AI 引用。
先挑一篇代表性頁面測試，記下工具偵測到的類型與具體問題，再回來源修正。技術問題排除後，就把重心放回頁面內容與 On-page SEO；持續追蹤搜尋曝光與點擊，才知道讀者有沒有真的找到你的內容。
