JSON-LD 驗證：分開檢查語法、內容一致與搜尋功能

「驗證工具亮綠燈」不是完整的驗收條件。JSON 可能有效，卻描述了錯誤企業、過期價格或讀者看不到的問題。工具也可能因為只測特定搜尋功能，而沒有列出某個 Schema.org 類型。

這篇用來驗收既有實作。Google 的 AI 搜尋優化指南不要求特殊 GEO 標記。任務是準確描述頁面，並知道每個檢查能證明什麼，不是累積驗證徽章或承諾 AI 引用。

1. 解析資料，確認嵌入 HTML 的邊界

先確認物件是有效 JSON。使用 JSON 序列化工具，避免自行拼接字串。解析可以抓出逗號或引號錯誤，但無法證明資料中的陳述是真的。

接著檢查資料如何進入 HTML。編輯者或使用者提供的文字可能包含影響 script 元素邊界的字元。應使用框架文件提供的安全嵌入方式，妥善處理小於符號；不能把 JSON 序列化本身當成 HTML 安全保證。這段程式變更時，檢查實際輸出及代表性的邊界案例。

以下是教學範例，不會成為頁面額外的即時標記。對應的可見問答是：

JSON 語法檢查能確認什麼？ 能確認資料可解析為 JSON，不能確認陳述為真。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "JSON 語法檢查能確認什麼？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "能確認資料可解析為 JSON，不能確認陳述為真。"
      }
    }
  ]
}

2. 檢查實際使用的詞彙

使用 Schema.org 驗證器檢查一般詞彙，並閱讀相關類型定義，包括 DefinedTerm、FAQPage與 HowTo，再判讀屬性與警告。

欄位被接受，不代表語意就正確。名詞定義不是產品資格；常見問答不是讀者共同回答的討論區；行銷時程也不一定是可以執行的程序。應修正語意不符的地方，而非不斷加欄位讓工具停止警告。

3. 比對實際內容與頁面身分

檢查目標路由及真正撰寫的語言版本。標題、描述、canonical 與實體關係應指向同一個頁面。文章標記保留原始發表日期，只有實質編輯時才填入真實修改日期。

逐一比對標記的問答、定義與步驟，確認讀者能取得相同意思與限制條件。可見文字不需要與 JSON 逐字相同，但必須支持同樣的內容。Google 結構化資料政策要求標記準確反映可見資訊。

在回傳的 HTML 確認預期的 application/ld+json 元素。教學範例應顯示為程式碼，不應意外變成額外執行的 script 元素。共用版型若產生很多頁面，應檢查代表性變體及資料契約，不必手動重查每個沒有變更的頁面。

4. 另外確認當前搜尋功能

Google 的工具指引區分了測試 Google 支援功能的 Rich Results Test，以及一般 Schema.org 驗證。某個類型沒有產生支援結果，不足以證明它的詞彙無效。即使標記有效且符合資格，也不能保證搜尋呈現。

實作時要查當前文件。Google 更新紀錄指出，FAQ 複合式搜尋結果自 2026 年 5 月 7 日起停止顯示，相關文件於 6 月 15 日移除。本文的 FAQPage 範例用來說明詞彙，並非取得該功能的方法；也不能從這次 Google 變更推論其他產品。

用明確紀錄完成驗收

記下受影響的路由、資料版本、已執行的檢查與尚存限制。「JSON 可解析、類型語意適合、輸出與內容一致、日期真實」是具體的實作結果。「AI 引用會增加」需要另外的觀察，不能從驗證直接推出。

小型事實修正，可能只需一次相關來源與輸出檢查。共用序列化工具、語言路由或外部資料邊界變更，則需要較廣的代表性涵蓋。只在相關變更或失敗後重跑，不把驗收變成無止盡的微調循環。目標是可信的既有頁面，以及可供覆核的改動。