在站长平台点了提交，sitemap 状态显示成功，可等了一两周，索引里的地址数量几乎没有变化。这时候容易得出一个结论：sitemap 没什么用。更接近实际的解释是，sitemap 只是把一批地址送进候选队列，从提交到真正进索引中间隔着好几环，任何一环断了，后面的发现都不会发生。

先把三件事分开看

• 提交：你在平台或 robots.txt 里声明了这份清单，只说明数据传过去了。
• 被读取：蜘蛛确实下载了这个文件，并且能解析出里面的地址。
• 被收录：蜘蛛又去抓了这些页面，判断质量后才决定是否建索引。

平台里的“提交成功”只覆盖第一步。后面两步卡住时，界面上通常不会明说卡在哪里。

第一步核对：sitemap 自己能不能被抓到

几个常被忽略的检查点

• 文件是否返回正常状态码，而不是重定向、拒绝访问或需要登录。
• robots.txt 里有没有把 sitemap 所在目录或路径屏蔽掉，屏蔽规则的优先级高于 sitemap 声明。
• robots.txt 里的 Sitemap 声明是否写成完整绝对地址，域名和协议有没有写错。
• 服务器是否对蜘蛛请求做了频率限制或 UA 拦截，导致下载被拒。

如果 sitemap 挂在需要验证、带参数或会随会话变化的地址上，蜘蛛拿到的可能是一份空内容。

第二步核对：格式能不能被解析

• 地址必须是绝对 URL，带完整协议和域名，相对路径一般不会被解析。
• 单个文件的地址条数有上限，超出部分会被忽略，需要拆分并做索引文件。
• XML 声明、命名空间、标签闭合要正确，手工拼接的内容最容易在这里出错。
• 编码统一用 UTF-8；地址里有特殊字符时需要转义，而不是直接塞进去。
• 压缩文件要符合约定格式，命名不对可能根本不被读取。

一个快速验证方式：把 sitemap 地址丢进浏览器查看源代码，看列出的地址是否完整、是否和预期一致。你看到的，应当和蜘蛛拿到的一致。

第三步核对：里面的地址本身经不经得起抓

sitemap 只负责“告诉”，不负责“担保”。清单里的地址如果本身有问题，被读取了也不会进索引：

• 地址返回重定向链，蜘蛛要多跳几次才落到目标页。
• 页面带 noindex，或者被 robots.txt 屏蔽了抓取。
• 地址里带大量会话、排序、筛选参数，同一份内容散成几十个地址。
• 页面内容稀薄、与站内其他页面高度重复，属于典型的质量不足。

所以一份干净的 sitemap，往往比一份很大的 sitemap 更有效。

第四步核对：它到底有没有被读过

最直接的证据在服务器访问日志里。筛出 sitemap 地址的请求，看几件事：状态码是不是正常，请求方是不是搜索蜘蛛，读取频率是否稳定，以及读取之后有没有紧接着出现对清单内地址的抓取。

如果日志里长期看不到 sitemap 请求，问题多半在发现入口，比如 robots 声明、平台提交、外部链接指向；如果 sitemap 被反复读，但清单里的地址始终没被抓，问题更可能出在地址质量或站点整体的抓取分配上。

把 sitemap 当成一条“发现通道”，而不是收录开关。它能提高页面被看到的概率，但不能替页面解决质量、重复和可抓取的问题。

一次可执行的核对顺序

1. 确认 sitemap 地址返回正常，内容与预期一致。
2. 确认 robots.txt 没有屏蔽，并正确声明了 sitemap 地址。
3. 检查格式、条数上限、绝对地址与编码。
4. 抽查清单内地址的状态码、canonical、noindex 与内容质量。
5. 用日志验证蜘蛛是否真的读过，读完有没有跟进抓取。
6. 按“发现没生效”和“发现生效但没进索引”两类问题分开处理。