Rich Results Test 與 GSC Schema 錯誤怎麼交叉診斷？

在進行任何網站的結構化資料實作後，如何驗證其正確性與效果，是確保搜尋引擎能正確理解頁面內容的關鍵。這過程的核心正是結構化資料驗證（structured data validation）。本文旨在建立一套系統性的交叉診斷流程，協助你區分 JSON-LD 語法、required/recommended property 缺失與 eligibility 不符等問題，並整合使用 Rich Results Test 與 Google Search Console (GSC) 這兩大工具，進行從單頁測試到全站監控的完整診斷。

先搞清楚：你遇到的 Schema 錯誤屬於哪一層？

在開始交叉診斷前，最重要的一步是正確「分類」你的問題。Schema 錯誤並非鐵板一塊，可以粗分為三個層次：JSON-LD 語法錯誤、required/recommended property 缺失，以及 eligibility 不符。語法錯誤是最基礎的問題，代表你的 JSON-LD 程式碼本身在格式上就不正確，例如缺少了引號、逗號，或是括號沒有正確配對，導致 Google 根本無法解析這段結構化資料。Property 缺失則更進一步，代表程式碼格式正確，但缺少了特定 rich result 類型所要求的必填欄位（required），或是會讓功能更完整的建議欄位（recommended）。最後，eligibility 不符是最常讓人困惑的「非技術性」問題：你的程式碼完美無缺，但頁面的內容或類型本身就不符合 Google 對於該種 rich result 的資格要求。

要快速判別，你可以想像一個三層過濾網。最外層是語法網，攔截格式錯誤；中間是屬性網，過濾欄位完整度；最內層是資格網，決定你的頁面「配不配」擁有這個搜尋結果樣式。例如，一篇關於「急性胃炎」的文章，若其 JSON-LD 中缺少了 `headline`（標題）或 `datePublished`（發佈日期），這就屬於第二層的 required property 缺失。但如果這篇文章的內容極短、僅有片段，或被歸類為非 E-E-A-T 的低品質頁面，即使你補齊了所有欄位，Google 仍可能判定它不符合「Article」類型 rich result 的資格，這便是第三層的問題。

第一步：用 Rich Results Test 檢查語法與資格

診斷的第一個實質工具，就是 Google 提供的 Rich Results Test。這是一個即時、單頁的檢測工具，它的首要任務是確認你的 JSON-LD 程式碼能否被正確解析。你只需要將頁面的網址，或是直接貼上你撰寫的結構化資料程式碼片段，點擊「執行測試」即可。工具會立刻反饋結果：如果存在語法錯誤，它會明確指出問題點，例如「JSON-LD 專案不完整」或「無法解析結構化資料」，這時你就需要回去檢查你的程式碼，特別是標點符號、屬性名稱的大小寫（`datePublished` 而非 `Datepublished`），以及巢狀結構是否正確。

除了語法，Rich Results Test 同樣會評估資格。如果語法無誤，它會顯示你的頁面「可能有资格顯示」的 rich result 類型，以及是否存在 required property 的缺失。這裡的關鍵字是「可能」。通過此測試，僅代表你的程式碼在技術上符合規範，但並不保證 Google 一定會在搜尋結果中呈現。若工具顯示「不符合資格」，通常會附上原因說明，例如「此頁面類型不支援此類型的結構化資料」，這就將問題指向了第三層的 eligibility 層面，你需要回到 JSON-LD Schema 完整指南 中，確認該 rich result 的具體資格要求。

第二步：用 GSC 增強功能報告追蹤實際收錄狀況

Rich Results Test 是個體檢，而 Google Search Console 的「增強功能」報告則是全站的健檢報告。它反映的是 Google 爬蟲實際收錄、解析你的網站後，所發現的問題總覽。進入 GSC 後，在左側選單找到「增強功能」，你會看到如「文章」、「產品」等不同類別。點進去，狀態會區分為「有效」、「警告」與「錯誤」。這裡的「錯誤」對應的是阻擋 rich result 顯示的嚴重問題（如語法錯誤、必填屬性缺失），「警告」則可能是建議屬性缺失或潛在的非致命問題。

