使用 JSON-LD 檢查器避免錯誤，意味著要把「萃取」視為對貼上標記的證據，並把「驗證」視為一個獨立的搜尋功能資格問題。大多數可避免的錯誤，都是把這兩個問題混為一談造成的：讀者貼上的是渲染後的 DOM，卻沒有和原始來源比較；把任何正面結果都當成最終裁決；或是假設只要出現一個缺少屬性的警告，就等於遭到拒絕。正確的工作流程應該把這些類別放在不同的檢視畫面中，讓一份格式錯誤的 JSON-LD 腳本無法在同一份文件中悄悄抹除有效的項目，也讓警告無法靜悄悄地冒充為失敗。這些習慣本身都不會直接產生損壞的標記，但每一個都會把一份有用的證據報告，變成驅動決策的因素。檢查器只在產品有記載規則集的位置套用明確、可檢視的設定檔，因此未知的類型仍會被萃取，但不會被加上捏造出來的要求。本地端的乾淨報告並不能證明該頁面符合 Google 的功能資格；單一警告也無法證明該頁面會被拒絕。這兩個問題都只能交由你所瞄準的搜尋體驗之官方驗證器，在修正範本後針對已部署的 URL 來回答。
為什麼萃取錯誤會悄悄溜進 JSON-LD 檢查
JSON-LD 萃取錯誤很少來自 JSON 本身，而是來自讀者對檢查器能做的事、以及工具實際能回報什麼，兩者之間的落差。本地端檢查器是針對你貼進去的 HTML 進行處理，而不是針對爬蟲最終收到的頁面；所以一旦把乾淨的結果當成裁決，這個工作流程就已經錯了。還有兩個習慣會讓第一個錯更加惡化：把「缺少屬性」警告當成拒絕，以及把不熟悉的 Schema.org 類型視為超出範圍。這些習慣本身都不會直接產生損壞的標記，但每一個都會把一份有用的證據報告，變成驅動決策的因素。
結構化資料檢查器與萃取器正是以相反的習慣為設計核心。它把剖析錯誤、已宣告的項目，以及缺少屬性的警告分到不同的檢視畫面，因此格式錯誤的腳本無法在同一份文件中悄悄抹除有效的項目，而警告也無法靜悄悄地冒充為裁決。把每個類別分開來讀，正是把「貼進去就祈禱」式的稽核，轉變成有控管審查的關鍵。
結構化資料檢查器與萃取器如何讀取貼上的 HTML
所有剖析作業都在一個分離的瀏覽器範本片段中執行。來源 HTML 會被複製進來，文件片段在即時頁面之外被剖析，且貼上的文件中沒有任何腳本會被執行。檢查器不會要求 URL、載入圖片、送出表單、跟隨連結，或評估嵌入的 JavaScript。這道界線能防止跨來源失敗、私網路請求，以及讓稽核偏離爬蟲實際收到的來源。
貼上 HTML 內的 JSON-LD 可能以單一物件、物件陣列，或包含多個項目的 @graph 節點形式出現。每一種都會被展開成各自的盤點項目，同時保留已宣告的 @type 值與可見的屬性。格式錯誤的 JSON 區塊會在它自己的類別中被回報，因此同一份文件中其他位置發現的有效項目，不會因為某個損壞的腳本而被抹除。以 itemscope 和 itemtype 識別的 Microdata 項目，會被視為有界線的最上層項目來走訪。值會從內容屬性、連結、媒體來源屬性、日期值與文字內容中擷取；巢狀項目會保持可見的巢狀結構，而不會被悄悄壓平成無關的字串。
最終得到的，是一份針對既有結構化資料、易於閱讀的盤點清單。驗證的範圍比萃取更窄。Schema.org 定義了廣泛的詞彙，而個別搜尋產品則會針對特定體驗發布各自的必要與建議屬性。檢查器只在擁有記載規則集之處，套用明確、可檢視的設定檔；未知的類型仍會被萃取，但不會被加上捏造出來的要求。如果想進一步了解 Schema.org 詞彙如何融入搜尋產品，可以參考 Google Search Central 結構化資料介紹，它同樣在詞彙與功能資格之間畫出清楚的界線。
三個步驟完成零錯誤的萃取
- 把經授權的 HTML 貼進檢查器。複製你想稽核之頁面的已交付 HTML 來源，或從開發環境匯出的可控渲染 DOM。如果某個框架在頁面載入後注入標記，請在得出結論前，並排比較原始回應、渲染後的 DOM，以及爬蟲可見的匯出結果。檢查器永遠不會擷取或執行頁面，所以沒貼進去的東西就看不見。
- 為每個類別各做一次檢視。先打開 JSON-LD 剖析錯誤區段，先解決任何格式錯誤的腳本，再進行其他動作。接著分開檢視 JSON-LD 項目與 Microdata 項目，記下已宣告的類型、可見的屬性，以及範本輸出的任何重複項目。最後依據相關設定檔的連結文件，檢視缺少高價值屬性的警告，把它們當成檢視提示，而不是阻擋條件。
- 修正來源範本，再驗證已部署的 URL。編輯會輸出標記的範本，重新執行本地端萃取以確認變更已生效，然後再用你所瞄準之搜尋功能的官方工具，驗證公開的 URL。本地端檢查器回報的是關於貼上標記的事實；資格則由官方驗證器與搜尋產品的政策決定。
常見的萃取錯誤與如何察覺
大多數萃取錯誤都屬於少數幾種模式。下表把每一種錯誤，與它在檢查器輸出中的樣貌、以及在它擴散成範本變更前最簡單的察覺方式配對起來。
| 錯誤 | 它看起來像什麼 | 如何在輸出中察覺 |
|---|---|---|
| 把任何乾淨結果都視為具備資格 | 沒有剖析錯誤、沒有警告，讀者便斷定該頁面符合豐富結果的資格。 | 檢視設定檔清單。乾淨的本地端萃取，只能證明貼上的 HTML 符合記載中的設定檔，無法證明功能資格。 |
| 讓一個格式錯誤的腳本隱藏掉有效的項目 | 在有多範本的頁面中，項目總數看起來異常地少。 | 先打開 JSON-LD 剖析錯誤區段。損壞的腳本必須被分別回報，而不是悄悄略過。 |
| 把巢狀 Microdata 壓平 | 巢狀項目的值以純文字字串顯示，而非巢狀節點。 | 確認巢狀項目在有界線的屬性檢視中仍維持可見的巢狀結構；如果一段複雜的 Microdata 區塊看起來像扁平字串，表示剖析器遺失了結構。 |
| 把警告讀成失敗 | 一個缺少的高價值屬性被當成拒絕。 | 警告代表本地端設定檔找不到該屬性，並不能證明搜尋引擎會拒絕該頁面。請與連結的文件交叉比對。 |
| 只貼上渲染後的 DOM | 在頁面載入後注入的項目，從未出現在盤點中。 | 比較來源回應、渲染後的 DOM，以及爬蟲可見的輸出。若某個項目只在渲染後的 DOM 中缺席，代表是客戶端注入的問題，而非範本錯誤。 |
| 假設 RDFa 也包含在內 | RDFa 標記被計為缺席，並被當成警告處理。 | 此工具僅萃取 JSON-LD 與 Microdata。RDFa 在目前的產品範圍之外，永遠不會被評分。 |
| 為了消除警告而新增欄位 | 在把通用或捏造的值塞進某個屬性後，警告就消失了。 | 標記應描述使用者實際看得到的內容。少數幾個真實的屬性，優於塞滿佔位字串的大型物件。 |
檢查器無法告訴你的事
檢查器回報的是關於貼上文件的證據，而不是對搜尋呈現的承諾。有些問題明確落在其範圍之外；事先知道這些，才能把有用的工作流程與過度自信的工作流程區分開來。
此工具不會擷取即時頁面，所以無法把它的輸出與爬蟲實際收到的內容做比較。如果某個框架在載入後重寫文件，你貼上的內容就不是被索引的內容；本地端萃取可能看起來很乾淨，但已部署的頁面卻可能失敗。Microdata 的走訪同樣是有界線的：檢查器會為最上層項目建立有界線的屬性檢視，而 RDFa 則完全不會被萃取。這項限制會顯示在輸出中，因此不會被誤認為是通用的語意網稽核。
搜尋引擎決定是否以及何時顯示強化版呈現。沒有任何本地端檢查器能保證索引、排名或豐富結果；一個看起來完整的物件，仍然可能違反搜尋政策、與可見頁面不一致、使用不受支援的功能，或因檢查器看不見的原因而在部署測試中失敗。反過來說，不屬於 Google 功能的 Schema.org 屬性，對其他消費者仍可能有意義，所以本地端缺少警告，並不等於缺少該值。如果想了解 Microdata 項目與屬性應如何巢狀的正式定義，請參考 WHATWG HTML Microdata 規範，這是檢查器所採用的有界線屬性檢視所依循的參考依據。
在信任結果之前，先驗證已部署的頁面
當本地端萃取已經乾淨，且範本已編輯過後，工作流程便交接給你所瞄準之搜尋功能的官方驗證器。本地端檢查器是預先檢查步驟，而不是替代品。它能告訴你，你所掌控的標記是否能被剖析、宣告了正確的類型，並符合記載中的高價值屬性集；官方驗證器則能告訴你，已部署的 URL 是否符合該搜尋產品針對特定體驗的政策。
部署後，請在頁面被重新抓取後，檢視 Search Console 的強化報告，並以具代表性的紀錄來測試實際的頁面範本，而非只挑一個手動挑選的例子。必要屬性的指引無法取代內容審查，因此你所新增的任何欄位，都應該描述頁面上使用者看得到的內容。依此方式使用，結構化資料檢查器就是一個透明的預先檢查：先解決剖析錯誤，再逐一檢視萃取出來的項目，再依連結文件核對設定檔警告，最後才把公開 URL 送到官方驗證器。輸出內容是關於貼上文件的證據，而不是對搜尋呈現的承諾。
延伸閱讀：如何解讀萃取後的 JSON-LD 檢查器結果。
延伸閱讀：為 JSON-LD 選擇結構化資料檢查器的做法。