Sitemap 里的 lastmod 字段经常被当成一个开关：更新它，蜘蛛就该来重抓。实际运行时它更像一条线索，蜘蛛会把它和自己观察到的情况对照，再决定这个 URL 是否值得占用一次抓取配额。
蜘蛛判断“要不要再抓”时会看什么
对已经抓取过的 URL，蜘蛛通常不会只依赖一个字段，而是把多方面的信号放在一起权衡：
- 历史变化频率：这个 URL 过去改动是否频繁，改完之后内容是否真的不同；
- 上次抓到的内容：和这次能拿到的版本比对，确认有没有实质变化；
- 站点层面的信号：内链、导航结构是否仍指向它，页面是否还在有效路径上；
- Sitemap 声明：lastmod 是否被频繁重置，是否与页面真实更新时间一致；
- HTTP 缓存头：Last-Modified、ETag 能否支撑一次条件请求；
- 服务器表现：响应时间、错误率、是否经常超时。
这些信号里，Sitemap 属于“发现层”，HTTP 头属于“验证层”。两层都做对，重抓请求才更容易落在真正变化的页面上。
lastmod 被忽略的常见原因
lastmod 不是填上就有效，下面几种情况会让它逐渐失去参考价值：
- 每次部署都刷新全站时间，蜘蛛看到大量 URL 同时“刚刚更新”，但内容并没有变；
- 时间格式不规范，缺少时区或使用本地化写法，解析后得不到可用信息；
- 把 lastmod 写成未来时间，或者与页面上的更新时间互相矛盾；
- Sitemap 中列了大量不重要的 URL，把真正需要重抓的页面稀释掉。
让重抓更有可预期性的做法
这里说的“可预期”不是让蜘蛛按你的时间表来，而是减少它判断时的噪音。
Sitemap 侧
- 只在内容确实改变时更新 lastmod，格式使用带时区的 ISO 8601；
- 把更新频繁的栏目或资讯类页面单独分片，不要和长期不变的说明页混在一起；
- 定期清理已经 404、301 到别处或已下线的 URL。
页面与服务器侧
- 让 Last-Modified 反映真实的内容变更，而不是每次渲染都变；
- 稳定输出 ETag，使条件请求能返回 304，避免重复传完整页面；
- 保证抓取高峰时服务器不出现大量 5xx，错误率升高会让整体抓取节奏放缓；
- 用内链把重要页面放在网站结构里，而不是只靠 Sitemap 推送。
观察与验证
改完之后不要只看一次日志。可以关注：同一批 URL 的重抓间隔是否趋于稳定；抓取失败的 URL 是否集中在某类模板；返回 304 的比例是否上升。这些指标比只盯着 Sitemap 更接近真实情况。
lastmod 是给蜘蛛的一条线索，不是抓取承诺。它起作用的前提是：页面的真实变化和它声明的是同一件事。
把 Sitemap 当成一份“当前有效 URL 与更新情况”的清单，而不是一份想让蜘蛛按排期访问的时间表，再配合稳定的服务器和清晰的内链结构，URL 的重新抓取才会慢慢形成可预期的节奏。