Sitemap 里除了 URL 本身，还有一组可选字段，其中 lastmod 是最容易被随手填写、也最容易被忽略的一个。它的作用是告诉搜索引擎这个页面最后一次发生实质性变更的时间。蜘蛛并不会因为一个新鲜的 lastmod 就立刻来抓，但一个稳定、可信的 lastmod 会帮助它判断哪些 URL 值得优先安排、哪些可以往后放。
简单说，lastmod 是建议，不是命令。它影响的是调度时的参考权重，而不是抓取与否的开关。
格式：不是随便写个日期就行
主流搜索引擎认可的写法是 W3C Datetime 格式，可以完整到秒，也可以只到日期。带时区的时间戳比不带时区更明确。
- 2024-05-21 这种只到日期的写法可用，但含义是该日 00:00
- 2024-05-21T09:30:00+08:00 这种带时区的写法最清晰
- 20240521 这类紧凑格式在部分实现里能被解析，但兼容性不如标准写法
- 只写时间不写日期，或使用“今天”“昨天”等相对描述，会直接失效
三类常见的填写问题
每次生成 Sitemap 都把全站刷成当下时间
这是最常见的一种。程序每次输出 Sitemap 时统一用当前时间填充 lastmod，结果是全站几万个 URL 的最后修改时间每天都一样新。蜘蛛多次对比后发现这个字段没有区分度，就会降低对它的信任，之后即使某个页面真的更新了，也很难通过 lastmod 传达出去。
用当天日期批量覆盖
与上一条思路类似，只是时间粒度不同。常见的触发场景是运营在后台点了“全站重建”，脚本顺手把所有条目的时间改成了今天。对蜘蛛来说，这等于告诉它整个站点每天全部重写了一遍。
时区与格式混用
一部分条目带时区、一部分不带，或者不同栏目由不同系统生成导致格式不统一。解析时可能出现偏移，让页面看起来的修改时间比实际更早或更晚，反而干扰判断。
lastmod 与服务端响应头的关系
Sitemap 里的 lastmod 和服务器返回的 Last-Modified 是两套信息，来源不同，用途也不同。
- lastmod 由站点在 Sitemap 中主动声明
- Last-Modified 由服务器在响应中被动给出
- ETag 更多用于缓存校验，配合 If-None-Match 判断内容是否变化
三者如果互相矛盾，比如 Sitemap 说今天更新、Last-Modified 却是半年前，蜘蛛会更倾向相信服务端实际返回的内容与校验信息。所以更稳妥的做法是让 Sitemap 的 lastmod 由内容系统的真实更新时间生成，而不是人工或模板拼出来。
一套可落地的自查方式
- 抽 10 个近期确实更新过的 URL，看它们的 lastmod 是否集中在更新当天，而不是全站同一个值。
- 检查格式是否统一、是否带时区，是否都是标准日期写法。
- 对比同一个 URL 的 lastmod 与响应头 Last-Modified，看两者是否大致吻合。
- 检查栏目页、标签页这类聚合页面，确认它们的 lastmod 会随内容变化而更新，而不是长期不动。
- 发布新内容后隔几天再拉一次 Sitemap，看新 URL 是否带着合理的时间出现。
一个现实提醒
lastmod 不会让页面凭空被收录，也不会让蜘蛛跳过正常的抓取路径。它只是一条帮助调度判断的辅助信息，写对了有用，写错了也不会立刻出问题，但长期失真会让这条信息失去价值。
把 lastmod 做对，成本不高，主要靠内容系统里那个真实的“更新时间”字段。真正麻烦的是站点结构复杂、多套系统拼装的场景，这时宁可少写、写准，也不要为了填满字段而全站刷同一个时间。