很多站点把 sitemap 当成“提交即收录”的开关，于是出现一种典型落差：文件里列了十万条 URL，搜索后台显示被发现的有一大半，真正进了索引的却只有几千条。这个落差不一定是 sitemap 写错了，更常见的原因是它的作用被高估了。站点地图只解决“告诉蜘蛛这里有个地址”，后面能不能被抓、抓了之后要不要留，是另外几道关。
站点地图解决的是发现问题，不是收录问题
一个 URL 从存在到出现在搜索结果里，大致要经过发现、抓取、索引三步。sitemap 只在前一步起作用，而且不是唯一的发现渠道——内链、外链、历史抓取记录、搜索后台的提交入口都能起到类似作用。因此 sitemap 里的 URL 数量，和最终收录数量之间没有固定的比例关系。
反过来也一样：没写进 sitemap 的页面，只要内链结构正常，照样可能被抓取和收录。把 sitemap 当作收录数量的控制手段，方向从一开始就偏了。
检查文件本身有没有问题
能否正常访问
先确认 sitemap 的地址返回 200，不是 404，中间没有多余的跳转，也没有被 robots.txt 拦住。用搜索后台的站点地图报告提交一次，看系统能不能读到里面的条目数；如果读不到，多半是格式或访问层面的问题，而不是内容质量的问题。
分片与索引文件
单文件有 5 万条 URL 和 50MB 两个上限。超过之后要么压缩成 .gz，要么拆成多个分片，并用一个索引文件把它们串起来。索引文件里只能放分片地址，不能再混页面 URL，这一点写错会直接导致后半部分被忽略。
lastmod 不要随手写
有些程序把 lastmod 统一设为当前时间，每次生成都刷新一遍。这种做法短期看似在提醒蜘蛛来抓，长期会让时间戳失去参考价值，蜘蛛逐渐不再优先处理。修改时间应当和页面实际内容的变动对应。
别把不该出现的 URL 放进去
重定向地址、返回 404 的旧地址、被 noindex 标记的页面、带一堆跟踪参数的链接，都不适合出现在 sitemap 里。它们会稀释抓取配额，也会让后台的“已发现”数字虚高，掩盖真正的问题。
收录数量偏少时的排查顺序
- 确认 sitemap 只包含规范化后的最终地址，没有重定向和参数版本。
- 抽样十几个未收录的 URL，逐个检查返回码、meta robots、canonical 指向是否正常。
- 看这些页面在站内有没有可点的入口。孤岛页面即使被 sitemap 列出，也可能长期排不上抓取。
- 核对页面内容是否与其他地址高度重复，或者正文本身太少。
- 对比服务器日志，确认蜘蛛到底有没有来过这些地址。来过却没收录，问题在页面；压根没来，问题在抓取优先级。
用两个数据源交叉看
站点地图报告里的“已发现”和日志里的实际抓取量，是两个不同的口径。前者只说明文件被读到了，后者才反映蜘蛛真的访问过。把这两个数字和索引量放在一起比对，基本能判断卡在哪一步：读到了却没抓，是抓取调度的问题；抓了却没收录，要回到页面本身去找原因。
把 sitemap 当成一份“待确认清单”而不是“应收录清单”，心态会稳很多。它的价值在于让站点的重要页面不被漏掉，而不是保证每一个地址都进索引。
最后回到维护习惯
规模较大的站点，建议让 sitemap 由程序按栏目或时间自动分片生成，定期清理失效地址，并且只在页面真正上线之后才加入。配合清晰的内链结构和稳定的服务器响应，站点地图才能发挥它那一部分作用——剩下的，仍然要交给页面本身。