以萃取為主的結構化資料檢查器與純 JSON-LD 驗證器回答的是兩個不同的問題，而兩者之間的選擇，取決於你需要的是「目前文件中已有的標記」的證據，還是「某個特定的搜尋消費者是否接受它」的確認。JSON-LD 語法檢查器回答的是「這個區塊是否為有效的 JSON，並且是否描述了已知的類型?」而萃取器回答的則是「這份 HTML 中實際存在哪些結構化資料，逐項列出?」針對單一搜尋功能的驗證器，只會告訴你 Google 目前是否針對該功能接受此類型。不進行擷取或執行頁面的萃取器，則會為你提供一份可閱讀的清單，列出每一個 JSON-LD 區塊、每一個 Microdata 項目、每一個宣告的類型，以及每一個可見的屬性。當一切都很簡單時，這兩個答案會重疊;但一旦涉及模板、多種類型、第三方注入，或是陌生的 Schema.org 類型時，兩者就會急劇分歧。結構化資料檢查器與萃取器在這條界線上明確地站在萃取那一端，而本文接下來將說明在哪些情況下這個立場才是正確的。
萃取與驗證:不同的工作，不同的證據
「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。在單一已渲染頁面上執行的驗證器，可能無法顯現這種模式，因為它只會看到其中一個重複項目。萃取器則會將文件中的每一個區塊都列出來，並將無法解析的區塊與其他區塊分開回報。
第五種是任何標記不得離開本機的工作流程:內部文件、位於防火牆後的草稿預備伺服器，或是需要驗證的頁面。由於結構化資料檢查器與萃取器從不擷取、執行或傳送來源，你可以直接貼上交付的 HTML。若需要與 JSON-LD 相關的其他決策依據，為 JSON-LD 選擇結構化資料檢查器的方法一文，則從不同角度探討了相同的權衡。
驗證器本身就已足夠的徵兆
相反的情境同樣存在。當類型是 Google 或其他消費者已有記載的、模板是穩定的、已渲染的頁面可從公開網際網路存取，並且你正在確認你所針對的特定功能是否會接受該頁面時，聚焦的 JSON-LD 檢查便有意義。一旦這四個條件成立，驗證器會給你比萃取器更精準的訊號，因為它問的正是你真正關心的問題。
驗證器在萃取成功之後，也是正確的工具。若你的萃取器回報了一份完整的清單，且沒有剖析錯誤，也沒有針對你所針對類型的輪廓警告，下一步便是以將會讀取該頁面的消費者，確認已部署的 URL。根據Google 搜尋中心對結構化資料的介紹，語法的有效性與搜尋的適用性是兩個分開的問題;「乾淨地萃取」這個結果，並不能證明一定會出現豐富結果。驗證器的存在，正是為了提供這最後的確認。
| 情境 | 更合適的工具 | 原因 |
|---|---|---|
| 具有多種變體的模板，僅貼上單一片段 | 萃取器 | 清單僅反映所貼上的片段;需分別檢查每個模板變體 |
| 同一頁面上同時包含 JSON-LD 與 Microdata | 萃取器 | 僅檢查 JSON-LD 會無聲地漏掉 Microdata 的那一半 |
| 少見或自訂的 Schema.org 類型 | 萃取器 | 驗證器可能不評分它未記載的內容 |
| 公開 URL 上穩定且有記載的類型 | 驗證器 | 直接從你所針對的消費者取得答案 |
| 針對單一功能的部署後驗收 | 驗證器 | 確認的是適用性，而非僅僅是語法 |
如何使用結構化資料檢查器與萃取器
這個工作流程刻意設計得很窄，目的是讓證據與你實際貼上的文件保持緊密關聯。
- 匯出你要檢查的頁面或模板的交付 HTML 原始碼，或是受控的已渲染 DOM 匯出。檢查器從不擷取 URL，因此你能完全掌控輸入內容。
- 將標記貼入結構化資料檢查器與萃取器的輸入欄位。
- 執行萃取，然後分別檢視 JSON-LD 剖析錯誤、Microdata 項目、宣告的類型、屬性，以及聚焦的遺漏屬性警告。
- 將萃取的項目與模板原本應輸出的內容進行比對。記下任何重複的類型、空白的 URL 欄位，或是在近期變更後消失的屬性。
- 修正來源模板，而不是萃取的輸出。清單只是證據;實際送出的，是來源。
- 一旦模板修正完成，請以你所針對搜尋功能的官方 Rich Results Test 驗證已部署的 URL。本機萃取永遠無法取代這最後一步。
解讀萃取出的清單
輸出刻意分割，使得單一損壞的 script 無法掩蓋其他健康的 script。格式錯誤的 JSON-LD 區塊會單獨回報;同一文件中其他地方找到的有效項目，則仍維持可見。JSON-LD 容器會展開為個別項目，同時保留所宣告的 @type 值與可見的屬性，無論來源是單一物件、陣列，還是包含多個節點的 @graph。
Microdata 透過一般 HTML 上的 itemscope、itemtype 與 itemprop 讀取，而有界屬性檢視則涵蓋透過內容屬性、連結、媒體來源屬性、日期值以及文字內容所公開的值。巢狀項目會維持巢狀結構，而不會被默默地扁平化為不相關的字串。若萃取器將某個 Microdata URL 顯示為空白，通常指向元素上錯誤的屬性，而不是欄位的缺漏。
輪廓警告帶有特定的意義:本機輪廓找不到某個屬性。警告並不等於拒絕;而乾淨的結果也不保證會出現豐富結果。請將這份清單視為一連串具體待回答的問題，例如「預期的類型是否存在?」、「模板是否輸出了重複的項目?」、「某個變體是否缺少必要欄位?」、「是否有任何 JSON-LD 區塊無法剖析?」這些問題是萃取器能夠回答的;其他一切，則屬於已部署的 URL 與搜尋引擎。
將本機萃取與官方驗證器搭配使用
實務上的工作流程會依序使用這兩種工具。先以萃取確認你預期的標記，就是你實際送出的標記。首先解決剖析錯誤，因為損壞 script 之後的任何內容都無法信任。接著依據連結的文件檢視輪廓警告，修正模板，重新部署，最後以你所針對搜尋功能的官方驗證器作結。
有兩項限制需要記住。首先，檢查器僅支援 JSON-LD 與 Microdata;RDFa 已超出目前的產品範圍，不會被視為缺失或無效的結構化資料。若你的頁面依賴 RDFa，清單將不會反映標記的那一部分，你不應將乾淨的 JSON-LD 結果解讀為完整的涵蓋稽核。其次，屬性少但完整且真實，優於以泛用或捏造的值填充出來的大型物件;必要屬性的指引無法取代內容審查，標記應該代表使用者實際能夠看到的內容。
萃取器不會模擬每個消費者、不會執行所貼上文件中的 script，也不會追蹤連結或提交表單。輸入大小與項目數量都設有上限，使得意外的全站傾印無法凍結頁面;已剖析的節點存在於一個與即時頁面隔離的分離式模板片段之中。請將此工具視為官方測試前透明的預檢:貼上經授權的 HTML、檢視每個萃取出的項目、優先解決剖析錯誤、依據連結的文件檢視輪廓警告，然後驗證已部署的回應。輸出是關於所貼上文件的證據，而不是對搜尋表現的承諾。