Sitemap 是站点主动交出去的 URL 清单，但清单里的每个地址都带着一个时间戳。很多站点把 lastmod 当成“填上就行”的字段，结果蜘蛛看到的时间和页面真实的改动时间对不上。一两次没有影响，长期不一致之后，这个字段就很难再被当作参考。
蜘蛛为什么在意这个时间戳
蜘蛛的抓取资源有限，它需要在“已知但可能过期的页面”和“从未见过的页面”之间决定先去哪里。页面的改动时间，是判断“值不值得再来一次”的输入之一。Sitemap 里的 lastmod 由站点自己声明，属于比较明确的信号——前提是它可信。
需要说清楚的是，lastmod 只是众多输入中的一个。它不会单独决定抓取顺序，也不会因为写对了就保证页面被重新抓取。它的价值在于：当其他条件差不多时，一个准确的时间戳能让判断更有依据。
格式先写对
- 使用 W3C Datetime 格式，例如 2025-03-08T09:12:30+08:00。
- 带上时区偏移。只写到 YYYY-MM-DD 也是合法格式，但精度只到天。
- 同一个 Sitemap 文件内保持一致，不要一部分带时区、一部分不带。
- 不要写相对时间，也不要用“三天前”这类描述。
三种常见的错误写法
全站统一成今天
有些程序会在每次生成 Sitemap 时，把所有 URL 的 lastmod 都刷成当前时间。蜘蛛第一次看到，会以为整站都更新了；第二次、第三次还是同样的结果，这个字段就失去意义了。一个持续变化的 lastmod，和一个没有 lastmod，差别并不大。
用构建时间代替内容时间
静态站点常见的问题：每次部署都重新生成所有页面文件，文件时间变了，lastmod 也跟着变，但页面内容可能一年没动过。正确做法是记录内容的最近一次实质性修改，而不是记录文件系统的时间。
时间戳无法解析
写成“2025/03/08”、中文日期，或者干脆留空，解析失败的条目往往会被整条忽略，连同这条 URL 的其他信息一起打折。生成之后最好抽查几条，确认格式能被标准解析器读懂。
让时间戳和真实改动对齐
判断什么叫“实质性修改”，可以给几条简单的线：正文内容、标题、主要结构化数据的调整，可以更新时间；评论排序变化、广告位轮换、推荐位调整，一般不算；样式微调、模板改动引起的全站“更新”，更不应该体现在 lastmod 上。
如果内容存在数据库里，取最后修改时间字段即可。如果内容来自发布流程，可以让编辑在保存时决定是否打上新的时间戳。关键点是：只有人或者明确的规则认为内容变了，时间才变。
和其他信号配合起来
- lastmod 准确，配合页面的 304 与 ETag 响应，蜘蛛可以用很小的成本确认有没有变化。
- Sitemap 分片时，索引文件里的 lastmod 应取该分片内页面的最大值，而不是生成时间。
- 内链和 Sitemap 指向同一个 URL 时，时间戳也应对应同一个页面版本，不要互相矛盾。
- 页面已经删除的，不适合靠改 lastmod 去“唤醒”，应当从 Sitemap 移除并返回正确的状态码。
一份可执行的自查清单
- 随机抽 20 条 URL，把 Sitemap 里的 lastmod 和页面实际修改时间逐条对比。
- 检查是否存在全站 lastmod 等于生成时间的批量模式。
- 确认时间格式统一，并且带有时区。
- 检查有没有未来时间。
- 检查分片 Sitemap 索引中的 lastmod 是否取的是分片内的最大值。
- 后台里如果有多处记录修改时间，确认 Sitemap 取的是同一个字段。
把 lastmod 写准，不会让蜘蛛立刻来抓；把它写乱，长期下来只会让这个字段变得可有可无。
站点对 URL 清单的维护方式，反映的是它对自身内容更新的掌控程度。时间戳只是其中一个细节，却很容易被自动化流程写坏，也很容易被忽略。定期抽查一次，比每次全量刷新更省事。