站点大到一定程度，把所有 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 发现的辅助通道，不是抓取配额。把它组织清楚、保持字段可信，比反复提交、频繁改动格式更有效。