站点大到一定程度，把所有 URL 塞進一個 Sitemap 文件，問题往往不是蜘蛛看不看，而是文件本身难维護、难定位，出了問题也不知道是哪一類頁面受影响。把清單拆成索引加多個子文件，是 URL 發現這條鏈路上比較實用的一步。
為什么要拆：先看两條硬上限
單個 Sitemap 文件有明确的邊界，越過之後不是抓得慢一点，而是文件可能被判為無效，里面的 URL 一條都進不了發現队列。
- 單個文件最多 50,000 條 URL。
- 未压缩体积不超過 50MB，用 gzip 上传时，判断标准仍是解压後的大小。
- 索引文件本身最多指向 50,000 個子 Sitemap。
按什么维度分片
常见的做法是让每個子文件對應一類邊界清晰的内容，出問题时能快速定位范围。
- 按内容類型：文章、商品、分類、专题各一份，便于對照日誌判断哪一類没被取走。
- 按語言或地区：多語言站点分開，與各自的目錄结构對應起来。
- 按更新频率：更新频繁的放一份，長期不變的归档内容放另一份，减少整份文件的重复抓取压力。
分片粒度不必太细。几十個子文件通常够用，拆成几百個反而增加蜘蛛讀取索引文件的次數。
索引文件怎么寫、放在哪
索引文件用 sitemapindex 结构，每一項指向子 Sitemap 的完整绝對地址，且應與索引文件同域。robots.txt 里一般只声明索引文件這一條，蜘蛛會顺着它去取各個子文件。
清單寫得再全，也只是告诉蜘蛛這里存在一個地址；是否抓取、什么时候抓取，仍由蜘蛛自己判断。
lastmod：寫真的，別批量刷
lastmod 是清單里少數會被參考的字段，但前提是它可信。
- 只寫内容發生實质變化的日期，改错別字、換广告位不算。
- 用带时区的 ISO 8601 格式，例如 2024-05-20T08:30:00+08:00，避免按 UTC 誤判。
- 全站批量刷新 lastmod，短期可能带来回爬，長期會让這個字段失去參考價值。
- changefreq 與 priority 目前基本被忽略，不必在這两個字段上花太多精力。
清單里该放哪些 URL
- 只放返回 200 且允许被索引的規范地址。
- 不放 301、302 跳轉地址，也不放 noindex 頁面和 404 頁面。
- 與頁面 canonical 保持一致，避免清單里一個地址、頁面里指向另一個地址。
- 篩選、排序等參數頁預設不放，除非它确實有獨立内容和搜尋需求。
- 分頁的後續頁可以放，但不比内容頁更重要，數量大时要有取舍。
清單文件自己也要能稳定返回
很多站点把清單当成静態资源随手一放，结果所在目錄响應慢、偶發 5xx，或者被 WAF 誤拦。清單取不到，後面所有 URL 都無從發現。几個基本要求：
- 响應稳定，尽量走缓存或 CDN，降低回源压力。
- 不要用多跳重定向引導到清單文件，多余的跳轉會拖慢處理。
- 压缩上传没問题，但解压後要能被正常解析，不出現编碼错誤。
- 更新频繁的子清單可以设較短缓存，归档類清單设較長缓存。
怎么確認清單真的起了作用
可以按三步检查：一是看搜尋後台的 Sitemap 报告，確認文件被讀取、解析成功的 URL 數量是否符合预期；二是翻服務器日誌，看蜘蛛是否按索引文件逐條請求子清單，請求频率和狀態碼是否正常；三是抽样抓取清單里的若干 URL，核對狀態碼、canonical 與清單记錄是否一致。三者對不上时，先排查清單本身，再排查頁面。
Sitemap 是 URL 發現的辅助通道，不是抓取配額。把它组织清楚、保持字段可信，比反复提交、频繁改動格式更有效。