站点 URL 数量到一定规模后，单个 Sitemap 文件往往装不下所有入口，于是会拆成「索引文件 + 若干分片」的结构。索引文件本身只列出分片地址，真正的 URL 放在分片里。这种结构看起来更整齐，但多了一层间接关系，出问题时也更难发现：索引文件正常返回 200，分片却可能少提交、重复提交，甚至根本没被抓取。
条目上限与文件体积的边界
常见约定是单文件不超过 5 万条 URL、未压缩体积不超过 50MB。这两条是硬边界，越界之后解析器可能直接放弃整个分片，而不是只丢掉多出来的部分。所以分片切分要留余量，比如按 4 万条或 40MB 来切，避免后续追加 URL 时刚好碰到上限。
同时要注意分片数量本身。索引文件虽然有分片数量上限，但对多数站点来说更现实的问题是分片过细导致调度分散：每个分片只有几十条 URL 时，抓取方需要额外请求索引和分片，单位成本反而更高。分片粒度建议按栏目或按更新时间切，而不是按导出批次随意切。
索引与分片不一致的常见形态
索引未同步
新增栏目或批量发布后只更新了分片，忘记把新分片地址写进索引文件。分片存在但无人引用，等价于这些 URL 没有通过 Sitemap 被声明出来。
分片被删但仍留在索引里
反过来，索引还指向已经下线的分片地址，请求返回 404 或 410。反复出现这种情况，会让抓取方对整份 Sitemap 的可用性打折。
lastmod 口径不统一
有的分片写内容修改时间，有的写文件生成时间，有的每次导出都刷新成当前时间。口径混乱会让回访调度难以判断哪些分片值得优先处理。至少在同一份 Sitemap 内保持一致。
分片可访问性被忽略
分片路径如果落在 robots.txt 的 Disallow 范围内、被基础访问控制拦截、或需要登录才能访问，都会导致列表无法读取。索引文件可访问，不等于分片可访问，这一点需要单独验证。
建议的核对顺序
- 直接请求索引文件，确认状态码、Content-Type 与可解析性。
- 从索引中提取全部分片地址，逐个请求，记录状态码与响应体积。
- 统计每个分片的 URL 条数，找出明显偏小或偏大的分片。
- 把分片里的 URL 与站点实际可访问 URL 做抽样比对，观察是否有分类整体缺失。
- 检查分片路径是否被 robots.txt 或访问控制规则影响。
- 核对 lastmod 的生成逻辑，确认同一份文件内口径一致。
- 确认压缩分片的编码声明与实际编码匹配，避免解析失败。
验证入口是否真的进入抓取范围
Sitemap 只是入口声明，不能代替实际抓取。判断分片是否有效，还是要回到服务端日志：观察这些分片地址本身有没有被请求，以及分片内的 URL 是否出现访问记录。如果索引被请求、分片未被请求，问题多半在分片自身的可访问性；如果分片被请求、其中的 URL 长期没有访问记录，则要结合内链结构、canonical 指向和页面状态一起看。
- 索引文件与分片的请求频次是否匹配
- 分片内 URL 的命中情况是否随分片不同而明显分化
- 是否存在只在 Sitemap 出现、内链中完全找不到的孤立 URL
把 Sitemap 当作一份需要持续维护的清单，而不是一次导出的产物：每次结构变动后，索引、分片、lastmod 三处都要一起核对。
索引加分片的结构本身没有问题，问题往往出在维护节奏上。只要把分片的生成、收录进索引、可访问性验证固定成同一套流程，大部分入口遗漏都能在发布阶段被发现，而不是等日志里出现长期空白才回头排查。