Sitemap 是最常见的 URL 發現入口，但站点規模上去之後，把所有地址塞進一個文件通常行不通。搜尋引擎對單個 Sitemap 有明确的條數和体积上限，超出部分需要拆成多個分片，再用一個索引文件把它們串起来。分片做得好，蜘蛛能稳定地拿到 URL 清單；做得乱，反而會让一批地址長期停留在待抓队列之外。

單文件的两個硬约束

常见的處理原則是：

• 單個 Sitemap 文件最多包含 50000 條 URL；
• 未压缩狀態下体积不超過 50MB；
• 文件需要 UTF-8 编碼，压缩只能使用 gzip；
• 索引文件本身同样受這两條上限约束，一個索引可以指向多個分片。

也就是说，URL 數量到十萬級时，靠一個文件已经不太可行；到百萬級时，索引下面還要再分层，或者按业務线拆成多個索引分別维護。

索引文件解决什么問题

索引文件本身不包含頁面地址，它只列出各個分片的位置。它的價值在于给蜘蛛一個稳定入口：只需抓取一個地址，就能顺着清單找到全部分片，而不必去猜你的 URL 規律。

實践中建议把索引放在站点根目錄下的固定路径，並在 robots.txt 中声明，避免每次改版都換地址。分片地址尽量寫成绝對 URL，且不要指向會跳轉的地址——多一跳就多一次消耗。

按什么维度拆分更合理

• 按内容類型：文章、商品、栏目頁分開，各自的更新节奏不同，便于單獨维護。
• 按更新時間：把近期更新的 URL 放一個分片，歷史 URL 放另一個，蜘蛛抓近期分片的收益更直接。
• 按語言或地区：多語言站点按語言拆，避免一個分片里混着大量與目前站点無關的地址。
• 按數量切齐：如果没有明顯的业務维度，就按 2 萬到 3 萬條一個分片切，留出增長余量，不要卡着 50000 條顶格。

拆分维度没有唯一答案，判断标准是：更新频率相近、生命周期相近的 URL 放在一起，维護时才不會互相拖累。

lastmod 別乱寫

lastmod 是蜘蛛判断分片是否需要重新抓取的參考之一。如果每次生成 Sitemap 都把全部條目的時間刷成当天，這個字段就失去了意义，時間久了蜘蛛也會逐渐忽略它。更稳妥的做法是让 lastmod 跟随内容真實的修改時間，只對确實變動過的 URL 更新。

分片的價值不在于“寫了多少條”，而在于清單是否干净、時間是否可信。

几個容易踩的坑

• 分片里留着已经 404 或 301 的老地址，等于持續给蜘蛛制造無效抓取。
• 分片文件本身返回 404 或 5xx，整個索引就失去作用，需要把分片当成正式頁面来监控。
• 分片數量過多、每個分片只有几十條，會增加蜘蛛的抓取次數，收益却不高。
• 只在提交时生成一次，之後長期不再更新，新增 URL 就進不了清單。

怎么確認分片被正常抓取

可以在服務器日誌里單獨筛出 Sitemap 相關請求，观察几個指标：分片是否被訪問、返回碼是否為 200、訪問频率是否稳定、新生成的分片是否在几天内被取走。如果某個分片長期無人訪問，優先检查它是否寫進了索引文件、地址是否可以直接打開。

分片和索引只是 URL 發現的一环，它需要和内鏈结构配合：Sitemap 负责把地址交给蜘蛛，内鏈负责告诉蜘蛛這些地址值不值得反复来。两者對不上时，通常先看 Sitemap 里是否混進了不该出現的地址。