文章的结构化数据日期，可以与正文显示的日期不同吗？

让每个日期对应一个编辑事件

把 `datePublished` 理解为文章第一次发布的日期，把 `dateModified` 理解为一次有意义修订的日期。例如，替换过时操作、纠正重要错误、扩充决策说明，或改变页面要回答的核心问题，都可能属于实质修订。页面可见日期文字应当用普通语言表达同一组事件。

外观上的小修改不一定需要新的更新日期。修正标点、调整间距或更换内部链接当然可能属于维护工作，但除非团队的书面规则把这类修改定义为实质编辑，否则不应把它呈现为全新的版本。目标是保持可追溯性，而不是让旧指南看起来更新。

诊断日期不一致

假设页面可见日期是九月，而部署后 JSON-LD 变成了十月。先确认十月是否代表真实修订，还是构建流程自动填入的默认值。然后比较已渲染页面、源数据、生成后的 JSON-LD 以及部署差异。不要先猜哪一个日期更应该保留，也不要只改页面标签来掩盖问题。

采用以下检查顺序：1. 确认每个日期代表首次发布还是实质修订；2. 检查内容记录和修订日志；3. 对比可见日期、`datePublished` 与 `dateModified`；4. 检查部署后的最终页面；5. 如果任一日期的来源不明，就暂停发布。修正源记录后重新生成页面，再检查最终输出。

1. 确认每个日期代表首次发布还是实质修订。
2. 对比内容记录、修订历史、可见日期和 JSON-LD。
3. 移除没有编辑事件依据的部署默认日期。
4. 重新生成并检查部署后的页面。
5. 日期无法追溯到记录中的编辑事件时，暂停发布。

记录修订，不人为制造新鲜度

发生真实修订时，记录改了什么、为什么改、谁批准，以及应当显示哪个日期。简短的修订说明比悄悄移动时间戳更有用。如果文章实质内容没有变化，即使相关指南刚刚发布，也应保留原始发布日期，不要仅因为站内出现新文章就添加新的更新日期。

这是工作流程建议，并不表示结构化数据一定会带来某种搜索展示。语法有效不能让错误日期变得可接受，验证工具通过也不能证明搜索引擎一定会收录或展示每个字段。应先让页面、结构化数据和内部记录保持一致，再考虑外部结果。

虚拟演练与上线复核

虚拟演练：某指南于 9 月 14 日首次发布，12 月部署时只修改了一个例子，没有改变操作说明或结论。团队应保留 `datePublished` 为 9 月 14 日。除非按照编辑规则，这个例子变化属于实质修订，否则不应悄悄把 `dateModified` 改成 12 月。如果后续修订替换了决策步骤，并且可见修订历史同步更新，12 月才可以作为有记录依据的修改日期。

上线复核人员应比较最终 HTML 与 JSON-LD，并把修订说明保存在部署记录中。如果页面写着九月而 JSON-LD 写着十月，却找不到相应修订，结果应判定为不通过。停止条件很明确：任一日期没有可追溯的编辑事件，就不要发布。

日期一致性复核