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 当作“提醒搜尋引擎来看”，而不是“告诉搜尋引擎已经收錄”。它最多能帮你争取一次更早的抓取，不能替你决定收錄结果。