Sitemap 里的 lastmod 是站点主动告诉搜索引擎的“这个页面最近改过”。它是抓取调度信号，不是收录结果。核对收录时，如果把 lastmod 当成判断依据，很容易得出错误结论：明明时间戳是今天，为什么索引里还是三个月前的内容？或者反过来，页面刚改完，索引里却毫无变化。
lastmod 影响什么、不影响什么
先建立一个边界，后面的核对才不会跑偏。
- 影响：搜索引擎安排抓取队列时，会把 lastmod 当作页面新鲜度的参考之一，与其他信号（内链变化、历史抓取频率、页面权重）一起决定下次抓取时间。
- 不影响：是否收录、收录后展示哪个版本、能否被检索到。这些由页面质量、内容重复度、canonical 选择等决定。
- 不保证：写了最新的 lastmod，也不代表搜索引擎会立刻来抓，更不代表抓完就会更新索引。
核对顺序：先确认声明，再确认事实
建议按下面的顺序走一遍，避免在错误的环节上反复排查。
第一步 检查 lastmod 是不是被批量刷新
不少 CMS 或插件会在发布任意一篇文章时，把整站 Sitemap 的 lastmod 全部改成当前时间。这种情况下 lastmod 已经失去区分度：搜索引擎看到全站“同时更新”，反而会降低对这个字段的信任，抓取调度也不会按预期倾斜。核对方法很简单，发布一篇内容后，看 Sitemap 里有多少 URL 的时间戳同时变了。
第二步 比对真实改动范围
把 lastmod 和实际改动对照：正文有没有变？还是只动了侧栏、推荐位、页脚、面包屑？如果每次只是模板层面变化，正文主体没变，那么这个页面对搜索引擎来说并没有新内容，收录状态自然不会有变化。真正需要核对的是正文可读区域是否更新。
第三步 看抓取有没有发生
lastmod 更新之后，去服务器日志里看对应 URL 是否被重新抓取、抓取时间是什么时候、返回状态码是什么。如果日志里根本没有这次抓取，问题在调度层面；如果抓了但索引没变，问题在内容或信号层面。这一步能把“没被抓”和“抓了不收录”分开。
第四步 检查是否有互相打架的信号
常见情况是：Sitemap 说这个页面刚更新，但 canonical 指向了另一个页面，或者模板里还残留 noindex，又或者正文只在登录后才可见。这类冲突会让收录归属跑到别处，和 lastmod 新旧无关。核对时把 canonical、robots meta、内容可访问性一起看。
lastmod 常见的四种失真写法
- 每次发布全站刷新：所有 URL 时间戳一致，等于没有信息。
- 固定用生成时间：Sitemap 每次生成都是当前时间，同样没有区分度。
- 格式或时区不规范：应使用带时区的标准格式，例如 2025-03-14T09:20:00+08:00，残缺格式可能被忽略。
- 写成未来时间：比当前时间还晚的 lastmod 基本会被判定为不可信。
怎么改才有效
核心原则只有一条：正文主体发生实质变化时才更新 lastmod。模板调整、导航改版、推荐位轮换，都不应该触发全站时间戳变化。站点规模较大时，可以只对更新频率高的栏目输出 lastmod，其余页面留空，通常比填一个假时间更安全。
另外，lastmod 应与页面上的可见更新时间保持一致。如果页面底部写着“更新于 3 月”，Sitemap 里却是 6 月，用户和搜索引擎都会对站点的可信度打折。
收录核对清单
- 确认 lastmod 不是全站同时间批量刷新。
- 确认改动发生在正文主体，而非模板或推荐位。
- 去日志确认该 URL 最近是否被抓取。
- 检查 canonical、noindex、robots.txt 是否存在冲突。
- 确认页面内容无需交互或登录即可完整读取。
- 对比索引中实际保存的版本与当前版本差异。
- 只在上述环节都无异常时，才考虑内容质量与竞争层面的原因。
把 lastmod 当作“提醒搜索引擎来看”，而不是“告诉搜索引擎已经收录”。它最多能帮你争取一次更早的抓取，不能替你决定收录结果。