Sitemap 里的 lastmod 是最容易被随手填、也最容易被蜘蛛忽略的一个字段。它不决定页面能不能被抓，但会影响蜘蛛下次来的时候，愿不愿意为这个 URL 再花一次抓取预算。
lastmod 在抓取流程里起什么作用
Sitemap 主要用来申报“有哪些 URL”，lastmod 是对“这个 URL 什么时候变过”的补充说明。蜘蛛解析 Sitemap 时，会把新出现的 URL 放进待抓队列；对于已经见过的 URL，则会结合 lastmod、页面返回的 Last-Modified 与 ETag、以及上一次抓取的时间，来判断是否值得回访。
关键在于：lastmod 是一个参考信号，不是指令。填了新时间不等于蜘蛛立刻来，填了旧时间也不等于蜘蛛永远不来。但如果这个字段长期和实际情况对不上，它作为参考的价值就会下降。
几种常见的填错方式
- 全站同一个时间戳。生成 Sitemap 时统一写当前时间，几万个 URL 的 lastmod 完全一致，蜘蛛无法从中分辨哪些内容真的变了，这个字段基本失效。
- 每次生成都刷新。哪怕页面没动，只要构建脚本重跑，时间就更新一遍。时间一长，蜘蛛会认为这个站点的 lastmod 不可信。
- 格式不规范。W3C Datetime 格式通常需要带时区，例如 2024-05-20T09:30:00+08:00。只写日期、写成纯数字时间戳、时区缺失，都可能被解析器丢弃。
- 填了未来时间。服务器时间设置错误或时区算反，会出现比当前时间还晚的 lastmod，这种值一般会被直接忽略。
- 列表页和详情页填反了。列表页其实每天在换内容，却从不更新；详情页长期没动，却天天刷新。两类页面的信号正好相反。
比较稳妥的填写习惯
第一，lastmod 尽量来自内容本身。数据库的更新字段、CMS 的发布时间、版本控制里的提交时间，都比脚本运行时间靠谱。
第二，只在正文、结构化数据或主要内链发生实质变化时更新。改个错别字、挪个广告位，未必值得动这个时间。
第三，列表页和聚合页按真实节奏填。如果它每天确实换一批条目，那就跟着更新；如果只是随机排序，就不要伪装成更新。
第四，和 HTTP 头保持一致。页面返回的 Last-Modified 与 Sitemap 里的 lastmod 相差太远，会让人怀疑这份数据的准确性，两边用同一个来源最省事。
lastmod 不是孤立的入口
把精力全押在 Sitemap 上并不划算。蜘蛛发现 URL 的主路径仍然是站内链接：导航、列表页、相关推荐、面包屑。Sitemap 更接近补漏，负责把内链不容易走到的深层地址交出去。
所以一个页面更新后，除了刷新 lastmod，更实际的做法是让它从几个稳定入口被链到——首页的推荐位、对应分类的第一页，或者一条站内快讯。链接路径通了，比时间戳写得多精确都管用。
用日志验证有没有起作用
判断 lastmod 是否被参考，最终还是要回到抓取日志：
- 看 Sitemap 本身被访问的频率，以及蜘蛛是否稳定地重新下载它。
- 看被标记为更新的 URL，在之后一段时间里有没有出现新的抓取记录。
- 看这些 URL 被抓取时返回的是 200 还是 304。304 比例很高，说明蜘蛛来了但内容没变，lastmod 可能与实际不符。
- 对比同一批 URL 中“改过 lastmod”和“没改过”的抓取次数差异，判断这个信号在当前站点上是否真的被参考。
如果更新了时间却完全看不到回访，先别急着改格式，回头检查内链是否可达、页面是否被 robots.txt 拦住、服务器是否稳定返回。这些基础问题不解决，任何字段层面的调优都看不出效果。
把 lastmod 当成一份诚实的变更记录，而不是催促蜘蛛的按钮。它最多影响回访的优先级，改变不了页面本身的可抓取性。