Sitemap 里的 lastmod 常被当作「告诉搜索引擎这个页面更新了」的开关，但很多站点并没有认真维护它。一旦时间戳与实际内容更新的关系被破坏，抓取调度拿到的就是噪声，而不是信号。结果是频繁被抓取的页面其实没变，真正更新的长尾页面却迟迟等不到访问。下面从 lastmod 的生成、校验和协同三个环节，讲一套可以落地的维护方式。
为什么 lastmod 会影响抓取优先级
搜索引擎在决定「下一次抓哪个 URL」时，会把多个信号叠加起来：内链权重、历史抓取质量、页面变更频率、Sitemap 声明的时间戳等。其中 lastmod 是站点唯一能直接、批量表达「这个 URL 变了」的手段。它不保证一定被采信，但如果大量页面的 lastmod 同时刷新、抓取后内容并无变化，这个字段的可信度会被整体打折，之后即便某篇文章真的更新，也很难被优先安排回访。
lastmod 失真的常见来源
- 模板级时间戳：页脚或侧栏输出了当前时间，导致每次渲染出来的 lastmod 都等于「现在」。
- 批量重建：整站重新生成静态页或重建缓存，所有 URL 的修改时间被统一改写。
- 依赖文件系统时间：部署、复制、迁移都会改变 mtime，与正文实际改动无关。
- 时区与格式混用：同一份 Sitemap 中同时出现带时区和不带时区的时间，解析结果不一致。
- 预览与草稿外泄：未发布内容先进入 Sitemap，正式发布时时间戳反而不变。
修正顺序
- 确定唯一来源：lastmod 只取正文内容的最后编辑时间，与发布时间、模板渲染时间区分开，写入数据库字段而不是运行时计算。
- 统一格式：全部使用带时区的 ISO 8601 格式，例如 2024-06-01T09:30:00+08:00，避免只写日期带来的歧义。
- 只在内容实质变化时更新：修正错别字、补充段落可以更新；调整导航、广告位不应触发全站时间戳变化。
- 分批提交：一次性把全站 lastmod 刷成同一时刻，等于放弃这个信号。按实际改动分组，让时间戳自然分散。
- 回查抓取日志：观察高频抓取的 URL 与 lastmod 靠前的 URL 是否重合，若明显错位，说明仍有模板时间在干扰。
与其他抓取信号的配合
lastmod 不是孤立的，它需要和 Sitemap 的 URL 集合、页面内链入口、服务器响应质量保持一致：
- Sitemap 中的 URL 应当是可稳定返回 200 的地址，不要混入重定向链或多变体路径。
- 更新后的页面最好能从栏目页、相关推荐等位置获得一条内链，纯靠 Sitemap 表达的更新信号更容易被忽略。
- 服务器在抓取高峰出现超时或 5xx，会让调度降低对该站点的抓取配额，此时再精准的 lastmod 也难换来额外访问。
把 lastmod 当作「内容变更的日志」，而不是「想被多抓一次的借口」，这个字段才有长期价值。
验证方式
建立一个简单的对照表：记录 URL、lastmod、实际内容修改日期、最近一次抓取时间。每隔一段时间抽查一批，重点关注三类页面——高频更新但抓取稀疏的、lastmod 长期不动但内容已改的、时间戳密集却没有任何实质变化的。这三类问题分别指向内链不足、字段未维护和批量刷新，处理方式并不相同。
维护 lastmod 的成本不高，难的是让它长期保持诚实。当字段与实际内容变更贴近时，抓取调度才有依据判断哪些 URL 值得优先回访，站点也更容易把有限的抓取配额用在真正更新的页面上。