站点地图里的 lastmod 字段，本意是告诉搜尋引擎“這個 URL 的正文最後一次實质性變化發生在什么时候”。它不决定頁面能否被收錄，但會影响抓取調度：抓取资源有限时，一個看起来很久没變過的 URL 往往排在後面。問题在于，很多站点的 lastmod 是程序自動寫入的時間戳——每次部署、每次生成缓存、每次模板微調都會刷新它，這個信号很快就失真了。
lastmod 失真後會看到什么
它不會让站点立刻出問题，通常會表現為几種慢性症状：
- 全站 URL 的 lastmod 每天一起變化，搜尋引擎無法從中区分哪些頁面真的更新了；
- 真正修改過的頁面淹没在大量“伪更新”里，重新抓取要排更久的队；
- 反過来，如果某個栏目的時間戳長期不動，抓取频次也可能随之下降；
- 报告里“已抓取，尚未编入索引”的比例升高时，很难判断是内容問题還是調度問题。
先给 lastmod 一個明确的定义
在動手改之前，团队内部要先统一它代表什么，例如：
- 只表示正文主体的變化，包括标题、正文内容、關键資料與图表的修订；
- 不触發更新：模板改版、CDN 刷新、评论新增、广告位調整、文件重新部署；
- 触發更新：正文增删、資料修订、错別字與事實纠错、正式發布時間調整。
如果頁面同时展示“發布時間”和“更新時間”，要保證结构化資料、頁面文字和站点地图三者一致，不要出現頁面寫着 2019 年、lastmod 却是今天的情况。
核對顺序
- 抽样比對。從站点地图里随机取 20 到 30 條 URL，把 lastmod 與頁面上顯示的更新時間、版本记錄逐條對照，先看有没有明顯不吻合的样本。
- 看整批分布。把全站 lastmod 按日期做一次統計。如果九成 URL 集中在最近两三天，基本可以判断這是程序统一寫入的時間，而不是真實更新時間。
- 定位寫入位置。找到生成 sitemap 的那段代碼，確認時間字段取的是内容表的更新時間，還是文件系統修改時間、构建時間或執行時間。
- 按頁面類型区分。文章、商品類頁面适合细粒度的最後修改時間；分類頁、标簽頁可以取“该分類下最新一篇内容的時間”，但不要用目前時間。
- 處理歷史值。如果站点有版本记錄或歷史快照，可按内容實际修订時間回填；没有可靠依據时，宁可留空或寫一個偏保守的時間，也不要繼續寫当天。
- 观察後續變化。修正後观察几周的抓取频次，以及“已發現—尚未抓取”的數量變化。這類信号需要時間才反映出来，不要频繁反复調整。
另外两個字段可以少花精力
changefreq 與 priority 早已被主流搜尋引擎忽略，繼續维護它們意义不大。真正值得投入的，是让 lastmod 接近事實，同时保證 URL 本身干净、可訪問、返回正常狀態碼，並且站点地图里只放需要被抓取的地址。
lastmod 只是一個調度提示。它不能让质量不够的頁面被收錄，也不能替代内容本身的更新。把它寫准，是為了让抓取资源更多地花在你真正改動過的頁面上。
如果你在訪問日誌里看到某個搜尋引擎反复抓取同一批入口頁、却很少深入内頁，除了检查内鏈與结构，也不妨回头看一眼站点地图里的時間戳是不是在频繁抖動。這種“看起来一直在更新”的假信号，往往是抓取集中在内层几個地址上的原因之一。