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 当成一種沟通方式
它本质上是在告诉抓取系統：這個地址值得重新看一眼。前提是這句话得是真的。稳定的時間戳，配合正常的狀態碼、清晰的站内連結和可靠的服務器响應，才更可能在長期里換来相對稳定的抓取节奏。