站点 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 的组织方式固化成規范：谁负责生成、多久更新一次、新栏目上线时归到哪一片，都寫清楚。這样在排查發現問题时，就能快速判断是格式問题、覆盖問题，還是入口可達性問题。