很多站长会把 sitemap 当成“加速收录”的开关：在蜘蛛池入口页挂一份 sitemap，把目标 URL 全部写进去，然后等搜索蜘蛛来抓。实际跑下来常常发现，URL 确实被发现了，抓取却迟迟不来。要理解这个落差，需要先看清 sitemap 在整条发现链路里的位置。
sitemap 解决的是“发现”，不是“排期”
搜索蜘蛛获取新 URL 的路径大致有几条：页面上的 a 标签链接、sitemap、外部链接、站长平台的手动提交。sitemap 的定位是批量告知，它本身不是链接，不传递权重，也不构成优先抓取的凭证。
所以“入口页 + sitemap”的组合，本质上是多开了一条告知通道，而不是拿到了插队的资格。搜索蜘蛛读完 sitemap，会把这些 URL 放进待抓取队列；什么时候抓、抓几次，仍然取决于目标 URL 所在站点的整体情况，比如历史响应速度、内容质量、是否存在大量重复页面。
搜索蜘蛛读取 sitemap 时会关注哪些点
- sitemap 本身能否正常返回 200，Content-Type 是否为 XML
- 里面的 URL 是否可访问，是否返回 200 而不是 404 或跳转链
- URL 是否与目标站 robots.txt 的规则冲突
- sitemap 的位置是否被声明：robots.txt 里的 Sitemap 行、入口页上的链接、站长平台提交
- lastmod 是否真实合理，长期不更新的时间戳参考价值会下降
其中最容易被忽略的一点是：sitemap 里有 URL，但入口页上没有任何指向它的可点击链接。这种情况下 URL 会被记录，但缺少页面级的链接支撑，抓取优先级通常排在后面。
和页面链接相比，差别在哪
页面链接是“甲指向乙”的关系，除了发现 URL，还带着一点上下文信息；sitemap 只是一份清单。对搜索蜘蛛来说，一个既出现在入口页链接里、又出现在 sitemap 里的 URL，可信度通常高于只在 sitemap 里出现的 URL。
如果目标 URL 分散在多个站点，建议每个站点各自维护自己的 sitemap，而不是把所有域名混在一份文件里。单个 sitemap 有文件大小和条目数量的上限，超过之后需要拆分并用索引文件串起来，否则可能出现读取不全的情况。
sitemap 提高的是被发现的概率，不是被收录的概率。发现之后还有抓取、解析、去重、质量判断几道关。
提交之后仍没抓取，常见的原因
- 目标 URL 所在站点整体抓取频次本来就低，待抓队列排得很长。
- URL 返回 3xx 跳转链或 4xx，被反复回退。
- 目标页内容与站内已有页面高度重复，被折叠处理。
- 入口页本身抓取异常，搜索蜘蛛根本没有读到 sitemap。
- 服务器对搜索蜘蛛响应过慢，触发限速或降频。
排查时可以先看服务端日志：搜索蜘蛛有没有真的请求过 sitemap 这个路径，响应码和响应时间是多少。日志里连 sitemap 的请求都没有，问题多半在入口页的抓取环节；日志里 sitemap 被抓了、URL 却没动静，方向就要转到目标站本身。
可以落地的几个调整
- 入口页上给 sitemap 里的重点 URL 补上正常链接，让清单和链接互相印证。
- sitemap 只放返回 200 的规范 URL，去掉跳转版本、参数版本和已下线页面。
- 控制单份 sitemap 的条目规模，必要时拆成多个并用索引文件串联。
- lastmod 随内容真实变化更新，不要每次生成都刷新时间。
- 观察一段时间后，按日志里被抓取的 URL 比例调整清单内容，而不是一味加量。
把 sitemap 当成“告知工具”而不是“提速工具”，预期会更接近实际。它能让搜索蜘蛛更容易知道某个 URL 存在，剩下的事情，还是要靠目标站自身的响应质量和内容来推动。