结构化数据不是给用户看的，是给搜索引擎读的一份说明书。它本身不会让页面直接排上去，但写错、写漏、写重，会让搜索引擎对页面内容的理解出现偏差，甚至在展示层面丢掉本来可以拿到的信息。这类问题通常不会在页面上露出任何破绽，只能靠主动自查发现。
一、标记必须和用户看到的内容对得上
这是最常见也最容易被忽视的一类问题。搜索引擎对待结构化数据的基本逻辑是：标记是补充说明，可见内容才是事实。如果两者冲突，通常以可见内容为准，同时降低对标记的信任。
- 评分与评论数：页面上没有评论，标记里却写了 aggregateRating，属于典型的高风险操作。
- 价格与库存：标记写 99 元，页面显示 129 元，或者标记显示有货、页面其实已经售罄。
- 作者与发布时间：标记里的作者和页面署名不一致，发布时间和页面显示的日期对不上。
- 标题层级：headline 和页面 H1 完全是两句话，描述的不是同一件事。
自查方法很简单：把页面上所有能看见的信息列一遍，再对照 JSON-LD 里的字段逐个核对。凡是标记里有、页面上找不到的内容，都要问一句“这句话用户能看到吗”。
二、输出方式与重复实体
格式上，JSON-LD 是当前兼容性和维护成本都比较均衡的选择，微数据写起来容易和模板耦合，改起来费劲。真正要留意的是下面几种情况：
- 靠 JS 动态注入：有些实现对爬虫不友好，渲染环节拿不到标记，等于白写。能放在服务端输出的，就别拖到前端。
- 同一实体输出多次：列表页循环时，模板把同一个 Organization 或 WebSite 重复打了几十遍，字段还互相矛盾。
- 同一节点上类型冲突：比如一个对象同时声明成 Article 和 Product，两边的必填字段互相打架。
- @id 缺失或重复：跨页面引用同一实体时没有稳定的 @id，搜索引擎只能当成多个不同实体处理。
判断标准可以简化成一句话：一个页面里，同一个实体只应该有一份完整、自洽的描述。
三、按类型过一遍重点字段
文章与内容页
headline、datePublished、dateModified、author、image 是最常被读取的几个字段。dateModified 要跟着正文实际修改走，只改了个错别字不必天天更新；正文做了实质调整，就该同步。
面包屑标记
BreadcrumbList 的层级、名称、顺序，要和页面上可见的面包屑、以及真实的 URL 目录结构保持一致。三者对不上，层级判断就会混乱。
组织与站点信息
Organization 的 logo、name、url、sameAs 建议全站统一输出一次，不要在每篇文章里各自写一份。logo 图片要用可长期访问的稳定地址。
商品、评价、问答类
这类标记涉及展示权益，也最容易被滥用。没有真实评价就不要标评价，没有问答内容就不要标 FAQ。规则收紧时，受影响最大的往往就是这些。
四、验证和维护节奏
- 上线前用官方测试工具跑一遍，重点看有没有报错和警告，以及工具解析出的实体数量和预期是否一致。
- 模板改动、字段改名、CMS 升级后，至少抽查几个典型页面，不要只看首页。
- 把结构化数据的校验加进发布流程，比事后从日志里倒推要省事得多。
- 定期抽样对比标记与实际页面，尤其是价格、库存、评分这类会变动的字段。
结构化数据属于“做对了不加分，做错了会减分”的那类基础工作。它不承诺任何展示结果，但至少能保证搜索引擎拿到的那份说明书，和用户看到的页面是同一件事。