很多站点把 Sitemap 索引文件当成一次配置就長期不管。實际上，搜尋蜘蛛讀取 Sitemap 时是先請求索引文件，再按其中的 loc 逐條拉取子地图。只要索引文件里的某條連結失效、子地图压缩格式異常，或者單文件超過限制，後續一批 URL 就可能長時間不被發現。
一、先確認蜘蛛是否真的請求了子地图
不要只看服務器訪問日誌里有没有 Sitemap 索引的 200。更實用的做法是篩選蜘蛛 UA，观察它是否繼續請求子地图路径。
- 索引文件被請求，但子地图没有任何請求记錄：優先检查 loc 是否可公開訪問、是否被 robots.txt 拦截、是否返回 3xx 或 4xx。
- 子地图只被請求一两次就停止：可能是响應超时、返回内容不是 XML、或者文件過大導致讀取中断。
- 子地图請求集中在舊分片，新分片從未出現：检查索引文件是否更新、CDN 是否缓存了舊版本。
如果索引文件走了 CDN，務必確認缓存刷新後蜘蛛看到的是最新内容，而不是舊索引。
二、索引文件本身的常见問题
Sitemap 索引文件的格式並不复杂，但细节容易出错。
- 路径與域名不一致：索引中 loc 使用了測試域名、带端口的内網地址，或者 http 與 https 混用，蜘蛛無法按预期抓取。
- 编碼問题：XML 声明、字符集與實际内容不一致，中文 URL 或特殊字符可能解析失敗。
- 大小與數量超限：單個 Sitemap 文件通常有 URL 數量和未压缩体积限制，索引文件也有子地图數量限制。超出後可能被截断或直接忽略。
- 压缩與 Content-Type 不匹配：.gz 文件返回 text/html 或 application/octet-stream，部分抓取端會放弃解析。
三、子地图分片與讀取顺序排查
子地图分片不合理，會直接增加讀取失敗的概率。
- 把大量 URL 塞進一個文件，响應体過大，蜘蛛可能只讀完前面一部分。
- 分片按時間滚動生成，但舊分片被刪除後索引仍引用，形成死鏈。
- 子地图内 URL 與索引声明不一致，比如索引说 5 萬條，實际只有几千條。
- 動態生成子地图耗时過長，首字节延迟高，蜘蛛容易放弃。
建议把子地图控制在合理体积内，按内容類型或栏目拆分，並确保每個分片都能獨立打開、返回正确 XML 头。
四、一個可执行的排查顺序
- 用蜘蛛 UA 或日誌篩選，確認索引文件與子地图的請求记錄。
- 直接訪問索引文件，检查 HTTP 狀態、Content-Type、是否被重定向。
- 逐條打開索引中的子地图 loc，確認均可訪問且返回有效 XML。
- 检查子地图内 URL 數量、格式、域名是否一致，避免混入站外或參數爆炸連結。
- 對比 CDN 與源站内容，排除缓存舊索引或舊分片。
- 观察随後几天的抓取日誌，看子地图請求是否恢复、URL 發現量是否回升。
五、日常维護建议
Sitemap 不需要频繁重寫，但需要和站点结构同步。新增栏目、改版路径、切換域名时，索引文件和子地图應一起更新。若站点使用自動生成方案，建议保留一個简單的手動检查入口，方便快速驗證索引、分片和压缩是否正常。
最後提醒：Sitemap 只是 URL 發現的辅助入口，不能替代内鏈和導航。蜘蛛是否抓取、何时抓取，仍受站点质量、服務器稳定性和抓取预算影响。把索引和子地图排查清楚，可以减少“明明提交了却長期不出現”的低級問题。