Sitemap 里的 lastmod 字段常被当成“顺手填一下”的字段，但它是爬虫判断某个 URL 是否值得重新抓取的参考之一。当 lastmod 与页面真实更新时间不一致时，抓取调度容易出现两类偏差：该重抓的页面迟迟不抓，或者不该重抓的页面被反复抓取，挤压抓取预算。

lastmod 在抓取调度中扮演什么角色

爬虫发现 URL 后，会综合入口来源、内链位置、历史更新频率、lastmod 等因素决定抓取顺序。lastmod 不是唯一依据，但成本很低，是一个容易被读取的提示信号：

• lastmod 明显新于上次抓取时间，倾向于尽快重抓；
• lastmod 长期不变，倾向于降低重抓频率；
• lastmod 与响应头 Last-Modified 冲突时，通常以实际内容变化和响应头为准。

所以 lastmod 失真的直接后果不是“被惩罚”，而是调度信号与实际内容变化脱节。

常见的 lastmod 失真来源

1. 全站统一时间戳

构建脚本把 lastmod 写成打包或部署时间，每次发布全站所有 URL 都被标记为“刚刚更新”。爬虫看到大量“新”URL，抓取队列被低价值页面占满。

2. 时区与格式不统一

建议使用带时区的完整格式，例如 2024-05-01T08:30:00+08:00。只写日期、写本地时间不加时区，或多种格式混用，都可能造成解析偏差，甚至让校验环节直接忽略该值。

3. 内容已更新但 lastmod 未同步

正文、价格、库存由接口动态渲染，而 Sitemap 由静态构建生成，lastmod 停留在构建时间。搜索蜘蛛抓到的是旧版本，更新信号传不出去。

4. 人为“刷新”lastmod

为了显得更新而批量改时间戳，会让抓取频率和真实变化量长期不匹配，日志上表现为同一批 URL 反复被访问但内容没变。

核对清单

1. 抽样 20 到 50 个 URL，对比 Sitemap lastmod、响应头 Last-Modified、页面中可见的更新时间三者是否一致。
2. 检查格式是否为带时区的完整时间，是否存在只有日期或时区缺失的情况。
3. 确认 lastmod 取自内容库的真实更新时间字段，而不是构建或部署时间。
4. 观察抓取日志中这批 URL 的重抓间隔，是否与内容更新频率相符。
5. 确认 lastmod 只出现在确实会频繁更新的 URL 上，长期不变的页面宁可省略该字段，也不要写死一个旧时间。

lastmod 是提示，不是承诺。它的价值在于“少而准”，不在于“全而新”。

修复与观察顺序

建议从生成逻辑入手，而不是手工维护：先让内容更新时间落库，再由构建流程读取输出；分页、筛选参数页等低价值 URL 尽量不写 lastmod；对高频更新的栏目设置合理的更新粒度。

调整后不要立刻下结论，抓取调度的反馈通常需要一到数周。可以关注三个指标：同一目录下的平均重抓间隔、抓取日志中 200 与 304 的比例变化、新发布页面的首次被抓取时间。如果重抓间隔没有变化，先排查 Sitemap 是否被正确读取，再考虑其他因素。

最后提醒：Sitemap 只是 URL 发现的入口之一，内链结构和服务器稳定性对抓取的影响往往更直接。把 lastmod 调准是把信号调准，并不能替代其他基础工作。