正確的擷取是 JSON-LD 檢查器執行過程中唯一可以驗證的部分——每一個警告、缺口以及後續的通過／失敗判斷，都取決於資料清單是否準確。三個條件決定擷取是否正確:輸入與爬蟲實際接收的內容相符、每個 JSON-LD 容器(單一物件、陣列或 @graph)各自展開成一個項目並保留其宣告的 @type，以及 Microdata 項目是從其 itemprop 和 itemtype 屬性讀取，而非僅依賴可見文字。正確的擷取也會將同一份文件中的格式錯誤 JSON 區塊與有效項目分開，並讓巢狀的 Microdata 項目保持明顯的巢狀結構。無論你是直接送出 JSON-LD，還是從範本產生 JSON-LD，本機檢查器都能針對貼上的原始碼確認這四種行為。它無法確認 Google 的複合式搜尋結果測試、Search Console 或任何其他消費者是否會接受已部署的網頁，所以在修正後仍然必須執行官方的驗證工具。
為什麼正確性比乾淨的分數更重要
本機 JSON-LD 檢查器是針對你貼上的內容運作，而不是針對被索引的內容。將綠色勾號或空白的警告清單視為該網頁將獲得複合式搜尋結果的證明，誇大了這個工具實際能證明的事情。這份報告是關於貼上文件的證據，而不是關於搜尋呈現的承諾。把擷取結果視為事實基準，才能用它做它能做的事——抓出範本錯誤、重複輸出、毀損的 JSON 以及空白的屬性值——並在它做不到的地方停下來:預測索引、排名或複合式搜尋結果的資格。
如果擷取器默默地把巢狀的 Microdata 項目攤平成不相干的字串，或是隱藏了格式錯誤的 JSON-LD 區塊，卻仍回報同一份文件中的其他項目，那麼後續每一個決策都會建立在錯誤的資料上。擷取的正確性是後續每一個警告或缺口的基礎。執行後的每一個動作，都假設項目清單忠實反映了你所貼上的來源。
讓輸入與爬蟲看到的內容一致
檢查器的第一個正確性控制點就是貼上的內容本身。三種輸入形式有不同的可靠性，把它們混用，是正確的擷取結果與部署網頁不一致的最常見原因。
| 輸入來源 | 包含內容 | 風險 |
|---|---|---|
| 來源範本(CMS、建置輸出、原始 HTML) | 作者所撰寫的 JSON-LD 與 Microdata | 漏掉執行階段由 JavaScript 注入的標記 |
| 受控的轉譯後 DOM 匯出 | 注入後、使用者互動前的 DOM | 仍缺少非同步或事件驅動的標記 |
| 即時擷取的回應 | 爬蟲實際接收到的內容 | 無法在本機產生;檢查器不會自行擷取 |
對於在載入後才注入標記的框架，安全做法是比較同一個網址的來源回應、轉譯後的 DOM，以及爬蟲可見工具所回傳的內容。如果這三者出現分歧，擷取結果就只稽核了其中之一。選錯輸入形式，會讓檢查器在技術上對錯誤的輸入是正確的。
如何驗證 JSON-LD 檢查器正確擷取資料
- 在瀏覽器中開啟結構化資料檢查與擷取工具。所有解析都在隔離的瀏覽器範本片段中執行——不會上傳任何內容，你的 HTML 中也不會執行任何指令碼。
- 貼上爬蟲接收到的同一份 HTML。用戶端轉譯的網頁建議使用受控的轉譯後 DOM 匯出;檢查器不會自行擷取網址。
- 執行擷取，依序檢視項目:JSON-LD 解析錯誤、JSON-LD 項目、Microdata 項目，然後是聚焦的屬性缺失警告。
- 確認 JSON-LD 容器已展開。單一物件應成為一個項目;陣列應為每個元素產生一個項目;@graph 應展開成個別節點，且每個節點都保留其宣告的 @type。
- 檢查 Microdata 涵蓋範圍。每個項目應透過 itemtype 顯示其宣告的類型，並透過 itemprop 顯示其屬性值，包括透過內容屬性、連結、媒體來源屬性、日期值與文字內容所揭露的值。
- 先解決解析錯誤，再處理設定檔警告。格式錯誤的 JSON-LD 區塊會被單獨回報，因此不會抹除有效項目，但在出貨前仍必須在來源範本中修復它。
- 交叉檢查:在來源中變更一個屬性、重新產生貼上內容，並確認同一個項目現在以新值列出該屬性。如果擷取結果在這個受控變更下保持穩定，擷取路徑就是正確的。
- 修正來源範本、重新部署，然後用 Google 的複合式搜尋結果測試，針對你實際要瞄準的搜尋功能驗證公開網址。本機擷取無法取代最後這個部署步驟。
如果同一份來源的兩次貼上執行之間，項目數或屬性數出現漂移，擷取結果就還不足以信任。重複執行、重新貼上，或在根據輸出下結論前確認輸入沒有被意外修剪。
能抓出錯誤擷取結果的交叉檢查
五個實用的交叉檢查，能把單次執行變成誠實的正確性檢查。沒有一個需要擷取實際上線的網頁。
- 重複項目稽核——同一個 @type 在同一個產品範本中出現兩次，通常代表產生器在每個頁面與每個區塊各執行了一次;在判斷屬性缺口前先進行去重。
- 必要欄位抽樣檢查——打開來源，挑選設定檔要求的欄位;擷取結果應顯示一個值，或提出聚焦的警告。對必要欄位保持沉默是紅燈，不是綠燈。
- 屬性與文字比對——對 Microdata 而言，如果 itemprop 預期為連結的位置出現空白網址，通常代表使用了錯誤的屬性;擷取結果應揭露連結目標，而不是只顯示內部文字。
- 巢狀項目可見性——巢狀的 Microdata 項目應維持明顯的巢狀;如果父物件的字串值默默吸收了子項目，攤平的值就具有誤導性。
- 設定檔限制檢查——未知的類型會被擷取，但不會被指派捏造的需求。如果你在項目清單中看到不支援的類型卻沒有警告，這是設計如此，而不是缺少檢查。
把這些當成明文記載的控制項來使用，而不是泛用的懷疑。如果檢查失敗，問題出在來源範本或輸入形式，而非擷取邏輯本身。
解析錯誤與屬性缺失不是同一個嚴重程度
解析錯誤代表 JSON 區塊根本無法讀取。屬性缺失代表區塊已成功讀取，但不符合已記載的消費者設定檔。正確性要求嚴格的順序:先處理解析錯誤，再處理設定檔警告，最後才是資訊性的觀察。
把屬性缺失警告當成解析錯誤處理，會導致假修正——為了消音而加入捏造的值。產品契約明文規定:屬性少但完整且真實，優於塞滿通用或捏造值的大型物件。警告代表本機設定檔找不到該屬性;它無法證明搜尋引擎會拒絕這個頁面。語法有效性與搜尋資格是不同的問題，檢查器的設計就是要把兩者分開。關於搜尋產品認定何為必要的外部依據，請參閱 Google 的結構化資料介紹。
本機擷取何時不再是充分的檢查
有三種情況代表是時候停止依賴本機結果，改用官方驗證工具了。
- 爬蟲可見的回應與你能在本機貼上的任何內容都不同——例如位於認證之後、私有網路之後，或是依賴檢查器無法複製的執行階段擷取、由用戶端邏輯產生的內容。
- 產品瞄準的是本機設定檔未編碼的特定功能政策——Google 關於垃圾內容政策、圖片規定或評論來源規則的說明適用於部署階段，而不是貼上階段。
- Search Console 的強化報告與本機擷取結果不同——只有已部署的網址能證明索引狀態，擷取結果本身無法。
對於支援設定檔之外的 Microdata 行為與屬性語意，WHATWG HTML 的Microdata 規格說明了有效節點的樣貌;當類型落在記載的契約之外時，本機檢查器無法取代那份文件。
最終的正確性紀律
一次值得信任的執行包含四個部分:貼上正確的輸入、正確展開每個 JSON-LD 容器、區分解析錯誤與屬性警告，以及在出貨前用官方工具確認已部署的網址。任何少於這個順序的結果，都只是一個數字，而不是保證。無論你是在稽核一個範本、一百個產品頁，還是一個剛建好的 CMS，紀律都相同。對於在做完這一切後擷取結果仍看起來不對的讀者，請參閱修正看起來錯誤的 JSON-LD 檢查器結果的逐步說明。對於不確定檢查器是否真的會打開自己網頁的讀者，請參閱JSON-LD 檢查器會對你的網頁做什麼。