页面数量到几千、几万以后，单个 XML 站点地图往往放不下，于是需要拆成多个分片，再用一个索引文件把它们串起来。问题也常出在这一步：分片本身没问题，索引文件的写法或返回状态有偏差，爬虫读完索引却没有继续读分片，URL 发现就断在这里。
先确认什么时候需要拆
主流搜索引擎对单个站点地图文件有大致相同的约束：未压缩文件通常不超过 50MB，单个文件包含的 URL 一般不超过 5 万个。接近任一上限就该拆分。
- 页面量在数千以内，单文件基本够用，拆开反而增加维护成本。
- 数量上万，或单文件明显变大（比如带了较长的 hreflang、图片、视频信息），建议按目录或按页型拆分。
- 拆分维度最好和站点结构一致，比如商品页一片、文章页一片、栏目页一片，出问题时容易定位。
索引文件的写法要点
索引文件的根节点是 sitemapindex，每个子项里只放 loc（分片地址）和可选的 lastmod，不要出现页面级的 url 节点，也不要写 priority、changefreq 这类只属于页面级站点地图的字段。
- loc 必须是完整的绝对地址，包含协议和域名，不要用相对路径或 ../ 形式。
- 分片地址要能直接返回 200，中间不要经过 302 跳转、登录校验或地域拦截。
- 命名空间要和根节点匹配，复制模板时改错命名空间是常见原因。
- 不要自我引用，索引文件里不要再把索引文件自己列进去。
- lastmod 用统一的日期格式，不要同一批分片全部写成同一个时间点，也不要用未来时间。
分片文件本身的几个坑
- 压缩后的 .gz 文件，后缀、压缩方式和响应头里的 Content-Type 要对应，解压失败等于没有内容。
- 分片里的 URL 要和页面上 canonical 指向的地址一致，否则相当于给爬虫提供了两套入口。
- 单个分片不要超过 5 万条或 50MB，超限时通常整份被忽略，而不是只丢掉多出来的部分。
- 分片地址变更后，旧地址最好保留一段时间并返回 200 或 301，避免索引里残留失效路径。
怎么验证分片到底有没有被读到
索引文件被请求，不代表分片被请求。可以按下面几步核对：
- 在服务器日志里筛选爬虫 UA，看它请求了哪些 sitemap 路径、状态码分别是多少。只有索引文件被访问、分片一条日志都没有，基本可以判断卡在索引层。
- 看搜索资源平台里的站点地图报告，提交的分片是否显示为已处理，有多少 URL 被发现。
- 用相同的 UA 模拟请求分片地址，确认返回的是 XML，而不是首页 HTML、验证页或空内容。
- 对比分片里的 URL 数量和报告里发现的数量，差距过大时回到前两步继续查。
站点地图只是发现渠道之一
站点地图的作用是告诉爬虫这里有这些 URL，它不负责保证被抓取，更不保证被收录。发现之后还要经过抓取、解析、质量判断几个环节。
- 内链是最稳定的发现渠道，重要页面应该能从首页通过几次点击到达，不要只依赖站点地图。
- 外部链接能带来发现，但新页面数量少、到达慢，适合作为补充。
- 如果用蜘蛛池之类手段提高抓取频次，要注意它影响的只是抓取请求量，对 URL 能否进入索引作用有限，页面质量、重复度和站点结构才是决定性的。
上线前可以照着走的自查清单
- 索引文件能被直接访问，返回 200 和 XML 内容。
- 每个分片地址都返回 200，内容可以正常解析。
- 分片数量与页面分组数量一致，没有漏掉某一类页型。
- 分片里的 URL 与 canonical、内链指向保持一致。
- 站点地图入口已写进 robots.txt，并在搜索资源平台提交。
- 上线后一周内看一次日志，确认分片确实被抓取过。
站点地图是辅助工具，不是收录开关。把它写对、验对，能让 URL 更容易被发现；发现之后能不能进入索引，还是要回到页面本身的质量和站点结构上。