很多站点把 Sitemap 索引文件当成一次配置就长期不管。实际上，搜索蜘蛛读取 Sitemap 时是先请求索引文件，再按其中的 loc 逐条拉取子地图。只要索引文件里的某条链接失效、子地图压缩格式异常，或者单文件超过限制，后续一批 URL 就可能长时间不被发现。
一、先确认蜘蛛是否真的请求了子地图
不要只看服务器访问日志里有没有 Sitemap 索引的 200。更实用的做法是筛选蜘蛛 UA，观察它是否继续请求子地图路径。
- 索引文件被请求，但子地图没有任何请求记录：优先检查 loc 是否可公开访问、是否被 robots.txt 拦截、是否返回 3xx 或 4xx。
- 子地图只被请求一两次就停止：可能是响应超时、返回内容不是 XML、或者文件过大导致读取中断。
- 子地图请求集中在旧分片，新分片从未出现：检查索引文件是否更新、CDN 是否缓存了旧版本。
如果索引文件走了 CDN，务必确认缓存刷新后蜘蛛看到的是最新内容，而不是旧索引。
二、索引文件本身的常见问题
Sitemap 索引文件的格式并不复杂，但细节容易出错。
- 路径与域名不一致：索引中 loc 使用了测试域名、带端口的内网地址，或者 http 与 https 混用，蜘蛛无法按预期抓取。
- 编码问题：XML 声明、字符集与实际内容不一致，中文 URL 或特殊字符可能解析失败。
- 大小与数量超限：单个 Sitemap 文件通常有 URL 数量和未压缩体积限制，索引文件也有子地图数量限制。超出后可能被截断或直接忽略。
- 压缩与 Content-Type 不匹配：.gz 文件返回 text/html 或 application/octet-stream，部分抓取端会放弃解析。
三、子地图分片与读取顺序排查
子地图分片不合理，会直接增加读取失败的概率。
- 把大量 URL 塞进一个文件，响应体过大，蜘蛛可能只读完前面一部分。
- 分片按时间滚动生成，但旧分片被删除后索引仍引用，形成死链。
- 子地图内 URL 与索引声明不一致，比如索引说 5 万条，实际只有几千条。
- 动态生成子地图耗时过长，首字节延迟高，蜘蛛容易放弃。
建议把子地图控制在合理体积内，按内容类型或栏目拆分，并确保每个分片都能独立打开、返回正确 XML 头。
四、一个可执行的排查顺序
- 用蜘蛛 UA 或日志筛选，确认索引文件与子地图的请求记录。
- 直接访问索引文件，检查 HTTP 状态、Content-Type、是否被重定向。
- 逐条打开索引中的子地图 loc，确认均可访问且返回有效 XML。
- 检查子地图内 URL 数量、格式、域名是否一致，避免混入站外或参数爆炸链接。
- 对比 CDN 与源站内容，排除缓存旧索引或旧分片。
- 观察随后几天的抓取日志，看子地图请求是否恢复、URL 发现量是否回升。
五、日常维护建议
Sitemap 不需要频繁重写，但需要和站点结构同步。新增栏目、改版路径、切换域名时，索引文件和子地图应一起更新。若站点使用自动生成方案，建议保留一个简单的手动检查入口，方便快速验证索引、分片和压缩是否正常。
最后提醒：Sitemap 只是 URL 发现的辅助入口，不能替代内链和导航。蜘蛛是否抓取、何时抓取，仍受站点质量、服务器稳定性和抓取预算影响。把索引和子地图排查清楚，可以减少“明明提交了却长期不出现”的低级问题。