在 Sitemap 的字段里，lastmod 大概是最容易被随手填写的一个。很多站点要么全部用构建时间，要么干脆不写。它本身不会让页面被收录，但会影响蜘蛛判断“这个 URL 是否值得再来一次”的优先级，所以值得认真对待。
lastmod 在抓取调度里的位置
蜘蛛安排下一次抓取时，通常会参考几个信号：页面上次被抓取的时间、内容是否发生变化、站点整体的更新节奏，以及 Sitemap 中声明的 lastmod。前几项来自蜘蛛自己的观察，最后一项来自站点自己的声明。
当声明与观察长期一致时，这个信号会被更信任；当声明经常和实际情况对不上，它就会逐渐被忽略。这也是“全部填今天”这种做法往往不如不填的原因。
三类常见的 lastmod 错误
- 全站统一时间：每次生成 Sitemap 都把当天日期写给所有 URL。蜘蛛抓回来发现内容与上次一样，声明就失去了参考价值。
- 时间倒流或超前：修改内容后忘了更新，或者用了未来的时间戳。前者让新内容被当成旧内容，后者通常直接被忽略。
- 粒度太粗：只精确到天，或者每次构建都刷新一遍。对更新不频繁的栏目页影响不大，但对新闻、商品、库存类页面，粗粒度会把“刚改过”的信号淹没掉。
怎么生成一份相对可信的 lastmod
- 让 lastmod 跟随内容本身的变化，而不是构建动作。可以在内容表里保留 updated_at 字段，编辑保存时更新，构建时读取。
- 只有正文、价格、库存这类实质字段变化时才更新；导航、页脚模板调整不应触发全站时间戳变化。
- 统一时区与格式，使用带时区的 ISO 8601 写法，避免服务器时区和蜘蛛理解不一致。
- 不要人工填写。人工维护的字段在几百个 URL 之后基本必然失控。
把 lastmod 当成内容变更日志的投影，而不是 Sitemap 的生成日志，判断标准会清晰很多。
lastmod 之外，蜘蛛还在看什么
HTTP 层的信号同样在起作用。Last-Modified 和 ETag 让蜘蛛可以用条件请求确认内容是否变化，命中 304 时能省下一次完整的响应传输；Cache-Control 的 max-age 则影响它多快愿意再来确认一次。这些响应头与 Sitemap 里的 lastmod 如果互相矛盾，通常以响应头为准。
页面自身展示的更新时间，例如文章页的发布日期与更新日期，如果和 lastmod 差得太远，也会让信号变得模糊。
落地时的取舍
对中小站点来说，比较稳妥的做法是：只给确实需要频繁再抓取的栏目开启精确 lastmod，其余页面保留一个大致准确的时间即可。与其追求所有 URL 都精确，不如保证被频繁访问的那一批不出错。
如果暂时没有能力维护，宁可不写这个字段，也比系统性写错要好。抓取调度本来就有多个信号，一个持续失真的字段只会稀释站点其他信号的可信度。