结构化資料不是给用戶看的，是给搜尋引擎讀的一份說明书。它本身不會让頁面直接排上去，但寫错、寫漏、寫重，會让搜尋引擎對頁面内容的理解出現偏差，甚至在展示层面丢掉本来可以拿到的信息。這類問题通常不會在頁面上露出任何破绽，只能靠主動自查發現。

一、标记必须和用戶看到的内容對得上

這是最常见也最容易被忽视的一類問题。搜尋引擎對待结构化資料的基本逻辑是：标记是补充說明，可见内容才是事實。如果两者冲突，通常以可见内容為准，同时降低對标记的信任。

• 评分與评论數：頁面上没有评论，标记里却寫了 aggregateRating，属于典型的高風險操作。
• 價格與库存：标记寫 99 元，頁面顯示 129 元，或者标记顯示有货、頁面其實已经售罄。
• 作者與發布時間：标记里的作者和頁面署名不一致，發布時間和頁面顯示的日期對不上。
• 标题层級：headline 和頁面 H1 完全是两句话，描述的不是同一件事。

自查方法很简單：把頁面上所有能看见的信息列一遍，再對照 JSON-LD 里的字段逐個核對。凡是标记里有、頁面上找不到的内容，都要問一句“這句话用戶能看到吗”。

二、輸出方式與重复實体

格式上，JSON-LD 是目前兼容性和维護成本都比較均衡的選擇，微資料寫起来容易和模板耦合，改起来費劲。真正要留意的是下面几種情况：

1. 靠 JS 動態注入：有些實現對爬虫不友好，渲染环节拿不到标记，等于白寫。能放在服務端輸出的，就別拖到前端。
2. 同一實体輸出多次：列表頁循环时，模板把同一個 Organization 或 WebSite 重复打了几十遍，字段還互相矛盾。
3. 同一节点上類型冲突：比如一個對象同时声明成 Article 和 Product，两邊的必填字段互相打架。
4. @id 缺失或重复：跨頁面引用同一實体时没有稳定的 @id，搜尋引擎只能当成多個不同實体處理。

判断标准可以简化成一句话：一個頁面里，同一個實体只應该有一份完整、自洽的描述。

三、按類型過一遍重点字段

文章與内容頁

headline、datePublished、dateModified、author、image 是最常被讀取的几個字段。dateModified 要跟着正文實际修改走，只改了個错別字不必天天更新；正文做了實质調整，就该同步。

面包屑标记

BreadcrumbList 的层級、名稱、顺序，要和頁面上可见的面包屑、以及真實的 URL 目錄结构保持一致。三者對不上，层級判断就會混乱。

组织與站点信息

Organization 的 logo、name、url、sameAs 建议全站统一輸出一次，不要在每篇文章里各自寫一份。logo 图片要用可長期訪問的稳定地址。

商品、评價、問答類

這類标记涉及展示權益，也最容易被滥用。没有真實评價就不要标评價，没有問答内容就不要标 FAQ。規則收紧时，受影响最大的往往就是這些。

四、驗證和维護节奏

• 上线前用官方測試工具跑一遍，重点看有没有报错和警告，以及工具解析出的實体數量和预期是否一致。
• 模板改動、字段改名、CMS 升級後，至少抽查几個典型頁面，不要只看首頁。
• 把结构化資料的校驗加進發布流程，比事後從日誌里倒推要省事得多。
• 定期抽样對比标记與實际頁面，尤其是價格、库存、评分這類會變動的字段。

结构化資料属于“做對了不加分，做错了會减分”的那類基础工作。它不承诺任何展示结果，但至少能保證搜尋引擎拿到的那份說明书，和用戶看到的頁面是同一件事。