一款採用分離式範本模式的本地 JSON-LD 檢查器,絕不會擷取您的網頁、不會執行其中的腳本,也不會將您的原始碼傳送到任何地方。 結構化資料檢查與擷取工具完全在您的瀏覽器內執行。您貼上既有的 HTML,工具會在隔離的文件片段中解析該段文字。該片段與即時頁面分離,因此貼上的內容中沒有任何腳本能存取您的 Cookie、 session 或網路。工具不會跟隨連結、載入圖片、提交表單,也不會執行內嵌的 JavaScript。它同樣不會從遠端伺服器請求 URL,這代表不會有跨來源失敗、私網路呼叫,也不會有稽核到與搜尋爬蟲實際接收內容不同的標記的風險。您在結果中看到的一切,都是針對您所貼上文字的清單,而不是關於搜尋引擎將如何處理您頁面的承諾。

這個界線之所以重要,有兩個實際的原因。第一,即時擷取可能會回傳與您寫入範本的不同文件,因為框架、邊緣運算服務和個人化層會在初始回應之後注入標記。第二,任何會執行您腳本的工具,都可能觀察到您無意分享的行為或資料。純貼上的工作流程能讓稽核聚焦在您能掌控的原始碼,並一次排除這兩個變數。

does the checker fetch or run my webpage when using json ld checker
does the checker fetch or run my webpage when using json ld checker

「擷取」或「執行」實際上會對您的頁面造成什麼影響

擷取 URL 的工具會對伺服器發出 HTTP 請求、接收伺服器送出的回應主體,然後解析該主體。執行頁面的工具則做更多事:載入圖片和樣式表、執行 JavaScript、觸發事件、跟隨重新導向,甚至可能提交表單或觸發分析事件。對結構化資料稽核而言,這兩種行為都會產生與標記品質無關的問題。

下表摘要說明即時擷取或執行頁面工具,以及結構化資料檢查與擷取工具的純貼上做法之間的實際差異。

結構化資料稽核期間的行為即時擷取或執行頁面工具結構化資料檢查與擷取工具
對您的伺服器發出 HTTP 請求是否
執行文件中的腳本是否
載入圖片、樣式表及其他資源是否
可能提交表單或觸發分析信標是否
稽核到的標記可能與爬蟲可見的 HTML 不同是否,這是設計上的預期
從文件中解析 JSON-LD 與 Microdata是是
依據已記載的設定檔報告聚焦的缺漏屬性警告有時是

即時擷取可能誤導您。一個對匿名請求回傳一份文件、對已登入使用者回傳另一份文件的頁面,會讓檢查器收到伺服器決定送出的那一個版本。爬蟲可見的 HTML、轉譯後的 DOM 與原始回應之間常常會有難以察覺的差異,特別是在仰賴用戶端轉譯的網站上。如果您的稽核跑在錯誤的版本上,您可能會新增實際上從未進入索引的欄位。

會執行您頁面的工具會帶來更廣泛的風險。貼上的 HTML 可能包含追蹤像素、第三方腳本和分析信標。即便是沙箱化的 iframe,也可能從檢查器內部發出網路請求。那些到達內部端點的請求,可能洩漏關於您測試環境、CMS 或訪客識別碼的資訊。純貼上的工具將文件視為惰性文字,因此不會產生任何這類副作用。

分離式瀏覽器範本如何維持本地解析

擷取引擎採用分離式範本模式。當您貼上 HTML 時,解析器會在您的瀏覽器分頁內建立一個隔離的文件片段。該片段並未掛載到即時 DOM,因此貼上文字中的任何 script 標籤會被解析為 script 元素,但永遠不會執行。該片段存在的時間僅夠解析器走訪其節點、收集 JSON-LD 區塊並讀取 Microdata 屬性。

JSON-LD 位於 <script type="application/ld+json"> 元素內部。檢查器會讀取這些元素的文字內容、執行 JSON 解析器,並將結果展開成個別項目。單一物件會變成一個項目;陣列會變成項目清單。@graph 節點則會展開為其所包含的項目,每個項目皆保留其宣告的 @type 與可見屬性。如果某個 script 區塊解析失敗,錯誤會分別回報,因此同一份文件中其他有效的項目不會被抹除。

Microdata 位於使用 itemscope、itemtype 與 itemprop 屬性的普通 HTML 之中。檢查器會走訪解析後的片段,並為每個頂層項目建構一個受限的屬性檢視。透過內容屬性、連結、媒體來源屬性、日期值與文字內容所暴露的值,皆會被讀取。巢狀項目在顯示時會保持巢狀結構,而不是被靜默地攞平為無關的字串,這讓您更容易察覺某個本應輸出具巢狀 NutritionInformation 的 Recipe 範本遺失了內部結構的情況。

