站点規模小的时候，一個 sitemap.xml 就能装下所有 URL。当頁面數量涨到几萬條，單文件會先撞上格式限制，再撞上加载時間。這时候真正需要處理的不是「要不要繼續用 sitemap」，而是把它拆成多個文件，再用一個索引文件把它們串起来。

單文件 sitemap 的两條硬上限

按通用协议约定，單個 sitemap 文件最多容纳 50000 條 URL，未压缩体积不超過 50MB。這两個數字是格式层面的约束，不是建议值。文件超過上限後，抓取方可能只讀取前面一段，後面的 URL 就停在队列之外。

即使没到上限，几萬條 URL 塞在一個文件里，單次請求的响應時間也會變長。抓取方讀取變慢，URL 發現的节奏自然被拖住。

sitemap index 解决什么

sitemap index 本身不是 URL 列表，而是一份文件清單。它只包含各個分片 sitemap 的地址和最後修改時間。抓取方先讀索引，再按需去取分片，压力被摊開，單個文件的体积也回到可控范围。

索引文件的作用是分流，不是替代。它让抓取方知道有哪些分片，剩下的取舍仍由對方决定。

分片按什么维度切

切分方式没有唯一答案，但有一種原則值得遵守：让每個分片内部有共同特征，方便以後單獨排查。

• 按目錄或内容類型：文章、商品、专题、帮助文档各占一個分片，出問题时能快速定位是哪一块。
• 按更新時間：更新频繁的頁面單獨放一個分片，让它的 lastmod 變化更集中，也更容易被反复讀取。
• 按語言或地区：多語言站点的各語言目錄分開，避免一個分片里後缀混杂。

分片數量不必太少，但也不宜碎到几百個。几十個分片通常就够用，過多會增加索引文件本身的讀取次數。

索引文件上容易犯的错

1. 索引文件里混入了普通頁面 URL，格式不對，解析直接失敗。
2. 分片地址寫成相對路径，抓取方無法拼接。
3. 分片返回了 404 或需要登入才能訪問，索引里的連結形同虚设。
4. 分片内容更新了，索引里的時間字段却一直没動。

压缩與提交

分片文件可以用 gzip 压缩，通常按 .xml.gz 命名。压缩後传輸量下降，抓取方讀取更快，但要注意响應头里的 Content-Type 與文件名一致，避免解碼阶段出错。

索引文件提交之後，不等于里面的分片都會被取走。可以在抓取日誌里观察分片的請求频率，判断哪些分片被讀取過、哪些一直没動静。一個分片長期無人訪問，先检查它在索引里的位置和自身是否可訪問。

它替代不了内鏈

sitemap 提供的是 URL 清單，不提供頁面之間的路径關系。一個只出現在 sitemap、任何頁面都不連結的 URL，即使被發現，也很难判断它在站内處于什么位置。

更稳妥的做法是两條路並行：sitemap 负责把清單交出去，内鏈负责给出真實的進入路径。巡检时可以對一下两邊數量——如果某個目錄的頁面大量只存在于 sitemap，說明内鏈结构出現了断层。

最後提醒一句：分片是為了让發現過程更顺，不是為了让所有 URL 立刻被抓取。文件拆得再整齐，能不能被訪問、值不值得抓取，仍取决于頁面本身和服務器狀態。