Sitemap 從几十條 URL 涨到几萬條之後，問题往往不再是“要不要提交”，而是“怎么切”。一個文件塞不下，或者说塞得下但每次更新都要整份重寫，這时候就需要用到 sitemap 索引文件。它本身不列具体頁面，只列出若干個子 sitemap 的位置，蜘蛛先讀索引，再按需去讀各個分片。

先记住两個硬上限

無论是普通 sitemap 還是索引文件，都有一個通行的規模上限：單個文件最多 50000 條 URL，未压缩体积不超過 50MB。索引文件里最多放 1000 個子 sitemap。這些數字不是建议值，超過之後文件很可能被直接判為不可用，蜘蛛讀到的就是一份残缺甚至完全無效的清單。

按上限推算，一個索引文件理论上能覆盖 5000 萬條 URL。對绝大多數站点来说，真正的瓶颈不是這個總數，而是每次更新时要動多少文件。

按什么维度切片更省事

切片的维度决定了後續维護的成本，常见的三種：

• 按内容類型：文章、商品、专题、标簽頁各成一片。结构清晰，某一類出問题时容易定位。
• 按业務板块或目錄：與站内 URL 层級基本對齐，改版时改動范围可预期。
• 按更新時間滚動：比如按月份或按周分片，新片只放新增和更新的 URL，老片基本不動。

第三種對蜘蛛比較友好：更新频繁的 URL 集中在一個小文件里，蜘蛛重訪时只需要拿這一小份，不必重新拉取整個大文件。第一種和第二種更适合做全量底稿，再配合一個只含近期更新的小分片。

分片數量不是越多越好

每多一個分片，就多一次獨立的抓取請求，多一份需要维護的文件。片數太少，單文件体积大、更新代價高；片數太多，索引文件變長，蜘蛛在索引和分片之間来回跳轉的開销也會上升。一個折中的做法是把數量控制在几十到几百片之間，並且让每片的大小相對均匀，避免出現一個几萬條、另一個只有几十條的极端情况。

分片本身不會带来抓取量，它只是把 URL 线索整理得更清楚。真正影响蜘蛛是否来訪的，是站点的整体质量、更新节奏和服務器响應。

索引文件里的 lastmod 與更新顺序

索引文件中的每個子 sitemap 也可以带 lastmod。這個時間應当反映该分片内容的實际變動時間，而不是部署時間或生成脚本的執行時間。如果每次發布都把所有分片的 lastmod 刷成同一时刻，那些其實没變的分片會被反复标记為有更新，蜘蛛白跑一趟，久了反而降低對该文件的信任。

排序上，把更新最频繁、最希望被優先發現的分片放在前面，是一個低成本的习惯。它不改變抓取總量，但能在蜘蛛只讀了一部分索引时，让重要的线索先被看到。

落地时容易忽略的几点

1. 索引文件和子 sitemap 都要在 robots.txt 里声明，或者提交到搜尋平台的站長工具里，通常只声明索引文件即可，不必逐個列出子文件。
2. 索引中的 URL 必须是绝對地址，且能被正常訪問，不要出現重定向到另一個域的情况。
3. 子 sitemap 里只放返回 200、可索引的頁面，把 404、软 404、需要登入或带大量參數的頁面剔除，否則等于把無效线索递给蜘蛛。
4. 刪除分片时同步從索引文件里移除，別留一個指向 404 的空壳。
5. 生成脚本失敗要有告警，一份空的 sitemap 被提交上去，比不提交更糟。

和服務器稳定性配合看

分片拆得再合理，如果蜘蛛来取文件时服務器频繁超时或返回 5xx，它拿到的仍是不完整的資料。尤其是索引文件，一旦讀取失敗，後續分片基本不會被触發。把 sitemap 的訪問日誌單獨拉出来看响應碼和响應時間，是判断“究竟是文件寫得不對，還是服務器没扛住”的比較直接的办法。

归根结底，分片策略要回答的是一個問题：当你只想让蜘蛛看一小部分文件时，能不能精准地把那部分挑出来。能做到這一点，索引文件才算用對了。