站点 URL 数量超过几万条之后，单文件 Sitemap 就不再合适，通常需要拆成多个子文件，再用索引文件（sitemap index）串联起来。但不少站点只是把文件拆开，没有核对拆分之后蜘蛛是否还能完整走一遍，于是出现“提交了却长期没被发现”的情况。下面从组织方式和核对顺序两个角度梳理。
分片之后发生的三个实际变化
- 入口数量增加：蜘蛛不再只读一个文件，而是先读索引，再逐个展开子文件，链路变长。
- 更新节奏分离：不同子文件的更新时间不再一致，回访判断要按片来看，而不是按整站看。
- 单点影响放大：某一片地址写错或返回异常，影响的是这一片里的全部 URL，而不是零星几条。
索引文件本身也是入口
索引文件通常放在站点根目录，命名和 robots.txt 里的声明要保持一致。常见问题是索引文件返回 200 但内容为空，或者子文件地址经过一次 302 跳转，蜘蛛跟随之后不一定继续展开。核对时应把索引文件当成普通页面看待：状态码、内容类型、字节大小都值得看一眼。
分片粒度与更新频率的匹配
- 更新频繁的栏目单独成片，配合较新的 lastmod，便于体现变化。
- 历史归档类 URL 合并到少量分片，本身变动少，没必要频繁重写。
- 各片的 URL 数量尽量保持在同一量级，避免个别分片过大拖慢整体读取。
- 子文件数量超出单层索引能承载的范围时，考虑分层组织，而不是继续堆叠。
一套可执行的核对流程
- 直接请求索引文件与各子文件，确认均返回 200 且内容是合法 XML。
- 抽查子文件中的 URL，与站内实际可访问地址比对，清理已下线或长期重定向的条目。
- 统计每片的条目数与字节数，确认没有超过格式约定的上限。
- 在服务器日志中筛选蜘蛛对 Sitemap 路径的请求，观察子文件是否被逐个抓取。
- 把日志里被抓取的 URL 集合与 Sitemap 中的集合做差集，差异部分就是待排查的发现盲区。
容易被忽略的细节
- 压缩格式：gzip 能减小传输量，但要确认解压后仍是合法 XML，且响应头与文件后缀一致。
- 编码处理：包含非 ASCII 字符的 URL 需要正确转义，否则蜘蛛拿到的地址与实际地址对不上。
- 时间字段：索引文件里的 lastmod 应与子文件的实际更新时间一致，长期不更新会让回访判断失真。
- 访问链路：Sitemap 路径被安全策略拦截，或 CDN 缓存了旧版本，都会让蜘蛛读到过期内容。
分片的目的，是让蜘蛛用有限次数的请求覆盖尽量多的有效 URL，而不是把文件切小就结束。拆分之后如果不做覆盖核对，等于把发现工作交给了运气。
与内链、日志的交叉验证
Sitemap 只是发现渠道之一。核对时可以取一小批只出现在 Sitemap、站内没有内链指向的 URL，观察它们在日志中的抓取情况：如果长期没有请求，说明单纯依赖 Sitemap 的发现效率有限，需要在列表页或相关页面补上可达入口。反过来，如果某批 URL 在日志中频繁被抓取，但 Sitemap 里缺失，说明分片没有跟上内容增长速度，需要重新整理。
建议把 Sitemap 的组织方式固化成规范：谁负责生成、多久更新一次、新栏目上线时归到哪一片，都写清楚。这样在排查发现问题时，就能快速判断是格式问题、覆盖问题，还是入口可达性问题。