一個 JSON-LD 檢查器會擷取結構化資料，把貼上的 HTML 轉成一份可閱讀的清單，列出文件中每個 JSON-LD 程式碼區塊與 Microdata 項目，並將剖析錯誤與缺少屬性的警告分成不同類別回報。擷取作業在隔離的瀏覽器範本中進行，因此已部署的網頁永遠不會被擷取、執行或傳送給第三方。輸出會將 JSON-LD 容器(例如頂層物件、陣列與 @graph 節點)展開為各別項目，同時保留每個項目所宣告的 @type 與可見屬性。Microdata 則透過走訪已剖析 DOM 上的 itemscope、itemtype 與 itemprop 屬性來讀取，並讓巢狀項目保持可見的巢狀結構，而不是被靜默地攤平。你得到的，是針對你所貼上標記的一份證據報告，而不是該頁面會獲得複合式結果、或被任何特定搜尋引擎視為合格的承諾。
JSON-LD 檢查器內部的擷取實際會產生什麼
大多數「JSON-LD 檢查器」工具都從剖析開始，但讓輸出對範本除錯有用的，是擷取階段。真正的擷取器會走訪文件，尋找兩個對象:<script type="application/ld+json"> 區塊，以及帶有 Microdata 屬性的 HTML 元素。它找到的所有內容都會被正規化為一份項目清單，每個項目都帶有其宣告的 @type，以及來源中實際存在的屬性。缺少或空白的值會保持空白，而不是被靜默填入，這也正是讓你能夠發現「範本輸出了正確的欄位名稱、卻沒有實用值」的原因。
這份清單能回答你在編輯器中閱讀原始 HTML 時無法回答的問題。範本究竟有沒有輸出 JSON-LD 區塊?輸出了一個、多個，還是一個在 @graph 內含多個節點的區塊?同一頁面的 Microdata 版本是否因為連結用錯了屬性，而帶有不同的 URL?內容欄位是否輸出為空白?這些都是擷取結果，而不是驗證裁決。結構化資料檢查器與擷取器正是圍繞著這個區別所建構。它的首要任務是擷取。它會同時尋找 JSON-LD 與 Microdata、展開容器、把剖析錯誤與屬性警告分開呈現，並且只在工具具備已記錄規則集的位置套用必要屬性規範。其餘的則以資訊性觀察的形式呈現，而不是瑕疵。
擷取過程中 JSON-LD 容器如何被展開
JSON-LD 很少以單一平坦物件的形式交付。在已交付的 HTML 中常見三種形狀，而每一種都必須在擷取時處理，讓下游的屬性檢查看到的是真實的項目，而不是必須猜測的字串。
| 容器形狀 | 在來源中看起來的樣子 | 擷取器的處理方式 |
|---|---|---|
| 單一物件 | 在頂層的單一 {"@context":..., "@type":"Recipe", ...} | 回報為帶有該 @type 及其屬性的一個項目 |
| 頂層陣列 | 在頂層的 [{"@type":...}, {"@type":...}] | 陣列中的每個項目各自回報為帶有自身 @type 的獨立項目 |
| @graph 容器 | {"@graph":[{"@type":...},{"@type":...}]} | @graph 內的每個節點各自回報為帶有自身 @type 的獨立項目 |
在擷取階段展開這些形狀之所以重要，是因為必要屬性檢查需要一個真實的 @type 才能查詢。如果陣列被視為單一不透明區塊，工具就無法判斷 Recipe 與 FAQPage 是否同時存在，也無法判斷缺少的欄位究竟屬於哪個項目。同樣的邏輯也適用於毀損的 JSON 區塊:當某個指令碼剖析失敗時，格式錯誤的區塊會單獨回報，這樣同一份文件中其他位置找到的有效項目才不會被抹除。這種區隔正是讓擷取在範本除錯時真正有用的原因，而不僅僅是部署前最後一關。
透過 itemscope 與 itemprop 讀取 Microdata 項目
Microdata 存在於一般 HTML 中，而不是位於 script 標籤內。擷取器會在已剖析的 DOM 中走訪帶有 itemscope 與 itemtype 的元素，接著收集透過 itemprop、content 屬性、連結 href 值、媒體來源屬性、日期值與文字內容所公開出來的值。依據 WHATWG HTML Microdata 規範，每個 itemscope 會建立一個新項目，而巢狀的 itemscope 會形成一棵樹，而不是平坦的清單。
結構化資料檢查器與擷取器會保留這種巢狀的可見性。一個包含巢狀 Offer 項目的 Product 項目不會被壓扁成一串平坦的屬性;Offer 會保持巢狀，讓你能清楚看出哪個 URL、價格或可用性值屬於哪個範圍。這也是為什麼帶有缺少或空白值的項目會顯示為空白，而不是被靜默填入:擷取器回報的是來源實際包含的內容，而不是它「可能」代表的意思。如果範本為連結輸出了錯誤的屬性，清單會立即讓這一點變得顯而易見。
使用 Lizely 檢查器擷取結構化資料:實務工作流程
- 複製你想檢查的範本已交付的 HTML 來源。如果框架在初始回應之後又注入標記，也請匯出一份受控的已渲染 DOM 快照，讓你能比較伺服器送出的內容，與爬蟲實際收到的內容。
- 將 HTML 貼到結構化資料檢查器與擷取器中。這個工具永遠不會擷取網頁、執行其指令碼、或載入其資源，因此這一步只會留在你的瀏覽器內，不會把來源傳送到任何地方。
- 執行擷取，並區分工具回傳的類別:JSON-LD 剖析錯誤、Microdata 項目、宣告的類型與屬性，以及聚焦的缺少屬性警告。請逐一檢視每個類別，讓單一毀損的區塊不會掩蓋同一份文件中其他位置的有效項目。
- 對每個 JSON-LD 項目，請確認宣告的 @type 與範本預期輸出的內容相符，且每個屬性帶有實際值，而不是空白字串。對每個 Microdata 項目，請確認 itemscope 涵蓋可見元素，且 itemprop 值確實解析為文字、連結或日期。
- 請先解決剖析錯誤，在 JSON 解析乾淨之前，清單的其他部分都無法被信任。接著對照連結的文件檢視規範警告，並判斷哪些警告反映的是真正的缺漏，哪些只是該頁面確實可省略的屬性。
- 編輯來源範本、重新擷取，並確認警告已消失。只有在貼上的標記清理乾淨之後，才應該以目標搜尋功能的官方工具驗證已部署的 URL。
剖析錯誤、規範警告與資訊性註記
使用 JSON-LD 檢查器時最容易犯的錯誤之一，就是把每個警告都當成會阻擋流程的錯誤。Lizely 擷取器把三個類別在視覺上分開，每一個對你下一步該怎麼做，意義都不同。
| 類別 | 代表的訊號 | 所暗示的行動 |
|---|---|---|
| 剖析錯誤 | JSON 區塊無法被剖析，因此無法讀取屬性 | 修正範本直到區塊能正確剖析;在此解決之前，下游檢查都不值得信賴 |
| 規範警告 | 項目剖析成功，但缺少文件記載的必要或建議屬性 | 對照連結的文件;可選擇補上屬性，或確認該屬性對此頁面確實超出範圍 |
| 資訊性註記 | 類型或屬性存在，但沒有對應的文件化規範，或工具的已知限制在此相關 | 作為背景資訊使用，而不是要逐項處理的瑕疵清單 |
這種區隔之所以重要，是因為它能避免你「修好」其實沒有壞的東西。針對不熟悉的 Schema.org 類型所產生的屬性警告，並不代表頁面無效;它代表工具刻意沒有為它虛構一套規範。正確的回應是閱讀擷取出的值，並判斷頁面是否真的需要該欄位，而不是用捏造的值填入物件來讓警告消失。比起一個塞滿通用佔位符的大型物件，數量較少但完整且真實的屬性更為理想，而擷取報告的目的，正是讓這個區別變得顯而易見。
擷取之後該做什麼:先修範本，再驗證線上 URL
擷取能告訴你標記裡有什麼。它無法告訴你頁面是否會排名、被索引，或獲得複合式結果。一旦貼上 HTML 的清單清理乾淨，下一步就是以你實際鎖定功能的官方驗證工具，來驗證已部署的 URL。Google 在其 結構化資料介紹 中，記錄了 JSON-LD、Microdata 與 RDFa 對特定功能的支援;真正應該依循的工具，是與該功能綁定的工具，而不是一個通用型檢查器。
部署後有三項檢查值得納入例行作業，每一項回答的問題都與擷取器不同:
- 針對任何瞄準 Google 功能的類型，把已部署的 URL 跑過 Google 的複合式結果測試，以確認爬蟲收到的回應能正確剖析並符合該功能的預期。
- 在下次重新擷取後觀察 Search Console 的強化項目報告;那裡持續下滑通常代表範本漂移，而不是擷取問題。
- 以具代表性的紀錄(而不只是一個範例)測試實際的頁面範本，這樣某一變體上缺少的欄位才不會被忽略。
這也是 Lizely 擷取器的不擷取邊界發揮價值之處。由於這個工具永遠不會向線上 URL 發出請求，你可以從預備環境、匯出檔或本機建置貼上經授權的 HTML，而不會跨越跨來源失敗或私有網路請求。擷取結果是關於你所貼內容的證據;驗證器結果是關於爬蟲所收到內容的證據，兩者值得分開保留。
Limits the Extractor Will Not Cross
The Structured Data Checker & Extractor works inside a clearly drawn perimeter, and that perimeter is part of why its output is trustworthy. A few limits are worth keeping in mind so the inventory is not mistaken for a universal semantic-web verdict.
- It extracts JSON-LD and Microdata only. RDFa is outside the current product boundary and is shown as out of scope rather than counted as absent or invalid.
- It never fetches or runs a webpage. No script from the pasted document executes, links are not followed, images are not loaded, and forms are not submitted.
- Input size and item counts are bounded, so an accidental full-site dump cannot freeze the page; if you need to inspect a large set, batch the templates.
- Required-property guidance applies only where the tool has a documented profile. Unknown types are still extracted but are not assigned invented requirements.
- A clean extraction is evidence about the pasted document, not a guarantee of search appearance. Search engines decide whether and when enhanced presentation is shown.
Used that way, extraction becomes the transparent preflight step it is meant to be: paste authorized HTML, inspect every extracted item, resolve parse errors first, review profile warnings against the linked documentation, and then verify the deployed response with the official tool. The output is evidence about the pasted document, and a strong evidence base is what makes the rest of the workflow worth trusting.
For a deeper look, see Extract URLs From a Sitemap: A Quick Cheat Sheet.