当站点 URL 數量增長到几千甚至几十萬，單個 Sitemap 文件就很难承载，分片和索引文件随之成為必须维護的基础设施。切分本身並不复杂，麻烦的是分片之後如何保持一致、如何與内鏈和抓取日誌對得上。

什么时候需要分片

常規做法是單個 Sitemap 不超過 5 萬條 URL、未压缩体积不超過 50MB，超過就拆成多個子地图，再用一個索引文件（sitemapindex）把它們列出来。索引文件本身也有類似的條數上限，理论上可以再套一层，但實际运营中很少需要超過两級。

判断是否要分片，看的不是感觉上的多與少，而是實际的生成和维護成本：一次性生成十萬條 URL 的 XML 會让脚本跑很久，出错後重跑代價高；分片之後可以按模块增量更新，某個文件出問题也只影响那一部分。

分片维度的選擇

常见的切分方式有几種，各有取舍：

• 按内容類型：文章、商品、分類、标簽各一份。好處是不同類型的更新频率和抓取價值可以分開管理。
• 按更新時間：热資料單獨一份，歷史資料归档成几份。适合新闻、电商這類时效性强的站点。
• 按 ID 区間或數量：最机械，结构统一的大站用起来省事。

如果站点同时存在需要频繁重抓的 URL 和基本不再變化的 URL，按内容類型加更新時間组合切分通常更好用，因為蜘蛛對不同子地图的重訪节奏本来就不一样。

索引文件保持简洁

索引文件里每條记錄只需要 loc 和可選的 lastmod，不必塞入額外字段。文件小、结构稳定，比堆砌信息更有價值。索引文件一般放在根目錄，並在 robots.txt 中声明位置。

更新节奏與一致性

分片之後最容易出問题的是更新不同步：主站已经删掉的 URL 還留在舊子地图里，新上线的頁面進了索引却没有归入任何子地图。建议把生成流程做成可重复执行的定时任務，每次重新生成全部受影响的分片，而不是在舊文件上手動追加。

几個常见的核對点：

1. 子地图里的 URL 是否都能返回正常狀態碼，是否還残留已被 404 或 410 處理的歷史連結。
2. lastmod 是否来自真實的内容變更時間，而不是每次生成时统一刷新成目前時間。统一刷新等于把這個字段作废。
3. 索引文件里列出的子地图地址是否都可訪問，压缩文件（.gz）的编碼和 Content-Type 是否正确。
4. 分片數量變化後，索引文件是否同步更新，舊的子地图地址是否已经被移除而不是繼續返回舊内容。

與抓取日誌的交叉核對

Sitemap 只是告诉蜘蛛有哪些 URL，它並不保證這些 URL 會被抓取。要判断分片是否有效，得回到抓取日誌：統計每個子地图中被抓取的 URL 比例、抓取間隔、狀態碼分布。如果某個分片長期没有抓取记錄，可能是文件過大、内容價值偏低，也可能是它列出的 URL 在内鏈中几乎没有入口。

這时候可以做一個简單對比：把 Sitemap 里的 URL 集合與站内可点击到達的 URL 集合求差集。差异部分如果數量很大，說明站点對 Sitemap 的依赖過重；如果差异很小，Sitemap 更多是辅助作用，重点應该放在内鏈结构本身。

分片不是把文件切小就完事，它是让 URL 清單可维護、可核對的一種组织方式。任何一份子地图，你都應该能回答三個問题：里面有哪些 URL、它們現在是什么狀態、上一次真正更新是什么时候。

最後提醒一点：Sitemap 的提交和更新属于基础工作，它能改善蜘蛛發現 URL 的效率，但站点能否被正常抓取和展示，取决于内容质量、内鏈结构和服務器可用性等综合因素，不宜把全部希望压在這份文件上。