当一個站点的 URL 從几百條涨到几萬條，單個 Sitemap 文件很快就不够用了。這时候真正影响 URL 發現的，往往不是“有没有提交 Sitemap”，而是這份清單被拆成了什么样、放在哪里、蜘蛛能不能顺畅地一個個讀完。

先看清單文件的两個硬上限

主流搜尋引擎對單個 Sitemap 文件有两個限制：URL 條數不超過 50,000 條，未压缩体积不超過 50MB。任意一條触顶，超出的部分就會被忽略，而不是报错提示你。所以当 URL 規模接近上限时，繼續往同一個文件里追加内容，等于把後面的地址直接丢掉。

另外還有一條容易被忽略的：同一個目錄下的文件數量、生成耗时、传輸体积，都會影响服務器在蜘蛛集中請求时的响應表現。

Sitemap 索引文件解决的是什么問题

Sitemap 索引（Sitemap index）本身不是 URL 清單，它只是一份“清單的清單”，里面列出若干個 Sitemap 文件的地址和最後修改時間。蜘蛛先取索引，再按索引去取各個子文件。

它带来的實际變化有三点：

• 單個文件的容量压力被分散，不會因為一個文件超限而整体失效；
• 可以按内容類型分別提交，某個分片出错不影响其他分片；
• 更新频率高的分片可以频繁重建，低频分片保持不動，减少生成開销。

分片怎么切才合理

切分逻辑没有唯一答案，但要避免两種极端：切得太碎（几百個只有几十條 URL 的文件）會增加蜘蛛的請求次數；切得太大又回到容量問题。常见的做法是按内容類型和更新节奏来分：

• 按内容類型：文章、商品、分類、专题各一個分片，便于單獨观察抓取覆盖情况；
• 按更新频率：每日更新的内容放一個分片，長期稳定的頁面放另一個分片；
• 按語言或地区：多地区站点按目錄或子域拆分，避免混在一起互相干扰。

每個分片保持在几千到两三萬條之間比較從容，既留有余量，也不會让索引文件指向過多的子文件。

索引文件本身的寫法

索引文件里每一條记錄包含子 Sitemap 的地址和 lastmod。這里的 lastmod 指的是该文件内容的最後修改時間，不是里面某一條 URL 的修改時間。時間戳频繁跳動而内容没變，會让蜘蛛對這個字段的參考價值打折。

索引文件的地址通常放在 robots.txt 的 Sitemap 行里，而且這里只需要寫索引地址，不必把每個子文件都列一遍。重复列出反而容易让人誤以為有多個入口。

分片之後容易踩的坑

• 分片里的失效 URL 不清理：已经 404 或 301 的地址長期留在 Sitemap 里，會持續消耗抓取請求；
• 新舊分片同时存在：改版後生成了新文件却忘了移除舊文件的引用，蜘蛛會抓到两份重复清單；
• 子文件動態生成太慢：每次請求都要查全表，蜘蛛並發取几個分片时，响應時間就會明顯上升；
• 把參數頁、篩選頁全塞進去：這類地址數量容易失控，把真正需要發現的頁面挤到後面。

比較稳妥的做法是让 Sitemap 文件静態化或加缓存，把生成過程與线上請求解耦，保證蜘蛛取文件时的响應稳定。

索引不是唯一入口

即使 Sitemap 拆分得再整齐，它也只是 URL 發現的辅助通道。蜘蛛的主要路径仍然是連結：從首頁、栏目頁、相關推荐一步步走到目标頁。Sitemap 能告诉蜘蛛“這些地址存在”，但一個頁面在站内没有任何内鏈指向它，被抓取和评估的机會依然有限。

所以拆分 Sitemap 的同时，值得同步检查一件事：這些分片里有多少 URL 是站内連結可以走到的。两者差得越遠，說明站点结构還有补的空間。

一個简單的自查清單

1. 索引文件里的子 Sitemap 地址是否都能正常返回 200，且返回的是 XML；
2. 每個子文件的條數是否遠离 50,000 上限，体积是否遠离 50MB；
3. 索引和子文件里的 lastmod 是否和真實修改時間對得上；
4. robots.txt 中引用的 Sitemap 是否為索引地址，且只出現一次；
5. 分片中是否混入了參數頁、已刪除頁、其他站点镜像的地址；
6. 蜘蛛集中抓取這些文件时，服務器响應時間是否仍在正常范围。

Sitemap 分片的本质，是把一份長長的清單變成一份可维護的清單。它不會让頁面自動被收錄，但能让蜘蛛少走冤枉路，把抓取時間花在真正值得讀的地址上。