這個報告最大的價值在於它的「批次性」與「時效性」。它顯示的是過去一段時間內，Google 所爬取的你網站上所有相關頁面的狀態，而非單一頁面。如果你在 Rich Results Test 中測試單一頁面顯示通過，但 GSC 報告中卻列出了大量錯誤，這可能意味著你的錯誤範圍更廣，或是你的網站上存在著測試工具未覆蓋到的其他問題版本。報告中每個項目都可以點擊展開，查看具體的受影響 URL 列表，讓你精準定位哪些頁面需要修復。

第三步：交叉比對 Rich Results Test 與 GSC 的結果

當兩個工具的結果都到手後，交叉比對就成了關鍵診斷步驟。最理想的情況是兩者一致：Rich Results Test 顯示錯誤，GSC 報告中也對應出現相同錯誤。這時你可以很有信心地直接修復。但不一致的情況也時有發生，這時就需要推理判斷。如果 Rich Results Test 顯示一切正常，但 GSC 報告中該頁面仍標記為「錯誤」，最常見的原因是「時間差」。你可能剛修復完程式碼並在測試工具中驗證通過，但 Google 爬蟲尚未重新爬取該頁面，因此 GSC 報告中仍保留著舊的錯誤狀態。

此時，你可以利用 GSC 的「網址檢查」工具，輸入該個別 URL，然後點擊「請求編入索引」，主動要求 Google 重新爬取。提交後，通常需要等待數天，增強功能報告才會更新。另一種可能的不一致是「測試與真實環境的差異」。Rich Results Test 對待測試的 URL 或代碼片段相對寬容，但 GSC 反映的是正式收錄的頁面。例如，你的測試 URL 位於測試子網域，但正式頁面位於主網域，兩者的部署版本可能不同步。因此，最終的權威依據應是 GSC 報告，因為它代表了 Google 眼中的線上真實狀況。

常見誤判：為什麼 Schema 有效卻沒有複合式搜尋結果？

這可能是最令網站管理員挫折的情況：你所有的技術步驟都正確，Schema 檢測工具顯示通過，但搜尋結果中就是看不到美觀的 rich result。這時，問題往往出在技術之外的領域。首先，你的頁面內容可能不符合 Google 對該 rich result 的內容政策。以「產品」評論為例，Google 要求必須是真實的用戶評論，且頁面不能設有付費牆完全遮蔽評論內容。如果你的評論是自己編寫的樣本，或是內容僅是促銷文案，即便程式碼正確，資格也不會通過。

其次，Google 對 rich result 的展示保留最終決定權，它並非一項權利。展示與否會考量頁面的品質、權威性以及在搜尋結果中的整體排名。一個新發布或低流量的頁面，即使 Schema 完美，Google 也可能選擇暫時不為其顯示 rich result。此外，某些 rich result 類型可能存在地域或語言限制。最後，請理解 rich result 的展示是「有可能」，而非「保證」。Google 會基於搜尋體驗的整體考量，動態調整展示策略。因此，當技術面確認無誤後，你應專注於提升頁面內容品質與權威性，並透過 GSC 的「成效」報告觀察該頁面的曝光與點擊變化，以評估整體策略是否有效。

修復優先順序：哪些錯誤該先處理？

面對一堆錯誤清單，合理的修復順序能讓你事半功倍。優先順序的核心原則是：先處理「阻擋性」問題，再處理「優化性」問題。最優先的，當然是 JSON-LD 語法錯誤與 required property 的缺失。語法錯誤會導致整個結構化資料塊失效，Google 無法解析其中任何資訊。必填屬性（required）的缺失，則會直接讓該 rich result 類型不符合資格，無法顯示。這兩類問題應被視為緊急修復項目。

接下來是 recommended property 的缺失。這類欄位並不會阻擋 rich result 顯示，但補齊它們可以豐富你的搜尋結果摘要，例如添加 `image`、`author` 或 `review` 等資訊，提升點擊吸引力。這類問題可以排在第二順位，視為功能優化。最後，eligibility 不符的問題可能需要最深入的評估。你必須判斷，為了獲得這個 rich result，去調整頁面內容（例如增加評論區塊、改寫文章結構）是否符合你的整體內容策略與資源。有時，放棄或轉換使用其他更合適的 schema 類型，可能是更務實的選擇。在修復過程中，善用 GSC 錯誤訊息中的屬性名稱（如 `headline`），可以幫助你快速在程式碼中定位到對應行數進行修改。