很多人把 Sitemap 当成一次性配置：生成、提交、然後就不管了。但站点地图更像是一份持續更新的待办清單，蜘蛛會照着它决定先去哪、後去哪。清單本身如果乱，蜘蛛的节奏也就跟着乱。
lastmod 到底在影响什么
lastmod 不是强制指令，而是一個參考信号。当站点規模較大、更新频繁时，蜘蛛不可能每次都把所有頁面重抓一遍，它需要一個粗略的排序依據：哪些頁面值得優先回訪。如果這個時間戳長期失真，這個排序依據基本就废了。
判断 lastmod 是否可信，标准很简單：随机挑十個 URL，把時間戳和後台真實的修改记錄對一遍，看看能不能對上。
分片结构怎么划更合适
單份 Sitemap 有体积和條目數量的上限约定，超過就需要拆分成索引文件加多份子文件。拆分方式没有唯一答案，但要選一種後續好维護的：
- 按栏目拆：适合栏目更新频率差异大的站点，比如资讯区和产品区分開，各自獨立更新。
- 按内容類型拆：文章、商品、专题頁各一份，便于單獨排查某一類的異常。
- 按時間区間拆：适合大量歷史归档内容，把不再更新的老内容單獨放一份，减少重复生成。
不建议每次全量重寫所有分片。增量更新时只改動受影响的那几份，既能降低服務器负担，也让抓取日誌里的變化更容易看懂。
lastmod 最容易寫错的几處
全站同一個時間戳
有些生成脚本图省事，把目前時間直接寫到所有條目上。结果是每份分片的時間都是“刚刚”，蜘蛛看到所有頁面同时更新，等于没有提供任何区分度。
构建時間覆盖了真實修改時間
静態站点重建时，如果時間戳取自构建過程而不是内容本身的修改记錄，就會出現没改過的頁面也被标成新頁面。正确做法是從内容源或資料库里取真實修改時間。
格式與时区不统一
時間格式需要完整、带时区标识，且和服務器、後台记錄保持一致。如果生成环境用 UTC、後台用本地時間，两邊就會差几個小时甚至一天，對帳时很难判断是谁错了。
只改了样式也更新時間
模板調整、導航微調會触發生成流程，但内容本身没變。這類改動是否该刷新 lastmod，取决于改動是否影响頁面主体内容。如果只是样式，通常没必要。
一套可以照做的自查流程
- 列出目前所有分片地址，確認索引文件能正常訪問，没有遗漏或重复引用。
- 抽样比對：每個分片随机抽几條，和後台修改時間對照，记錄偏差。
- 检查格式，確認时区标识统一，没有缺失或格式错誤的條目。
- 核對内容范围，把不该在里面的 URL 剔除出去。
- 观察日誌，看蜘蛛訪問 Sitemap 的频率、返回狀態，以及 Sitemap 中 URL 的實际抓取情况。
- 把核對動作固定成周期性检查，比如每月一次，而不是等發現問题再回头翻。
哪些 URL 不该出現在 Sitemap 里
- 設定了 noindex 的頁面，两邊信号互相矛盾。
- 會跳轉的舊地址，應直接给出最终地址。
- 已经失效的頁面，Sitemap 里留着只會让蜘蛛反复撞墙。
- 大量參數组合产生的篩選结果頁，這類地址更适合交给頁面内部連結處理。
- 登入後、购物车等無收錄意义的頁面。
和日誌、後台记錄對照着看
Sitemap 只是鏈條的一端。真正判断它是否有效，要看蜘蛛訪問站点地图後有没有實际去抓 URL，抓的是不是清單里的地址，以及新發布的内容多久能被訪問到。把這些观察和内容更新记錄放在一起看，才能判断是站点地图的問题，還是抓取预算、内鏈结构的問题。
這份清單不需要做得很复杂，關键是保持和實际更新节奏一致。清單准了，蜘蛛的時間才花得值。