站点地图（sitemap）的作用很朴素：把站点希望被发现的 URL 整理成一份清单，放在固定位置，让蜘蛛来取。它不承诺收录，也不代表提交了就会被抓取，但它是少数几个由站点主动发起、成本又很低的沟通渠道。问题在于，很多站点的 sitemap 是建站时自动生成的一版，之后栏目调整了、地址改写了、内容下线了，文件却一直躺在服务器上没动过。
先确认这份文件有没有真的在被读
自查的第一步不是改内容，而是确认这条链路是通的。如果文件本身打不开，后面做什么都白费。
- 直接用浏览器或命令行请求 sitemap 地址，确认返回 200，而不是 404、403 或者被跳转到一个 HTML 页面；
- 确认返回的内容类型是 XML，而不是被服务器当成普通文本或下载文件；
- 在搜索引擎的站长后台提交一次，观察后续的抓取与索引数据是否有变化；
- 到服务器日志里搜一下 sitemap 的文件名，看看蜘蛛最近有没有来取，频率如何。
如果日志里长期没有任何抓取记录，常见原因是 robots.txt 里没有声明 Sitemap 地址，或者声明了一个已经失效的路径。这一行写错，后面所有维护都等于零。
提交范围：哪些地址不该写进去
sitemap 不是「越多越好」的清单。放进去的每一条地址，都相当于在告诉蜘蛛「这个值得花时间看」。以下这些类型通常不值得占位：
- 会批量生成地址的参数页，比如排序、筛选、会话跟踪参数，一个列表页可能派生出成百上千条组合；
- 返回 404、410 的失效地址，以及还在做 301、302 跳转的旧地址，应该提交跳转后的目标地址；
- 设置了 noindex 的页面，一边说不让索引，一边把地址列进 sitemap，属于自相矛盾的信号；
- 需要登录才能访问的页面，蜘蛛取不到内容，只会消耗抓取预算；
- 已经被 canonical 指向别处的重复副本，以及测试域名、分站镜像里的同一篇内容。
把这些地址清出去，sitemap 的总量会明显下降，剩下的条目反而更容易被抓取到。
lastmod 要真实，其他字段不用纠结
lastmod 是 sitemap 里少数仍被参考的字段，它的价值建立在一个前提上：时间戳反映的是页面内容的实际改动，而不是文件生成的时间。如果每次程序跑一遍就把所有地址的时间戳刷成当下，这个字段很快就会被忽略。
比较稳妥的做法是让 lastmod 来自内容表的更新时间字段，只有正文确实改动时才更新。至于 changefreq 和 priority，主流搜索引擎早就明确表示不太参考，不值得为它们反复调参。
分片、数量与多语言处理
- 单个 sitemap 文件通常建议控制在 5 万条 URL、未压缩 50MB 以内，超出部分用 sitemap 索引文件把多个分片串起来；
- 按内容类型分开更利于排查，文章、商品、视频、图片各自一个文件；
- 多语言站点可以按语言各出一份，并在页面里用 hreflang 做好对应，不建议把多个域名的地址混进同一个文件；
- 索引文件本身也要能被直接访问，且不要嵌套过深，保持两三层以内。
一份可以照着走的自查流程
- 拉取 sitemap 中的全部地址，抽样或全量请求，记录状态码分布；
- 筛出 3xx、4xx、5xx 三类地址，分别确认是跳转未更新、页面已下线还是服务器异常；
- 抽查页面的 meta robots 与 canonical，看是否与 sitemap 的意图一致；
- 对比 lastmod 与页面正文的实际更新时间，确认没有整批刷新的情况；
- 核对分片数量与索引文件，确认没有遗漏或重复收录；
- 检查 robots.txt 中的 Sitemap 声明，并到搜索后台确认最新提交时间；
- 把上述检查结果写进固定的生成流程，让 sitemap 跟着内容系统自动更新，而不是靠人工定期重做。
把 sitemap 当成一份需要跟着站点一起演进的清单，而不是一次生成就永久生效的静态文件。它不需要频繁改动，但需要有人定期看一眼。
最后提醒一点：清理 sitemap 之后，索引量和抓取量未必立刻有变化，它解决的是信号一致性的问题——让蜘蛛把有限的抓取额度用在你真正想让人看到的内容上。这件事没有捷径，但检查一遍的成本，通常比事后排查收录异常要低得多。