輸入大小與項目數量皆受到限制,以避免一次意外的全站傾印讓分頁卡住。分離式片段的存在時間也很短:一旦解析完成,片段就會被捨棄。您貼上的文件中沒有任何內容會觸及網路、父頁面或 Lizely 伺服器。

檢視 JSON-LD 與 Microdata 而不暴露原始碼

  1. 在瀏覽器中開啟結構化資料檢查與擷取工具。無需帳號、登入或上傳步驟。
  2. 將已交付的 HTML 原始碼 (也就是您伺服器實際送出的回應主體) 貼到輸入區域中。若您的框架在載入後注入標記,請一併貼上一份可控的轉譯後 DOM 匯出檔與原始回應,以便進行比較。
  3. 執行擷取。工具會走訪分離式片段,找出每一個 JSON-LD 區塊與 Microdata 項目,並以清單形式呈現,而不是給出一個評分。
  4. 先讀取解析錯誤區段。格式錯誤的 JSON 區塊會以獨立的一行回報;在信任其餘清單之前,請先修正這些錯誤。
  5. 逐一檢視擷取出的項目。確認宣告的 @type 與頁面可見的內容相符、必填屬性皆已存在,以及您的範本未輸出重複的項目。
  6. 閱讀聚焦的缺漏屬性警告。警告代表支援的設定檔在您貼上的標記中找不到某個屬性;這並不證明搜尋引擎會拒絕該頁面。
  7. 檢查巢狀值。Microdata 的巢狀結構應反映您預期的關係,JSON-LD 的 @graph 節點亦應仍可暴露其內部類型。

如需進一步了解上傳與貼上的差別,請參閱 能在不上傳檔案的情況下使用 JSON-LD 檢查器嗎? — 它從不同角度說明了相同的本地解析界線。

使用官方工具驗證已部署的 URL

本地檢查器僅回報關於您貼上文件的事實。是否符合任何特定搜尋功能的資格,則是另一個問題,只有搜尋引擎本身能回答。在您根據本地清單修正完範本後,請部署變更,並透過對應的官方驗證工具執行公開 URL。

針對鎖定 Google 功能的所有類型,可參考 Google 的 結構化資料介紹,其中列出每項功能所需的格式與屬性。複合式結果測試工具 (Rich Results Test) 會執行已部署的 URL、執行該頁面,並回報是否適用特定的複合式結果功能。Search Console 的強化功能報告則能確認重新抓取是否已納入該變更,以及 Google 是否認為該標記符合資格。

針對 Microdata,WHATWG HTML Microdata 規格定義了 itemscope、itemtype 與 itemprop 彼此的互動方式。當本地檢查器回報 Microdata 的 URL 為空時,原因幾乎都是錯誤的元素上放了錯誤的屬性 — 該規格是確認解析器應當看到什麼內容的最快方式。

請在具有代表性的紀錄上測試實際的範本。單一產品頁可能通過驗證,而同站的類別頁卻輸出重複;食譜範本可能在某道菜上通過,在另一道菜上卻失敗。在您請 Google 重新抓取之前,本地擷取的速度快到足以在各種變體間重複進行。

值得了解的限制與邊界情況

本檢查器僅擷取 JSON-LD 與 Microdata。RDFa 不在目前的產品範圍內,且永遠不會被計為缺失或無效的結構化資料。若您的網站仰賴 RDFa,即使本地結果乾淨,也無法反映您的標記是否正確;您需要使用另一個針對該詞彙的驗證工具。

必填屬性的指引無法取代內容審查。標記應代表使用者實際看得到的內容,且應使用具體且正確的值。為了消音警告而新增欄位,反而可能降低實作品的可信度。少量完整且真實的屬性,通常優於一個塞滿籠統或捏造值的大型物件,因為搜尋產品公布的政策會看穿標記,直接檢視可見的頁面。

分離式範本解析器並不會模擬所有消費者。它會依據已記載的設定檔回報解析錯誤與聚焦的屬性缺口;但它不會像瀏覽器那樣執行頁面,也無法告訴您特定搜尋引擎是否會索引、排名或強化您的結果。請將本地清單視為透明的預檢工具,接著再用您實際目標搜尋功能對應的官方工具驗證已部署的回應。

延伸閱讀:避免使用 JSON-LD 檢查器時犯錯。