lastmod 是给蜘蛛的参考信号，不是命令
Sitemap 里除了 loc，还可以给每个 URL 加一个 lastmod，表示这个 URL 最后一次实质更新的时间。它采用 W3C 的日期时间格式，例如 2024-05-12T08:30:00+08:00，至少要写到日期。
蜘蛛读取 Sitemap 时，会把 lastmod 当成一个参考信号：这个页面比我上次抓到的版本新，可能值得再看一眼。但它只是判断依据之一，蜘蛛还会结合上次抓取时间、页面重要性、站点整体变化量来决定先看谁。写对不会带来什么额外待遇，写错却可能让这个字段逐渐失去意义。
三种常见的错误写法
- 全站同一个时间戳。每次生成 Sitemap 时，把所有 URL 的 lastmod 刷成当前时间。蜘蛛第一次可能还会参考，几次之后发现内容其实没变，这个字段的区分度就没了。
- 用构建时间或文件修改时间。模板改动、部署发布、缓存回源都会让文件时间变化，但页面正文可能一个字没动。把这类时间写进去，等于告诉蜘蛛每天全站都在更新。
- 未来时间或时区错误。写成明年的日期，或者把本地时间当成 UTC 写，会让蜘蛛对时间线的判断错乱。统一使用带时区的 ISO 8601 格式最稳妥。
真正该写的是内容变化时间
比较可靠的做法，是让 Sitemap 里的 lastmod 来自内容管理系统的更新时间字段，而不是模板层或发布流程的生成时间。
几条判断标准
- 正文增删、勘误、补充数据、替换主图，算更新。
- 只改了页脚、导航、广告位、推荐位，不算更新。
- 批量调整全站样式或统计代码，不要顺手把全站 URL 的 lastmod 一起刷新。
- 局部改动只改对应 URL 的 lastmod，其余保持原值。
如果站点没有可靠的内容更新时间字段，宁可不在 Sitemap 里写 lastmod。缺省字段不会带来坏处，写满错误的时间反而会削弱整份 Sitemap 的可信度。
分片 Sitemap 与索引文件的 lastmod
URL 数量较多时，站点通常用 Sitemap 索引指向若干分片文件。索引里每个分片也能标注 lastmod，它表示该分片内所有 URL 中最新的那个更新时间。
常见的毛病是：分片内容没有任何变化，却被重新生成，索引里的 lastmod 跟着一起变。更细的做法是，只有当某个分片里的 URL 集合或时间确实有变化时，才更新这个分片的 lastmod，其他分片保持不动。
和其他更新信号配合起来看
lastmod 最好与页面上能看到的信号保持一致，否则蜘蛛拿到的是互相矛盾的线索。
- 页面上显示的发布时间、更新时间，和 Sitemap 里的 lastmod 不要互相打架。
- 结构化数据里的 dateModified 如果存在，也应与页面可见时间接近。
- 内链变化本身就是一种发现信号。新增一条从栏目页指向新 URL 的链接，往往比只把它塞进 Sitemap 更直接。
- 内容发生实质变化后，可以顺手在站内合适位置补一条内链，让蜘蛛有路径跟进来。
一个可以长期执行的维护习惯
- 确认内容更新时间字段的来源，确保它只在编辑动作之后变化。
- 生成 Sitemap 时读取这个字段，而不是文件系统时间。
- 每次发布前抽查几个 URL，看 lastmod 是否与实际更新时间对得上。
- 提交后在 Search Console 的 Sitemap 报告里观察已发现 URL 数的变化。
- 定期用服务器日志核对：被重新抓取的 URL，是否集中在 lastmod 较新的那批。
lastmod 的价值不在于让蜘蛛立刻就来，而在于它在决定先看哪些页面时，能拿到一份大致准确的排序依据。字段越小、越准，越有用。