sitemap全站日期每天刷新，lastmod到底取错了哪个时间

凌晨的站点地图任务跑完后，几百个URL的lastmod又整齐地变成了当天日期。产品参数没动，文章没改，连长期不维护的旧页面也显示刚刚更新。真正新增的资料也混在同一批时间里，搜索系统很难从这份文件判断哪些页面值得重新抓取。

排查时不要先改XML格式。要追的是日期在生成链路里从哪来：内容表的更新时间、静态文件mtime、模板部署时间，还是任务执行时直接取了当前日期。把这几种时间混成一个字段，站点地图每次重建都会制造一次全站更新。

先分清页面更新、构建和抓取时间

内容发布日期说明页面何时出现；内容更新时间记录标题、正文、参数或主图等主体信息何时发生实质变化。模板部署时间属于程序版本，文件mtime只说明服务器何时写过文件，搜索抓取时间则来自日志或平台记录。四者可以接近，却不能默认相等。

最直接的证据来自同一URL的三处对照：数据库记录、页面上公开的更新时间、sitemap中的lastmod。若数据库保留旧日期，XML却是今天，问题在生成程序；若数据库也被统一改写，要继续查看后台保存动作、定时任务或触发器。几百条记录出现在同一秒，通常比页面本身更能说明问题。

静态站还要查看构建方式。全量构建会重写HTML文件，mtime随之变化，正文却可能一个字没动。可以改用内容元数据，或在构建前比较主体内容哈希，只在页面信息确实变化时写入新版本时间。导航、公共样式的小改动是否算页面更新，应按影响范围决定，不能把一次部署扩成全站内容变化。

跨一天做四组样本

准备四个URL：完全未改的旧页、只清过缓存的页面、修改了核心参数的页面、已经删除或重定向的页面。重建站点地图后，旧页和缓存页保持原日期，参数页出现本次修改时间，失效地址从URL集合中移除。第二天不改内容再跑一次，前三个保留原值，才算切断了“每天自动变新”的来源。

验收还要看时区。数据库保存本地时间、生成任务使用UTC时，午夜附近可能提前或延后一天。站点只使用日期精度时，应统一按发布服务器的业务时区截取；使用完整时间时，带上明确的时区偏移。不要用手工加减一天来掩盖配置差异。

Sitemaps协议把lastmod定义为文件的最近修改时间。对CMS站点来说，更有用的实现是把它落到可回查的内容版本，而非抓取时间或任务时间。搜索平台是否立刻重抓由平台决定，制造一个新日期并不能替代真实更新。

恢复自动提交前，保存一次数据库字段、旧XML和新XML的差异。今后改模板、迁移静态构建器或调整缓存组件，再用这四组样本跑一遍。只要未改页面的日期出现联动，就先暂停提交，回到时间来源排查。