lastmod 被忽略，多半不是抓取系统的问题
不少站点在 Sitemap 里认真写了 lastmod，抓取频次却没什么变化，于是得出一个结论：这个字段没用。实际情况往往是时间戳本身失真——整站 URL 共用同一个时间，或者每次生成 Sitemap 时把当前时间整体刷新一遍。这种信号被反复证伪之后，再想靠它争取更新抓取就更难了。
填写 lastmod 的三条基本规则
只在内容发生实质变化时更新
改标题、改正文、调整价格和库存都算变化；换模板、调样式、加统计脚本不算。如果程序无法区分这两类改动，宁可不动，也不要全站刷新。
格式规范并且带时区
建议使用 W3C Datetime 格式，日期和时间都写全，并带上时区偏移，例如 2024-05-12T08:30:00+08:00。只写日期也能被接受，但会丢失同一天内的先后关系。
不要写成未来时间
lastmod 晚于服务器当前时间，基本会被判为不可信。批量导入历史数据、从测试环境同步内容时最容易踩到这一点。
程序自动生成时的几个常见坑
- 后台保存文章时，即使只是点开没做修改，也刷新了更新时间字段；
- 更换模板后整站重建，所有 URL 的 lastmod 被统一覆盖成同一天；
- 多语言或分区域站点，各个语言版本共用同一个时间戳，无法体现该先看哪个；
- 定时任务每小时重写一次 Sitemap 文件，导致分片时间持续变动。
怎么核对时间戳是否可信
- 抽样取 20 到 50 个 URL，把 Sitemap 里的 lastmod 和数据库中的更新时间字段对照，看偏差是否集中在某类模板或某个栏目。
- 在抓取日志里筛出这些 URL，观察响应是 200 还是 304。如果内容明明没变却长期返回 200，说明时间戳和实际内容已经脱节。
- 看整站 lastmod 的分布。如果九成 URL 集中在同一分钟，基本可以确认是生成程序统一刷新的，而不是真实更新。
- 把有真实更新的页面单独列出来，看它们在更新后的一段时间里是否被重新访问，以此判断信号是否仍被采信。
分片 Sitemap 里的 lastmod 是另一回事
Sitemap 索引文件中的 lastmod，指的是分片文件本身的修改时间，不是分片里那些页面的更新时间。分片内容没变，就不要去动这个时间；频繁重写分片文件，只会让索引看起来一直在变化，反而增加核对成本。同理，每个分片内部只放相对稳定的一批 URL，比每次全量重新生成更容易维护。
时间戳的价值来自长期一致，而不是某一次写得漂亮。一个从不虚报的 lastmod，比一个天天刷新的 lastmod 更有用。
changefreq 和 priority 不必太纠结
这两个字段早已不是主要的调度依据，填了也很难带来额外抓取。与其花时间估算到底该写每天还是每周，不如把 lastmod 写准，把内链入口理清楚，让重要页面在站内更容易被走到。
把 lastmod 当成一种沟通方式
它本质上是在告诉抓取系统：这个地址值得重新看一眼。前提是这句话得是真的。稳定的时间戳，配合正常的状态码、清晰的站内链接和可靠的服务器响应，才更可能在长期里换来相对稳定的抓取节奏。