站点 URL 數量上来以後，單份 Sitemap 會撞到两個限制：协议對文件大小和 URL 條數的上限，以及蜘蛛讀取一份大文件时的處理成本。Sitemap 索引文件（sitemap index）就是為這種情况准备的：它本身不列具体頁面，只列出若干份子地图的地址。蜘蛛先讀到索引，再顺着里面的地址去取每一份子地图，URL 的發現路径就變成了两层。
索引文件不负责排序
很多人會預設索引里排在前面的子地图會被優先抓取，實际上索引文件只是提供地址清單。蜘蛛拿到清單後仍按自己的調度逻辑處理，抓取顺序受更新频率、站点整体抓取节奏、服務器响應状况等因素影响。把索引当成“優先級队列”来用，通常得不到想要的结果。
它真正的作用是让 URL 清單變得可维護：按业務或更新時間切成多份，出問题时可以只替換其中一份，而不用重寫整個文件。
常见的几種拆法
- 按内容類型拆：文章、商品、分類、标簽各一份。适合结构清晰、模板差异大的站点。
- 按更新時間拆：例如按月或按周生成子地图。更新频繁的站点用這種方式，能让新 URL 集中出現在固定的几份文件里。
- 按語言或地区拆：多語言站点常见，便于和 hreflang 一起核對。
- 按目錄或业務线拆：适合由不同团队维護内容的站点，责任邊界清楚。
如果只是 URL 多、结构單一，按更新時間拆通常最省事；如果各模块的頁面模板完全不同，按内容類型拆更容易發現遗漏。
子地图里的 lastmod 表達什么
子地图中的 lastmod 描述的是頁面内容的最後修改時間，而不是這份文件生成的時間。索引文件里也可以带 lastmod，它指的是對應子地图的更新時間。两者混淆时，蜘蛛可能反复回取一份實际没有變化的子地图。
子地图每次重新生成都會變，但里面的頁面未必變。如果每次生成都把 lastmod 刷成目前時間，這個字段的參考價值就會下降。
拆分时的操作清單
- 先統計目前可被抓取的規范化 URL 總量，再决定每份子地图放多少條，给後續增長留出余量。
- 子地图地址保持稳定，不要带随机參數或時間戳。
- 索引文件與子地图都使用绝對地址，並确保协议、域名與站点目前規范一致。
- 子地图自身不要放進 sitemap 列表里，避免索引與子地图互相引用。
- 检查 robots.txt 没有誤屏蔽子地图路径，否則索引存在、入口却取不到。
- 確認子地图返回的是 XML 内容類型，而不是被重寫規則带回首頁或返回 HTML。
容易踩的几個坑
- 索引嵌套索引：索引文件里只能放子地图，不能再指向另一份索引，多层的寫法無法被正常讀取。
- 子地图返回 404 或 5xx：索引仍在，但這一支的 URL 發現路径等于断了，日誌里通常能看到反复請求失敗的记錄。
- 列了已下线模块的子地图：文件長期返回空内容，既不提供有效 URL，也占用蜘蛛的請求次數。
- 压缩格式没声明：直接提供 .gz 文件时，要確認响應头與文件後缀一致，否則取回来也解析不了。
- 同一批 URL 出現在多份子地图：蜘蛛會看到重复入口，虽然不會直接導致問题，但會让統計和排查變复杂。
怎么驗證拆分是否有效
把服務器訪問日誌按 URL 前缀分组，观察三件事：索引文件和子地图是否被定期回取；子地图里的 URL 是否出現在後續抓取记錄中；失效子地图的請求是否長期停留在错誤狀態。如果某個模块的頁面在日誌里始终没有抓取记錄，先看它對應的那份子地图是否被成功讀取，再回头看内鏈是否提供了另一條路径。
Sitemap 索引解决的是“URL 清單怎么组织”的問题，不解决“蜘蛛一定来抓”的問题。把分片做清楚、地址保持稳定、错誤能快速定位，它就是一個可靠的基础设施；把它当成抓取量的開關，反而容易在排查时被誤導。