以萃取為主的結構化資料檢查器與純粹的 JSON-LD 驗證器，分別回答兩個不同的問題，而兩者之間的選擇，取決於你需要的是「文件現有標記的證據」，還是「某個特定搜尋消費者是否接受它」的證明。JSON-LD 語法檢查器回答的是「這個區塊是否為有效的 JSON，並且描述了已知的類型？」；而萃取器回答的是「這份 HTML 裡實際上有哪些結構化資料，逐項來看？」只針對單一搜尋功能的驗證器，只會告訴你 Google 目前是否接受該功能所使用的類型。不抓取、也不執行網頁的萃取器，則會提供一份可閱讀的清單，列出每一個 JSON-LD 區塊、每一個 Microdata 項目、每一個宣告的類型，以及每一個可見的屬性。當一切都很單純時，兩種答案會重疊；但一旦範本、多種類型、第三方注入，或不熟悉的 Schema.org 類型介入，兩者就會急劇分歧。Structured Data Checker & Extractor 明確站在萃取這一側，本文接下來會說明在什麼情況下，採取這個立場才是正確的選擇。
萃取與驗證：不同任務，不同證據
「JSON-LD 檢查器」與「結構化資料萃取器」這兩個詞常被互換使用，儘管它們所描述的工具具有截然不同的契約。JSON-LD 語法檢查器接收一個區塊、執行 JSON.parse，並回報該 script 標籤是否包含語法正確、且能解析為可辨識的 Schema.org 類型的 JSON。結構化資料萃取器接收一份文件，遍歷每一個 script 標籤與每一個 HTML 節點，並回報實際存在的內容。
Schema.org 定義了廣泛的詞彙；搜尋產品則針對特定的複合式體驗，發布更精簡的必需與建議屬性集合。萃取可以維持通用性，因為描述一個物件比評分一個物件容易。相對地，針對單一消費者設定檔的驗證，必須明確且可檢查，因為每個缺失的屬性都可能觸發警告。當你將同一份文件貼到這兩類工具中時，可能會在驗證器上得到綠色勾號、在萃取器上看到一長串未解決的問題，反之亦然；無論出現哪種矛盾，都不代表工具故障。它們是在對同一份來源回答不同的問題。
對大多數實際工作而言，有用的問題是：我需要的是「現存內容的清單」，還是「某個產品是否接受它」的確認？這個單一的分歧點，就是區分以下各種情況的依據。
你需要的不是純 JSON-LD 檢查器，而是萃取器的跡象
有幾種反覆出現的情況，會讓決策傾向萃取。第一種是由範本驅動的內容，單一來源會產生數十甚至數百筆僅有些微差異的紀錄；對其中一個片段進行語法檢查，對下一個片段毫無意義。第二種是混合格式的內容：一個頁面同時包含 JSON-LD 與 Microdata，有時繼承自 CMS 佈景主題，有時由外掛新增，有時由人工編輯。純粹的 JSON-LD 檢查器會默默地忽略 Microdata 那一半。第三種是不常見或罕用的 Schema.org 類型，而你在意的搜尋功能並未記載這些類型；驗證器可能完全不為其評分，但萃取器仍會列出你提供的每個屬性。
第四種情況是回歸後的預飛偵錯。對範本、CMS 升級或新結構化資料外掛的變更，可能會悄悄複製區塊、從某個變體中刪除必要欄位，或產生一個再也無法解析的 JSON-LD script。對單一渲染後頁面執行驗證，可能無法浮現這種模式，因為它只會看到其中一個重複項目。萃取器則會列出文件中的每個區塊，並將無法解析的部分與其他部分分開回報。
第五種是任何標記不能離開你機器的作業流程：內部文件、位於防火牆後的草稿預備伺服器，或需要驗證的頁面。由於 Structured Data Checker & Extractor 從不抓取、執行或傳送來源，你可以直接貼上所提供的 HTML。如需針對 JSON-LD 的相關決策標準，Choosing a Structured Data Checker Approach for JSON-LD 這篇指南會從不同角度探討相同的取捨。
驗證器本身就足夠的跡象
相反的情況同樣存在。當類型是 Google 或其他消費者已記載的類型、範本穩定、渲染後的頁面可從公開網際網路存取，而你正在檢查你所瞄準的特定功能是否會接受該頁面時，聚焦的 JSON-LD 檢查就合理了。一旦這四項條件成立，驗證器能提供比萃取器更精準的訊號，因為它問的正是你真正關心的問題。
驗證器也是成功萃取之後的正確工具。如果你的萃取器回報了一份完整的清單，且針對你瞄準的類型沒有解析錯誤或設定檔警告，下一步就是使用將讀取該頁面的消費者，確認已部署的 URL。根據 Google Search Central 對結構化資料的介紹，語法有效性和搜尋資格是兩個不同的問題，「萃取無誤」的結果並不能證明複合式結果即將出現。驗證器正是為了最終那道確認而存在。
| 情境 | 較合適的工具 | 原因 |
|---|---|---|
| 範本有多個變體，僅貼上單一片段 | 萃取器 | 清單僅反映貼上的片段；請分別檢查每個範本變體 |
| 同一頁面同時包含 JSON-LD 與 Microdata | 萃取器 | 僅檢查 JSON-LD 會默默地忽略 Microdata 那一半 |
| 不常見或自訂的 Schema.org 類型 | 萃取器 | 驗證器可能不為其未記載的內容評分 |
| 公開 URL 上的穩定、已記載類型 | 驗證器 | 直接從你所瞄準的消費者取得答案 |
| 單一功能的部署後簽核 | 驗證器 | 確認資格，而不僅是語法 |
如何使用 Structured Data Checker & Extractor
這個作業流程刻意設計得很精簡，讓證據始終與你實際貼上的文件保持關聯。
- 匯出所要檢查的頁面或範本的「已交付 HTML 原始碼」，或經控制的「渲染後 DOM 匯出」。檢查器永遠不會抓取 URL，因此你能完全掌控輸入內容。
- 將標記貼到 Structured Data Checker & Extractor 的輸入欄位中。
- 執行萃取，然後分別檢視 JSON-LD 的解析錯誤、Microdata 項目、宣告的類型、屬性，以及聚焦的缺失屬性警告。
- 將萃取出的項目與範本原本應輸出的內容進行比對。留意任何重複的類型、空白的 URL 欄位，或在近期變更後消失的屬性。
- 修正來源範本，而不是萃取的輸出。清單是證據；實際出貨的是來源。
- 範本修正完成後，請使用官方的複合式結果測試，對你所瞄準的搜尋功能驗證已部署的 URL。本地萃取永遠無法取代那最後一步。
解讀萃取出的清單
輸出刻意經過切割，使單一損壞的 script 無法掩蓋其他健康的區塊。格式錯誤的 JSON-LD 區塊會單獨回報；同一份文件其他位置中發現的有效項目則會保持可見。JSON-LD 容器會展開為個別項目，同時保留宣告的 @type 值與可見屬性，無論來源是單一物件、陣列，還是包含多個節點的 @graph。
Microdata 是透過普通 HTML 上的 itemscope、itemtype 與 itemprop 讀取；而有界屬性檢視則涵蓋透過 content 屬性、連結、媒體來源屬性、日期值與文字內容所暴露的值。巢狀項目會保持巢狀結構，而不會被默默地扁平化為不相干的字串。如果萃取器將某個 Microdata 的 URL 顯示為空白，這通常指向元素上使用錯誤的屬性，而非欄位缺失。
設定檔警告帶有特定的意涵：本地設定檔找不到某個屬性。警告不等同於拒絕；乾淨的結果也不保證會出現複合式結果。請將清單視為一系列需要回答的具體問題，例如「預期的類型是否存在？」「範本是否輸出了重複項目？」「某個變體中是否缺少必要欄位？」以及「是否有任何 JSON-LD 區塊無法解析？」這些是萃取器能回答的問題；其他一切則屬於已部署的 URL 與搜尋引擎的範疇。
將本地萃取與官方驗證器搭配使用
一個實用的作業流程會依序使用這兩種工具。先用萃取確認你所預期的標記就是你所出貨的標記。首先解決解析錯誤，因為損壞 script 下游的所有內容都無法信任。接著依據連結到的說明文件檢視設定檔警告，修正範本，重新部署，最後使用你所瞄準之搜尋功能的官方驗證器完成驗證。
有兩項限制需要牢記。首先，檢查器僅支援 JSON-LD 與 Microdata；RDFa 超出目前的產品範圍，且永遠不會被計為「缺失」或「無效」的結構化資料。如果你的頁面依賴 RDFa，清單將無法反映標記的該部分，你不應將「JSON-LD 結果乾淨」解讀為完整的涵蓋率稽核。其次，較少但完整且真實的屬性，優於一個摻雜大量通用或捏造數值的大型物件；必要屬性的指引不能取代內容審查，標記應代表使用者實際能看見的內容。
萃取器不會模擬每個消費者、不會執行貼上文件中的 script，也不會追蹤連結或提交表單。輸入大小與項目數量均受到限制，因此意外的全站傾印不會使頁面凍結；已解析的節點則存放在一個獨立於即時頁面的分離範本片段中。請將此工具視為正式測試前透明的預飛作業：貼上經授權的 HTML、檢查每個萃取的項目、先解決解析錯誤、依據連結到的說明文件檢視設定檔警告，然後再驗證已部署的回應。輸出是關於所貼上文件的證據，而非對搜尋呈現方式的承諾。
如果你正在權衡各種選項，Document JSON-LD Checker Steps for Structured Data 對此有詳細說明。