Sitemap 里的 lastmod 经常被当成一个“填了就行”的字段：不少站点每次构建都把全部 URL 的时间刷新成当天，结果是蜘蛛看到整站天天更新，久而久之把这个信号当作噪音处理。这篇想说的是，lastmod 更接近一条线索，而不是一条命令，它的价值取决于它与页面真实变化之间是否一致。
蜘蛛为什么在意更新时间
站点的 URL 总量通常远大于蜘蛛在单位时间内能抓取的数量，所以抓取队列里必然要做取舍：新 URL 要抓，旧 URL 也要重访。当蜘蛛没法从页面本身低成本判断“有没有变”时，就会参考若干外部提示，lastmod 是其中之一。它不会单独决定抓取顺序，但会作为一个维度参与权衡。
这也解释了一个现象：lastmod 写得越随意，它带来的边际收益越小。当大部分 URL 的时间戳频繁变动、而页面内容几乎不变时，这个字段就失去了区分度。
几种常见的写法问题
- 全量刷新：构建脚本把 sitemap 中所有条目的 lastmod 统一改成构建时间，与页面内容是否变化无关。
- 格式不一致：有的条目带时区，有的不带；有的精确到秒，有的只到日期。格式混乱会让解析结果不可靠。
- 时间来自模板：列表页、聚合页的 lastmod 跟着模板走，正文没有任何改动也跟着变。
- 只在新发时写一次：正文做过实质性修订，价格或库存也变了，时间却停留在首次发布那天。
哪些变化值得改 lastmod
判断标准可以简单一点：这个改动对访问者看到的内容有没有影响。
- 正文的新增、删减、纠错，属于值得更新的改动。
- 结构化数据里价格、库存、状态的变动，通常是高频且真实的更新。
- 页面主要模块的位置调整、信息合并，也可以更新。
- 纯粹的样式微调、缓存刷新、页脚年份改动，一般没必要动 lastmod。
如果拿不准，就问自己一句：一个上周来过这个页面的用户，今天再来会不会看到实质不同？答案是否，就不要改时间。
lastmod 之外的配套信号
单一字段容易被忽略，配合其他信号会更稳。
- Last-Modified 响应头：与 sitemap 中的时间大致对齐，两者能相互印证。
- 内链位置变化：把更新过的页面挪到首页或栏目页更靠前的位置，蜘蛛重访这些高频页面时更容易再次碰到它。
- Sitemap 分片：只重写发生变化的那个分片和对应索引文件，降低蜘蛛的对比成本。
- 内容指纹：记录正文哈希，只有哈希变化时才更新 lastmod，减少人工遗漏。
一次简单的自查
不需要复杂工具，做一次抽样对比就能看出问题：从服务器日志里挑几十个 URL，把每个 URL 最近一次被抓取的时间，和它在 sitemap 里的 lastmod 放在一起看。如果大量 URL 的 lastmod 长期等于构建时间，而页面内容并无变化，说明这个字段正在被滥用；如果明明修订过的页面 lastmod 还停在首次发布，说明更新链路存在漏点。
把更新当成流程，而不是字段
真正影响重访效率的，往往不是 lastmod 的写法本身，而是站点有没有一条“内容更新—时间戳更新—内链位置更新”的完整链路。字段只是这条链路的末端输出。把它当成一个需要维护的流程，比把它当成一个必须填满的字段，更接近问题的本质。