文章更新后，dateModified 应记录哪次修改

内容人员下午改了产品适用范围，页面正文已经是新版本，源码里的 dateModified 却还等于首次发布日期。开发清了一次缓存，它又变成清缓存的时间。两个结果都不可靠：前者漏掉真实更新，后者把程序动作当成内容变化。

datePublished 记录页面首次公开的时间，后续不随编辑动作变化。dateModified 应指向最近一次已经审核、会影响读者判断的内容修改。网站要先定义“实质更新”，再决定从哪个字段输出时间。

先把编辑时间和实质更新时间分开

CMS 常见的 update_time 只说明数据库记录被写过。运营改了标题，程序重建标签，后台统计浏览量，甚至保存时没有改正文，都可能刷新这个字段。模板直接读取它，dateModified 就会在没有新信息时反复变化。

内容表可以保留普通编辑时间，另建审核记录。记录至少包含内容主 ID、版本号、变更类型、提交人、审核人、审核状态、批准时间和正文哈希。模板只读取最近一条“已批准且属于实质更新”的 approved_at，草稿保存和驳回记录不进入公开页面。

实质更新需要影响页面回答。产品适用型号发生变化，或者检测标准换版，都应生成新版本。只改错别字、空格、图片压缩率或后台备注，可以留下维护记录，不必改公开时间。替换图片时要看图片承担的任务：新图展示了不同结构或参数，属于内容变化；同一张图只减小文件体积，不属于。

JSON-LD 里的标题、作者、日期和正文要来自同一条内容记录。站内已有的结构化数据与页面事实核对方法可以作为字段清单，但日期还要多查一层审核状态。编辑器显示“已保存”，不能替代发布负责人确认。

页面、sitemap 和响应头共用审核时间

审核通过后，系统把批准时间写入业务修改字段，并保留时区。JSON-LD 输出 ISO 8601 格式，例如带有 +08:00 的完整时间；页面可见日期可以只显示到日，但两者必须指向同一次批准。模板找不到批准记录时，旧文章沿用首次发布日期，不要用当前时间补空值。

sitemap 的 lastmod 也应读取这项业务修改时间。重建 sitemap 只是生成文件，不代表所有页面当天发生变化。相关检查可结合sitemap 更新时间与真实更新的对应规则进行，尤其要抽查没有编辑过的旧页面，确认它们的日期没有跟着批量刷新。

服务器若发送 Last-Modified 响应头，也应采用相同依据。CDN 或页面缓存可以改变文件落盘时间，却不能改业务修改时间。使用 ETag 时，正文版本发布后要让标识随内容变化；只清缓存不改正文，重新请求仍应得到同一版本判断。

PbootCMS 项目里常同时存在 date、create_time 和 update_time。维护人员要查清后台保存动作分别改动哪些字段，再决定是否增加审核时间，不能看字段名像“更新时间”就直接套进模板。历史内容没有审核记录时，可从版本备份、发布日志和 sitemap 旧文件中核对，无法确认就保留原发布日期。

新字段上线时不要把迁移日期批量写进全部旧文章。可以先筛出正文哈希与备份不同、同时能找到发布日志的记录，由内容负责人逐条确认；其余页面把审核时间留空。模板按“审核时间优先，发布日期兜底”取值，旧库存不会因为一次数据库迁移突然显示为当天更新。

验收时先记录页面源码、sitemap 和响应头中的现有时间。修改一个错别字并保存，公开时间应保持不变；再补充会影响适用范围的条件，审核通过后重新请求，三处时间才一起更新。还要检查 canonical 页面与缓存副本是否一致，避免同一正文对外出现两组修改时间。

评论、浏览量和销售跟进记录不属于文章内容，不应触发公开更新时间。每次发布后只核对本次批准版本对应的正文哈希与时间字段；两者对不上，就暂停 sitemap 更新，先查审核记录和模板取值。