Boloop 閱讀示意圖（AI 生成）：解析、語義、功能資格和實際表現需要分別核對。
Boloop 做結構化數據檢查時，出現過一種很容易讓人提前結束工作的畫面：測試器顯示有效項目，頁面上卻仍有圖片抓取限制，軟件也沒有可核實的報價和評分。
綠色結果有價值，只是它回答的問題比「SEO 做好了沒有」窄得多。後來我把檢查拆開記錄：數據能否解析、描述是否真實、目標功能要求是否滿足，以及搜索中實際發生了什麼。
先把兩個驗證器的工作分清
Schema.org Validator 幫助檢查所用詞彙和結構是否成立。Google 富媒體結果測試面向 Google 支持的搜索功能，可能識別文章、軟件或麵包屑，但不會把所有 Schema.org 類型都列為獨立的富結果。
Boloop 的作品頁用了 CreativeWork 和圖片實體。Google 測試當時只顯示有效麵包屑，這不能推導出作品描述無效，也不意味著應該删掉其餘真實語義去迎合項目數量。
反過來，一個類型在工具裡被識別，也不足以證明它已滿足某項搜索展示的全部文檔要求。Google 的結構化數據說明明確區分其搜索功能約定與更廣泛的 Schema.org 詞彙。
軟件頁的綠色，暴露了工具與資格的差別
我們檢查 Magpie 推薦頁時，Google 測試列出了有效的 SoftwareApplication，同時把缺少報價和聚合評分顯示為非嚴重提示。
如果只截一張綠色截圖，很容易寫出「軟件富結果已經全部通過」。但逐項對照Google 軟件應用文檔，其中要求價格，以及符合條件的評價或評分。工具提示的措辭並沒有替我們補齊這些事實。
我選擇讓缺失的數據繼續為空。開源許可證不能自動證明所有分發方式都免費，GitHub stars 不是用戶評分，本站點讚也不能換算成星級。若頁面沒有真實、可見、適用的報價和評價，就不能為了消掉提示填一個零價格或一組分數。
這一页可以具有真實的語義描述，同時還沒有滿足目標富結果的全部要求。把兩項結論分開，後續才知道缺的是數據，還是代碼。
作者、發布者和更新時間各有各的位置
Boloop 同時有原創文章、外部推薦和互動作品。网站負責發布一個推薦頁面，不會因此成為被薦軟件或原文的作者。修正作者關係時，我們保留第三方創作者，只把已確認的原創文章作者統一為 Tink，並讓它們引用同一個公開人物身份。
頁面上的名字、About 資訊和結構化數據需要相互對應。sameAs 只連接已經核實的公開身份，不能因為想豐富人物節點而添加未經確認的公司、履歷或社交賬號。
日期也有類似問題。我們的 CMS 原有公開時間字段會隨重新發布而更新，因此界面把它明確標為「最近更新」，結構化數據繼續使用 dateModified。沒有可靠的首次發表記錄時，不從創建日期猜一個 datePublished，也不把最近一次重新發布悄悄寫成第一次發表。
這樣做減少了一些字段，卻讓讀者看到的時間含義更準確。
圖片字段還要把追到真實响應
文章聲明了 image，檢查並沒有結束。圖片需要確實與內容有關，頁面能看到，引用地址能被相应抓取系統訪問。圖片 URL、正文、結構化數據和分享資訊之間也應保持一致。
2026 年 10 月 22 日，我們在缺陷修復指南上發現：圖片本身能加載，Google 測試也識別到有效文章，但資源路徑仍受到 API 的爬取規則和 noindex 響應頭限制。這個例子說明，字段存在和頁面看起來正常，都不能替代圖片訪問檢查。
同樣，沒有適用圖片的頁面也不應該把 Logo、裝飾紋理或虛構截圖塞進字段。新配圖可以在內容需要時製作，並清楚說明它是閱讀示意圖，不能冒充產品真實界面。
把驗收結果寫成四層
我現在為結構化數據保留四類結論：
| 檢查層 | 要回答的問題 | |---|---| | 解析 | 線上實際 HTML 或渲染後的數據能否讀出，語法是否正常？ | | 語義 | 實體、關係和字段是否對應當前可見內容與可靠來源？ | | 功能資格 | 對照目標搜索功能的官方要求，還缺哪些適用事实或訪問條件？ | | 實際表現 | Search Console 與搜索結果中，是否觀察到抓取、索引和相应展示？ |
每個實際測試保留自己的頁面、語言和結果。某次繁體中文測試如果尚未完成，就不能拿英文結果代替；一個工具停在提交界面，也不能被寫成頁面測試失敗或成功。
這套拆分讓我們停止用「零錯誤」概括所有事情。標記描述正確，是已經做完的一部分；搜索引擎會不會抓取、索引和採用某種展示，還要看後續證據。Google 軟件文檔也說明，結構化數據功能並不保證展示。
如果你正讓 AI 給网站補 Schema，可以要求它同時交付可見字段對照和缺失事实列表。比起一口氣生成更多類型，這更容易發現一段看起來完整的 JSON-LD 到底有沒有描述真實的网站。