当站点 URL 數量達到几萬甚至更多时，單個 Sitemap 文件很容易触到條數和体积的上限。這时繼續往一個文件里塞，不僅维護困难，搜尋蜘蛛讀取时也可能只拿到一部分。更稳妥的做法是用 Sitemap 索引文件把多個子地图组织起来，让 URL 發現入口保持清晰。
Sitemap 索引文件解决什么問题
常见的 XML Sitemap 有两條硬限制：單個文件最多 5 萬條 URL，未压缩体积不超過 50MB。超過之後，就需要拆成多個子地图。索引文件本身不直接列 URL，它只负责告诉搜尋蜘蛛：這個站点有哪些子地图、它們分別在哪里。
可以把索引文件理解成一本總目錄。搜尋蜘蛛先讀總目錄，再按顺序去讀各個子地图。這样即使站点有几十萬條 URL，也能通過一個固定地址被發現。
拆分维度：按什么逻辑切分
分片不是随便切，最好和站点本身的结构對齐。常见的拆分方式有几種：
- 按栏目或频道：新闻、商品、帮助中心各自一個子地图，邊界清楚，更新频率也接近。
- 按内容類型：文章頁、列表頁、标簽頁分開。不同類型頁面的抓取價值不一样，放在一起反而不便观察。
- 按更新時間：把最近更新的内容單獨放一個子地图，方便搜尋蜘蛛優先回訪。
- 按 URL 數量均匀切：如果站点结构比較平，也可以單纯按條數切，每個子地图控制在几千到一两萬條，便于排查。
無论選哪種，子地图的地址一旦确定就尽量保持稳定。频繁更換分片地址，等于把已经建立的 URL 發現入口拆掉重建，搜尋蜘蛛需要重新适應。
索引文件的基本寫法與注意点
索引文件的根标簽是 sitemapindex，里面每個 sitemap 子項包含一個 loc，也就是子地图的完整地址。可選的 lastmod 用来标注该子地图最後修改時間，但不要為了“顯得新鲜”而随意改動。
有几個细节容易被忽略：
- 索引文件里不要再嵌套另一個索引文件，搜尋蜘蛛通常不希望你绕来绕去。
- 子地图地址必须是绝對地址，並且和站点协议、主机名保持一致。
- 子地图如果啟用了 gzip 压缩，索引里的地址仍然寫未压缩前的 .xml 地址即可。
- 索引文件本身也要能被正常訪問，返回 200 狀態碼，不要被 robots.txt 誤拦。
分片之後，URL 發現還要靠内鏈
Sitemap 是补充型入口，不是唯一入口。分片做得再整齐，如果頁面之間没有内鏈，搜尋蜘蛛讀完地图後仍然可能只抓取一部分。比較稳的做法是：重要頁面既出現在合适的子地图里，也能從栏目頁、列表頁或正文連結被点到。
另外，子地图里的 URL 應当是可抓取的規范地址。如果里面混入大量带追踪參數、會话 ID 或重定向地址，分片反而會把抓取队列搞乱。定期抽查子地图内容，比單纯增加分片數量更有用。
服務器响應與分片维護
子地图數量多，對服務器稳定性的要求也會提高。如果某個子地图返回 5xx 或超时，搜尋蜘蛛這次可能就跳過它。如果索引文件本身訪問不稳定，整批 URL 發現入口都會受影响。建议把 Sitemap 文件当成静態资源来對待，做好缓存，避免每次請求都動態生成。
排查时可以從外到内：先確認索引文件能正常打開，再逐個检查子地图是否返回 200，最後看子地图里的 URL 是否真實可訪問。哪一层断了，就先修哪一层。
一個简單的检查顺序
- 索引文件地址是否固定、可訪問、协议主机名统一。
- 子地图是否按栏目或類型拆開，單個文件没有超限。
- 每個子地图里的 URL 是否返回 200，是否包含規范地址。
- 重要頁面是否有内鏈支撑，而不是只依赖 Sitemap。
- 服務器日誌里，索引文件和子地图是否被稳定抓取。
把這些环节理顺之後，Sitemap 索引與分片才能真正承担起大站点 URL 發現入口的角色，而不是變成一份没人维護的清單。