站点地图（sitemap）大概是站点运营里最容易被“建好就不管”的文件。它不像首页那样每天有人访问，出了问题也未必有反馈——蜘蛛照样抓别的页面，访客毫无感知。等到新栏目上线一两个月还没有动静，或者搜索资源平台里显示的已提交数量长期停在两位数，才想起翻出那个 XML 文件，发现里面的地址还停在两年前。
sitemap 上常见的几类问题
覆盖太少，只列了首页和几个栏目
有些站点只把首页、几个主栏目写进 sitemap，大量文章页、产品页、标签聚合页全靠蜘蛛顺着内链自己爬。这些页面不是抓不到，但被发现的时间会被拉长，新站或者内链较浅的页面尤其明显。检查方式很直接：把 sitemap 里的 URL 数量和站内“可公开访问的正文页”数量做个对比，差距过大就说明覆盖不全。
混进了不该出现的地址
- 已经删除、返回 404 的页面；
- 设了 noindex 的页面，和 sitemap 想表达的意思正好相反；
- 带排序、筛选、会话跟踪参数的重复地址；
- 已经 301 或 302 跳走的旧地址，sitemap 里应尽量写最终地址；
- 后台、登录页、站内搜索结果页等不希望被收录的地址。
lastmod 不可信
有的站点给所有 URL 填同一个时间，有的干脆不填，还有的每次重新生成就把全部页面的 lastmod 刷成当前时间。前两种问题不大，最后一种反而有害：蜘蛛会认为这个字段没有参考价值，之后即使内容真的更新了，也懒得当成更新信号。建议只在正文确实发生实质性修改时才动 lastmod，格式用带时区的完整时间，例如 2025-03-11T09:20:00+08:00。
体积和分片失控
单个 sitemap 文件有上限，通常是 5 万条 URL 且未压缩不超过 50MB，超过就要拆成多个文件，再用 sitemap 索引文件把它们串起来。不少站点是文章量涨上来以后忘了这件事，结果生成脚本报错，或者只生成了前一半。如果站点规模已经不小，建议一开始就按栏目或按月份分片，后续维护会轻松很多。
一份可以直接照做的自查清单
- 打开 sitemap 地址，确认返回 200 且 Content-Type 是 XML 或纯文本，不是被 CDN 或安全策略拦下的错误页。
- 随机抽 10 到 20 条 URL 实际访问一遍，看是否都能正常打开。
- 确认没有 noindex 页面、参数重复页和跳转地址混在里面。
- 检查 lastmod 是否符合格式，是否只有真正更新的页面才变化。
- 确认 robots.txt 里写了 Sitemap 的完整地址，包括分片索引文件。
- 如果站点有多语言或多地区版本，确认对应关系标注清楚，别让蜘蛛把不同语言的页面当成重复内容。
生成与更新：别靠手工维护
手工维护的 sitemap 基本活不过半年。比较稳妥的做法是让程序在内容发布、下线、改地址时自动更新清单，再由定时任务每天或每周重新生成文件。生成逻辑里最好加两条过滤：状态码必须是 200，且页面不能带 noindex。这样即使某天有人误操作，也不会把一堆废弃地址推给蜘蛛。
提交之后怎么验证
提交只是开始。可以在搜索资源平台里看已提交数量和已收录数量的大致比例，但更实在的是去翻服务器日志：搜 sitemap 的文件名，看蜘蛛有没有定期来取、返回码是不是 200、取完之后有没有顺着里面的地址去抓几个页面。如果日志里几乎看不到这个文件的访问记录，那再规整的 sitemap 也只是躺在服务器上的一个 XML。
需要说明的是，sitemap 只是给蜘蛛的一条线索。页面能不能被收录、排在哪里，取决于内容质量、站点整体情况和用户需求，sitemap 本身并不保证任何结果。把它做好，是为了减少“新页面迟迟没人发现”这类本可以避免的损耗。
顺带一提，sitemap 也不能替代内链。一个页面如果只有 sitemap 里的一条记录，站内没有任何入口指向它，蜘蛛即使抓到了，也很难判断它的重要程度。结构清晰的内链，加上一份准确、及时更新的 sitemap，才是比较完整的组合。