很多站点把 sitemap 当成“提交收录”的开关：文件生成好、在后台点一下提交，就等着收录上涨。实际观察下来，sitemap 能做的只是把 URL 主动放进蜘蛛的候选队列，它既不改变页面质量，也不保证抓取和索引。所以“提交了没反应”往往不是 sitemap 失效，而是文件里塞了蜘蛛不该抓的东西，或者页面本身还不满足收录条件。
先分清 sitemap 解决的是哪一步
URL 从被发现到进入索引，中间至少有三步：被发现、被抓取、被建索引。sitemap 只对第一步有直接帮助，而且只是众多发现渠道之一，内链、外链、历史抓取记录同样会贡献新 URL。把 sitemap 当作“加速收录”的工具，预期一开始就偏了。
文件本身要能被正常读到
这一步最简单，也最容易被忽略。建议逐个确认：
- 地址可公开访问，返回 200，不是 301 跳转、不是登录后才能看到。
- 内容是合法的 XML，编码统一，不要出现半截截断的标签。
- 在 robots.txt 里用 Sitemap 字段声明绝对地址，方便蜘蛛顺带发现。
- 单个文件不超过 5 万条 URL、未压缩体积不超过 50MB，超了就拆成 sitemap index。
- 如果用了 gzip，文件名和响应头要一致，别让抓取端解压失败。
文件里该放什么 URL
sitemap 的定位是“这些地址我希望被收录”。只要混入不该收录的地址，整份文件的可信度就会下降，抓取量也会被浪费。
- 只放返回 200 且允许索引的页面；不要把 301、404、410 的地址留在里面。
- 被 robots.txt 屏蔽或被 meta robots 标为 noindex 的 URL 不要放，两者信号互相矛盾。
- canonical 指向别的页面的地址，尽量换成规范版本本身。
- 带 session、排序、筛选等参数的重复变体，先做归一化再决定是否收录。
lastmod 别随手写
lastmod 是一个“可选但容易被滥用”的字段。如果每次生成 sitemap 都把全站时间戳刷成当天，蜘蛛很快会学会忽略它，真正更新的页面反而得不到优先抓取。
lastmod 只在页面正文或主要结构确实变化时更新；模板改动、导航调整、页脚换文案，都不算。
提交之后该看什么
提交完就别盯着“收录数”看了，先看更靠前的信号：
- 服务器日志里，抓取端有没有按预期访问 sitemap 文件本身，频率是否正常。
- 日志中新出现的 URL 是不是来自 sitemap，还是主要靠内链带动。
- 后台的 sitemap 报告里，是否存在“无法读取”“包含被屏蔽地址”等提示。
- 索引覆盖率里，这些 URL 是停在“已发现”，还是进入了“已抓取未索引”。
后面两种状态的排查方向完全不同：前者是发现与预算问题，后者更多是页面质量与重复内容问题。
sitemap 替代不了内链
蜘蛛顺着内链走，能同时获得上下文和层级信息；sitemap 给不出这些。一个只存在于 sitemap、站内没有任何入口的地址，即使被抓过一次，后续也很难持续获得抓取。重要页面应该同时具备内链入口和 sitemap 记录，而不是二选一。
一份可用的自查顺序
- 直接打开 sitemap 地址，确认状态码、格式和内容完整。
- 抽查若干 URL，逐个看返回码、robots 状态、canonical 指向。
- 核对 lastmod 是否与实际更新时间一致。
- 确认文件条数和体积在上限内，必要时拆分。
- 提交后用日志验证抓取端确实来过，再判断问题出在发现、抓取还是索引环节。
把这几步走完，多数“提交了没动静”的情况都能定位到具体环节。至于最终是否收录，仍然取决于页面本身能不能回答用户的搜索需求，这一点没有任何提交入口可以替代。