Schema 通過 Google 的驗證工具，不代表 AI 引擎抓得到你的結構化資料，這兩件事走的是不同的解析路徑。Rich Results Test 只檢查 Google 支援的少數幾種 rich result 是否合格，Schema.org Validator 只檢查語法有沒有符合詞彙規範。兩者都不會告訴你，ChatGPT、Perplexity 或 Google AI Overviews 的爬蟲在你的頁面上實際讀到了什麼。很多頁面驗證全綠，卻在 AI 答案裡完全隱形，落差就在這裡。
為什麼「通過驗證」不等於「AI 讀得到」
驗證工具的工作是『合規檢查』，不是『可讀性檢查』。Schema.org Validator 把你的 JSON-LD 對照 schema.org 詞彙表，確認類型與屬性拼寫正確、巢狀結構合法；Rich Results Test 則模擬 Googlebot 渲染頁面，判斷這頁能不能觸發某種 rich result。這兩件事都做完，你只知道『語法沒錯』和『Google 願不願意給你 rich result』。至於 AI 爬蟲，它們多半直接抓伺服器回傳的原始 HTML，不執行 JavaScript，也不在意你有沒有 rich result 資格。真正決定 AI 讀不讀得到的，是那段 JSON-LD 到底有沒有出現在原始 HTML 裡、實體之間連不連得起來。
兩個必備工具，各自的盲點
先把兩個工具的定位講清楚，才知道各自漏掉什麼。
- Rich Results Test（search.google.com/test/rich-results）：會用 Googlebot 實際渲染頁面、執行 JS，逐項列出偵測到的 rich result 類型與錯誤警告。盲點是它只涵蓋 Google 支援的約三十幾種類型；你標了 Organization、Person 這類不觸發 rich result 的類型，它會顯示『未偵測到項目』，但那不代表你的 schema 無效。
- Schema.org Validator（validator.schema.org）：不管 Google 支不支援，把所有類型的完整實體樹攤開給你看，最適合檢查語法與詞彙。盲點是它預設不替你執行 JS，你貼原始碼或給它 URL 抓到的常是未渲染版本，而且它不告訴你 rich result 資格，也對某些語意錯誤過度寬容。
結論很直接：兩個都要用，而且要清楚自己這一步在查什麼。查語法與實體結構用 Schema.org Validator，查 Google rich result 資格與渲染結果用 Rich Results Test。兩者都不能替你回答『不跑 JS 的爬蟲看得到嗎』，那要靠下一步的原始碼檢查。
一套可重複的 Schema 驗證流程
把驗證拆成固定順序，每個頁面、每次改版都跑同一份清單，才不會每次憑印象檢查、每次漏掉不同的洞。
- 用 Schema.org Validator 貼上『渲染後』的 HTML，確認語法與詞彙無誤，並攤開完整實體樹，逐一核對類型與必填屬性。
- 用 Rich Results Test 輸入正式 URL，確認 Google 抓到的是渲染後版本，且你想要的 rich result 類型有被辨識、沒有紅色錯誤。
- 用 curl 或 view-source 抓『沒有執行 JS』的原始 HTML，搜尋 application/ld+json，確認 JSON-LD 真的在伺服器回傳的內容裡，這一步模擬的正是多數 AI 爬蟲的行為。
- 檢查 @id 與 @type 之間的交叉引用：Organization、WebSite、Article、Person 是否用一致的 @id 串成一張圖，讓引擎能判斷作者屬於哪個組織、文章屬於哪個網站。
- 把 schema 裡的值和頁面可見內容逐項對照，價格、標題、評分、日期都要一致，不一致時 Google 會直接忽略，AI 也會降低信任。
- 存一份基準快照，之後每次改版重跑整份清單，把差異當成 regression 來看。
AI 引擎真正讀不到的錯誤類型
語法過關的 schema，仍然有一整類『工具說沒問題、AI 卻讀不到』的錯誤。這些是我們替客戶做審計時最常抓到的：
- JSON-LD 由前端框架或 tag manager 在瀏覽器端注入，伺服器回傳的原始 HTML 裡一行都沒有，不跑 JS 的爬蟲完全看不到。
- @id 缺失或前後不一致，實體之間連不起來，引擎無法把作者、組織、文章綁成同一個知識圖譜節點。
- 類型選對了，值卻放錯欄位：把幣別塞進 price、把整段描述塞進 name、offers 裡少了 priceCurrency。
- 語法合法但語意殘缺：Product 沒有 offers、Article 缺 author 或 publisher、FAQPage 的 answer 是空字串。
- 同一頁有多段互相矛盾的 JSON-LD，例如首頁 template 帶的 Organization 和頁面自帶的打架，引擎無所適從。
- 日期不是 ISO 8601、圖片用相對路徑而非絕對 URL，這些在寬容的驗證器裡會過，但抽取時容易被丟掉。
別只看工具，要看『渲染後 DOM』和『原始碼』的落差
把驗證做紮實，關鍵是同時看兩個版本的頁面。打開 DevTools 的 Elements 面板，看的是瀏覽器渲染後的 DOM，這大致是 Googlebot 會看到的樣子；用 view-source 或 curl 看的是伺服器最初回傳的原始 HTML，這是多數 AI 爬蟲會看到的樣子。你的結構化資料如果只存在於前者、不存在於後者，那道落差就是 AI 讀不到你的地方。驗證工具幫你看第一個版本，第二個版本得自己動手抓。
Schema 驗證不是發布時做一次就結束的動作，而是每次改版都要重跑的關卡；CMS 一次升級、template 一次調整，就可能讓整棵實體樹默默散架。— Tenten GEO 技術審計筆記
把驗證變成發布前的固定關卡
最實際的做法，是把這份清單接進發布流程，而不是靠記憶臨時檢查。可以在 CI 裡加一支腳本，抓正式 URL 的原始 HTML、解析出 JSON-LD、比對必填屬性與 @id 引用，一旦缺漏就擋下部署；沒有 CI 的團隊，至少把六個步驟寫成發布前 checklist，改版後逐項打勾。結構化資料的價值在於穩定被機器抽取，而穩定來自流程，不是來自某次手動驗證的運氣。若你想知道自己的頁面在不跑 JS 的爬蟲眼中長什麼樣、哪些 schema 其實 AI 根本讀不到，可以到 /contact 預約一場 30 分鐘 GEO 診斷，我們用你的實際頁面跑一遍這套流程。
