很多站長做站点自查时，會把注意力放在标题、描述、内鏈這些肉眼能看到的地方，却忽略了一段躺在 HTML 里的 JSON-LD。结构化資料不改變頁面外观，但它决定了搜尋引擎讀取頁面时，能不能准确分清“這是一篇文章”“這是一個商品”“這是一條問答”。分不清，頁面照样能被收錄，只是很多本可以传達的信息被浪費了。
结构化資料到底解决什么問题
搜尋引擎抓到一個頁面，看到的是大量标簽和文本。它能大致判断主题，但未必能分清哪段是發布時間、哪段是作者、哪個數字是價格、哪個是评分。结构化資料的作用，就是用一套约定好的字段，把這些信息顯式标注出来，减少對方的猜测成本。
需要先说清楚：它不是排名開關。标了不等于排得更好，也不等于一定會出現富媒体结果。它更像一份寫得工整的简歷，让對方少花時間理解你，但不保證给你面试机會。
不同類型頁面，标记重点不一样
- 文章頁：Article 或 BlogPosting，重点标 headline、datePublished、dateModified、author、publisher、mainEntityOfPage、image。
- 列表與分類頁：ItemList 或 CollectionPage，帮助說明這頁是聚合關系，而不是單獨一篇文章。
- 商品頁：Product 搭配 Offer，價格、货幣、库存狀態要與頁面上顯示的一致。
- 問答與帮助頁：FAQPage，但問题和答案必须是頁面上真實可见的内容。
- 全站通用：Organization 标注站点主体信息，WebSite 可加 SearchAction 指向站内搜尋。
自查时最容易踩的几個坑
- 标记與頁面内容不一致。頁面上寫 199，标记里寫 99，一旦被识別，轻則這條标记被忽略，重則整站标记的可信度下降。
- 必填字段缺失。headline 空着、image 寫了個不存在的路径、author 只留一個空對象，都可能让整段标记失效。
- URL 不是規范地址。标记里的 url、mainEntityOfPage 建议寫绝對地址，並且與 canonical 保持一致，避免同一内容出現两種寫法。
- 日期格式随意。datePublished 推荐 ISO 8601，例如 2025-03-18T09:00:00+08:00，別寫成“3月18日”這種自然語言。
- 同一類型重复多份。一個頁面塞三段互相矛盾的 Article，解析时不知道以哪份為准。
- 無差別堆砌類型。為了覆盖面把所有類型都标一遍，反而模糊了頁面真正的主体。
- 前端渲染導致标记丢失。如果标记只在客戶端生成，要先確認抓取时能不能看到。
上线流程建议
比較稳妥的做法是先在模板层加，再挑几個有代表性的頁面驗證，最後全量铺開。驗證分两步：用通用的结构化資料校驗工具看语法是否正确，再到搜尋平台的富媒体报告里看實际解析结果。两處都通過，這一步才算做完。
改版时尤其要注意同步。模板換了一版，字段名拼错、日期變量没輸出、图片地址變了，都會让原本正常的标记悄悄失效。可以在改版清單里加一條：结构化資料抽查三個頁面。
结构化資料的價值在于把信息说清楚，而不是把關鍵詞重复一遍。寫不寫它，頁面都能被收錄；寫對了它，頁面被理解得更准。
如果你還没開始做，可以從文章頁的 Article 入手，把标题、作者、發布時間、修改時間、主图這五項补齐。對多數内容站来说，這一項投入产出比最高，也不需要改動頁面结构。