Sitemap 里的 lastmod 是很多站长最熟悉、也最容易随手写错的一个字段。它本来只是告诉蜘蛛“这个 URL 大概什么时候更新过”，但因为它会参与蜘蛛判断“要不要来、什么时候来、来了之后值不值得再抓一次”，写错了，浪费的往往是本来就不宽裕的抓取安排。
lastmod 通常会影响什么
它不是排名因素，也不保证蜘蛛会按你写的日期上门。它的作用更像一份日程提示：在抓取资源有限的情况下，蜘蛛会参考历史抓取记录、页面变更情况和 lastmod 这类信号，去安排哪些 URL 值得优先重访。信号可靠，调度就可能更贴近你的更新节奏；信号混乱，调度就可能要么浪费在没变的页面上，要么迟迟不来。
它和条件请求是配套的
蜘蛛重访时如果带上 If-Modified-Since 一类的条件请求，服务器可以返回 304，省下一次传输。前提是服务器确实知道文件的最后修改时间。如果 Sitemap 写的是 A 时间、HTTP 头里给的是 B 时间，两边对不上，蜘蛛接收到的信号就是矛盾的。
三种常见的写错方式
- 全站一个时间戳。几千个 URL 全部同一个 lastmod，等于在说“它们同时更新”。真实情况显然不是，久而久之这个字段就失去了参考价值。
- 每次生成都刷成当前时间。程序每次跑 Sitemap 都写入 now()，页面内容其实没动。蜘蛛连续几次来都发现页面没变，只会逐渐降低对这个字段的信任。
- 时区与格式混乱。有的写 2024/5/6，有的写 6 May 2024，有的用本地时间又不带偏移量，跨时区时可能凭空多出或少掉一天，比较难以对齐。
写错之后的连锁反应
最直接的影响是重访节奏被打乱。页面明明改了，蜘蛛按旧信号判断“最近没动”，来的次数就少；页面没改却天天被标记为更新，蜘蛛反复白跑，占掉的正是本该分给新页面和其他重要页面的抓取额度。
更隐蔽的问题出在内链与抓取路径上。如果新上线的栏目页 lastmod 长期停在过去，蜘蛛顺着内链走到这里，可能只做一次浅抓取；而如果 Sitemap 里的时间与页面实际内容长期不一致，蜘蛛在多个来源之间来回校验，也会带来不必要的请求。
把 lastmod 当成“内容真正发生变化的时间”，而不是“文件被写到磁盘的时间”，通常更接近它的用途。
怎么核对和修正
- 抽查一批 URL，用 curl -I 看响应头里的 Last-Modified，与 Sitemap 里写的时间做对比，看是否在合理范围内一致。
- 确认生成逻辑取的是内容库的更新时间字段，而不是每次构建的时间戳。
- 统一使用带时区的 ISO 8601 格式，例如 2024-05-06T09:30:00+08:00，减少解析歧义。
- 分片 Sitemap 时，让每个分片的 lastmod 反映该分片内最新的真实更新时间，不要统一覆盖。
- 改版、批量迁移之后，全站内容确实变了，这时写当前时间是合理的；迁移完成、内容稳定之后，就该回到真实更新时间。
和服务器稳定性一起看
lastmod 只是调度参考，能不能按这个节奏抓下来，还要看服务器是否稳定。响应时间波动大、偶尔出现 5xx，蜘蛛即使按计划来了，也可能中途降低频率。所以把 Sitemap、内链结构、服务器响应这几件事放在一起排查，通常比单独盯着某一个字段更有效。
简单说：lastmod 写对不会让你多收录什么，但写错确实可能让本该被及时看到的内容，多等上一阵。