很多运营者把 sitemap 当成“提交了就等着收录”的通道。等到索引报告出来，发现提交了几千条，实际被索引的只有一成，于是开始怀疑抓取出了问题。实际情况通常更琐碎：sitemap 只是帮助搜索引擎发现 URL 的入口之一，它既不决定抓取，也不决定页面能否进入索引。当提交量和收录量对不上时，按下面几层逐级核对，大多能找到原因。
先把三个数字分开看
很多人一上来就比对“提交数”和“收录数”，这两个数字本来就不是一回事。中间至少还要拆出抓取量。
- 提交量：sitemap 里声明的 URL 总数，如果用了 sitemap 索引文件，要把子文件展开后统计。
- 被抓取量：从服务器日志或抓取统计里看，代表蜘蛛确实访问过的 URL。
- 被索引量：索引报告或站内查询的结果，这个数字本身波动较大，不适合每天盯着比对。
三者依次递减属于正常现象。真正值得关注的是某一段出现断崖，比如抓取量正常但索引极少，或者提交了大量 URL 却几乎没有被访问。
第一层：sitemap 文件自身的问题
先确认这份清单本身是干净可用的，否则后面的判断都会被带偏。
- URL 是否全部返回 200，有没有混进 301、404、410 之类的旧地址；
- 单个文件是否超出 50MB 或 5 万条的限额，超了就拆成 sitemap 索引文件；
- 是否包含被 robots.txt 屏蔽、或页面自带 noindex 的 URL，这两类提交了也不会被索引；
- lastmod 是否真实反映内容更新，长期不变的假时间戳会让蜘蛛降低对这个字段的信任；
- 协议、主机名、结尾斜杠是否统一，别把同一批页面用两种写法各写一遍。
第二层：URL 层面的冲突
这一层最容易被忽略，因为它看起来像是“没收录”，其实是索引被算到了别的地址名下。
典型情况包括：页面 canonical 指向了另一个版本；URL 带一串无意义参数，每次生成都不一样；同一份内容存在三个地址，而 sitemap 把三份都提交了。这时你在原地址上查询，自然看不到结果，但索引总量并没有减少。
处理办法是先确定每个页面唯一希望被索引的地址，再让 sitemap、canonical、站内链接指向同一个版本，而不是三套写法并存。
第三层：页面本身能不能进索引
抓取正常、URL 无冲突，仍然没被索引，就要回到页面本身看。
- 主体内容是否足够：模板、导航、推荐位占比过高时，正文容易被判定为信息量不足；
- 是否与站内已有页面高度相似，例如同一产品的不同规格各做一个页面，文字几乎一样；
- 是否存在可访问性障碍：强制登录、地区限制、内容完全依赖 JS 渲染而首屏为空；
- 时效性页面是否已经过期，过期内容保留在索引里的优先级本来就偏低。
一条实际可用的核对顺序
- 从 sitemap 里随机抽 20 到 30 条 URL，逐条确认状态码和 meta robots；
- 用站内搜索或日志确认这些 URL 是否被抓取过，以及抓取时间距今多久；
- 对已抓取但未索引的页面，检查 canonical 归属与站内重复度；
- 把整批 URL 按栏目归类，看是某一类整体表现差，还是随机分布；
- 修正后观察 2 到 4 周再下结论，不要在上线第二天就判定无效。
sitemap 的价值在于帮助发现和清点 URL，它不能代替页面质量，也不能承诺收录。把它当成一份需要定期维护的清单，比当成一个提交按钮更有用。
另一个常见误区是反复重新提交同一份 sitemap。如果 URL 没有变化，重复提交并不会加快处理，反而让你更难判断哪次调整起了作用。保持内容更新、保持清单准确、保持一个版本对应一个地址，比频繁提交更有意义。