使用 JSON-LD 檢查工具時，真正重要的細節包括來源邊界、項目邊界、已宣告的 @type 值、屬性值、解析錯誤，以及標記與使用者可見頁面之間的一致性。請將擷取結果視為清單，而不是判定。這個 Structured Data Checker & Extractor 可讓你透過本機方式檢查貼上的 HTML 中既有的 JSON-LD 與 Microdata。它會展開 JSON-LD 容器、列出每個找到的類型與屬性、在有界限的檢視畫面中保留巢狀項目關係，並分別回報格式錯誤的區塊。其針對性缺少屬性警告僅適用於明確支援的設定檔，因此即使是不熟悉的類型，仍可擷取該類型，而不會被套上憑空捏造的需求。這項區分可避免稽核過度斷言：語法正確仍可能描述不準確、隱藏、無關或與頁面不一致的內容。同樣地，本機警告並不能證明搜尋引擎會拒絕該標記。若要支援 Google 功能，本機清單是使用 Google 官方驗證工具測試已部署 URL 前的預檢檢查點。
確認你要測試的 HTML 層級
擷取結果只能描述放入檢查工具中的來源。在解讀任何結果之前，請先確認來源：
- 傳送的 HTML：當伺服器傳回的回應包含結構化資料時，請使用該回應。這是初始頁面內嵌標記最相關的證據。
- 受控的算繪 DOM 匯出：若框架在載入後加入結構化資料，請使用匯出的 DOM 快照。此匯出必須代表你實際要檢查的階段。
- 多個階段：若用戶端程式碼可能修改標記，請比較原始回應、算繪後的 DOM 與檢索機器人可見的輸出。某個階段的乾淨結果無法證明另一個階段也包含相同資料。
此檢查工具刻意不會要求遠端 URL 或執行貼上的頁面。它會在分離的瀏覽器範本片段中解析來源，將有界限的擷取值算繪為文字，而且不會執行指令碼、follow 連結、載入圖片、提交表單或將來源傳送給 Lizely。解析作業發生於瀏覽器中。輸入大小與項目數量皆有界限，因此請使用經授權且具代表性的頁面或範本片段，不要意外貼入整個網站傾印內容。
分開閱讀解析錯誤、清單與警告
有用的問題不是頁面是否得到一個綠色或紅色結果，而是輸出的每個部分對貼上的文件證明了什麼。請區分以下訊號：
| 訊號 | 可證明的事項 | 無法證明的事項 |
|---|---|---|
| JSON-LD 解析錯誤 | 特定指令碼區塊包含格式錯誤的 JSON，因而無法依預期讀取。 | 這不會使其他區塊中找到的有效項目失效。 |
| 擷取的項目 | 檢查工具找到一個項目，並可顯示其已宣告的類型與可見屬性。 | 僅憑其存在並不能證明具備搜尋資格。 |
| 缺少屬性警告 | 明確的本機設定檔找不到該設定檔涵蓋的屬性。 | 這不能證明搜尋引擎會拒絕該頁面。 |
| 資訊性觀察 | 有某個邊界或結構細節值得檢查。 | 這不一定構成驗證失敗。 |
| 官方功能驗證 | 已部署的 URL 已依特定搜尋功能的現行規則進行測試。 | 這無法保證索引、排名或 rich result。 |
這種區分可避免一項常見的類別錯誤：將語法有效性視為內容準確性或搜尋核准。Schema.org 定義了廣泛的詞彙，而各個搜尋產品則定義自己的必要與建議屬性。因此，檢查工具僅套用有文件規則集支持的、可檢查的設定檔。未知類型仍可擷取，但工具不會為其捏造需求。它的首要工作是擷取，而非評分 rich result 資格。
保留容器與項目邊界
JSON-LD 可能以單一物件、物件的頂層陣列，或包含多個節點之 @graph 的物件形式出現。檢查工具會將這些容器展開為個別清單項目，同時保留已宣告的 @type 值與可見屬性。請將展開後的項目與原始容器比對，以免忽略藏在 @graph 內的節點。格式錯誤的指令碼會單獨回報，讓同一文件中的其他位置仍能顯示有效物件。
Microdata 透過一般 HTML 遵循不同的處理路徑。itemscope、itemtype 與 itemprop 等屬性會建立項目與屬性。檢查工具會建立頂層項目的有界限檢視，並辨識透過內容屬性、連結、媒體來源屬性、日期值與文字內容公開的值。巢狀 Microdata 項目會保持可見的巢狀關係，而不會被扁平化為無關字串。相關基礎屬性與處理模型記載於 WHATWG HTML Microdata 規格。
| 格式 | 要檢查的細節 | 邊界 |
|---|---|---|
| JSON-LD | 單一物件、陣列、@graph 節點、已宣告類型、屬性與格式錯誤的指令碼區塊。 | 當另一個指令碼區塊解析失敗時，有效項目仍可回報。 |
| Microdata | 項目範圍、項目類型、屬性屬性、由屬性衍生的值、文字、日期、連結與巢狀項目。 | 顯示的屬性檢視有界限，尤其是頂層清單項目。 |
| RDFa | 不會執行擷取或設定檔評估。 | RDFa 位於產品邊界之外，絕不會被計為缺少或無效的結構化資料。 |
項目邊界很重要，因為屬性只有在附加至正確實體時才可能具有意義。在依警告採取行動前，請確認該值屬於預期的物件、圖形節點或 Microdata 範圍，且未被拉入無關項目中。
依實體與目標評估每個屬性
並不存在一份對每個使用者皆重要的通用屬性清單。請檢查決定每個擷取項目是否能準確代表預期頁面的細節：
- 實體身分：確認預期項目確實存在，且其已宣告的 @type 或 itemtype 與頁面描述的實體相符。
- 屬性相關性：判斷每個值是否具體、即時且對該實體有用，而不是僅為讓物件看起來完整而存在。
- 來源對應：將值追溯至確切的 JSON 欄位或 HTML 屬性。這有助於說明空白 URL 是由錯誤屬性造成，而非真的缺少頁面網址。
- 可見內容一致性：將名稱、說明、日期、圖片、價格、身分與其他擷取主張，與使用者實際可見的內容比較。即使 JSON 能成功解析，隱藏、捏造或無關的值仍是內容問題。
- 功能需求：查閱特定搜尋功能的現行文件。即使不同使用者使用相同的 Schema.org 詞彙，其必要與建議屬性仍可能不同。
- 重複項目與變體：檢查範本是否輸出同一實體兩次、在其中一種記錄類型中省略欄位，或混合不同頁面狀態的值。
請以 Google 的 結構化資料簡介 作為理解結構化資料廣泛用途的起點，再依循目標功能的文件。針對性警告應促使你檢查來源，而不是自動插入欄位。與其使用大量僅為消除警告而加入通用值的物件，寧可提供較少但完整且真實的屬性。
擷取並檢查提供的 HTML
- 收集正確的來源。從經授權的傳送 HTML 或受控的算繪 DOM 匯出開始。記錄來源代表哪個頁面狀態與算繪階段。
- 將來源貼入檢查工具。不要貼上 URL 並期待即時擷取。此工具會在本機分析提供的 HTML，絕不會要求或執行該頁面。
- 執行擷取。讓檢查工具先找出 JSON-LD 指令碼區塊與 Microdata 項目，再檢查產生的清單。
- 先解決解析錯誤。分別檢查格式錯誤的 JSON，並修正受影響的來源區塊。不要假設此錯誤已移除文件其他位置原本有效的項目。
- 檢查每個找到的項目。檢查其已宣告類型、屬性與容器。對 JSON-LD，請納入物件、頂層陣列與 @graph 節點考量。對 Microdata，請驗證範圍、屬性屬性與巢狀關係。
- 在脈絡中閱讀針對性警告。確認項目具有文件化的設定檔，在來源中檢查缺少的屬性，並與可見內容及現行功能指引比較。不要為不熟悉的類型捏造規則。
- 修正來源範本。修正產生問題的範本或記錄變體，移除重複或不準確的標記，並測試具代表性的範例，而不是只測試一筆異常完整的記錄。
- 轉至已部署內容的驗證。修正後的回應公開後，使用目標搜尋功能的官方驗證工具測試已部署的 URL。
確認已部署的回應包含哪些內容
本機乾淨的結果是關於單一貼上文件的證據，而不是公開回應的證明。部署後，請檢查實際 URL，因為伺服器設定、算繪、重新導向或框架行為可能改變檢索機器人收到的內容。若該類型旨在支援 Google 功能，請在已部署頁面上使用 Google Rich Results Test，並在重新檢索後檢查 Search Console 增強報告。若是其他搜尋功能，請使用該使用者的官方驗證流程。
請測試頁面範本中具代表性的記錄，包括可能含有選填欄位、長值、巢狀實體或缺少資料的記錄。是否以及何時顯示增強呈現由搜尋引擎決定。沒有任何本機檢查工具能保證索引、排名或 rich result。
最終證據簽核
部署前，請確認您能回答以下擷取問題：
- 測試了哪個 HTML 來源與算繪階段？
- 每個 JSON-LD 區塊是否都能成功解析，且有效項目是否已保留在其他位置？
- 物件、陣列、@graph 與 Microdata 的邊界是否符合預期實體？
- 宣告的類型與屬性是否存在、具體且正確巢狀？
- 每個重點警告是否都有文件化的設定檔與來源層級說明？
- 擷取的主張是否與使用者可見的內容相符？
- 重複項目、空白值及特定記錄遺漏是否已在範本中解決？
- 修正後的部署回應是否已通過預期功能的官方測試？
這些證據可為您提供的標記提供透明的部署前檢查，並將擷取事實、設定檔警告、內容審查與搜尋資格維持為各自獨立的決策。