站点 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 三處都要一起核對。
索引加分片的结构本身没有問题，問题往往出在维護节奏上。只要把分片的生成、收錄進索引、可訪問性驗證固定成同一套流程，大部分入口遗漏都能在發布阶段被發現，而不是等日誌里出現長期空白才回头排查。