站点规模上来之后，一份 Sitemap 往往装不下全部 URL。这时会用索引文件把多个分片串起来。分片怎么切、索引怎么写、更新时动哪一份，会直接影响蜘蛛读取的效率，也影响后续的核对工作。
先看清两个硬性上限
单个 Sitemap 文件有两个常见限制：URL 条数不超过 5 万条，未压缩体积不超过 50MB。超过就得拆。拆分之后需要一个索引文件，把各个分片的地址列出来，通常命名为 sitemap.xml，而真正的分片用 sitemap-1.xml 这类名字。
分片文件可以是 gzip 压缩的，但索引文件本身不要压缩。这个细节经常被忽略，结果索引读不出来，前面拆得再整齐也没有意义。
索引文件的写法与常见错误
- 索引里只放分片地址，不要把普通页面 URL 混进去。索引是“目录的目录”，混放会让解析层级变得混乱。
- 不要在一个索引里指向另一个索引。索引嵌套不是标准做法，容易出现读取中断。
- 分片地址要与站点同域，跨域声明通常会被忽略。
- robots.txt 里如果声明 Sitemap，一般写索引文件的地址就够了，不必把每个分片都列一遍。
另外，分片地址写错、文件被删、或者返回 404，都会让整批 URL 失去声明入口。这类问题在服务器日志里表现为对分片文件的请求返回非 200，值得定期扫一遍。
按什么维度切分片
切分方式没有统一答案，但目标一致：让“更新”集中在少数几个文件里。常见的几种切法：
- 按目录或栏目切：适合内容板块清晰、更新节奏不同的站点。改版某个栏目时，只需要动对应的分片。
- 按语言或地区切：多语言站点常用，便于分区域核对。
- 按更新频率切：高频更新的页面单独一份，低频的另放，减少蜘蛛反复读取大文件。
- 按时间或 ID 段切：适合内容持续增长、历史内容基本不动的站点。
如果每天新增几千条 URL，就把所有分片都重写一遍，索引和分片的最后修改时间会不断变化，蜘蛛需要重新读取的量也随之上升。让不变的分片保持原样，是拆分最实际的价值。
lastmod 用不用，怎么用
lastmod 的作用是告诉蜘蛛这个地址内容有变动。用它的前提是时间戳真实。如果每次生成分片都把 lastmod 刷成当天，短时间内可能看不出问题，时间一长，这个字段的参考价值就没了，蜘蛛可能干脆忽略它。
真实的时间戳才有意义。把 lastmod 当成“提醒工具”而不是“刷新按钮”，自己核对日志时也更方便。
还有一种情况：页面内容没变，但因为模板改动导致整批 lastmod 变化。这类批量变化会在抓取日志里留下一片密集访问，核对时容易误判为大规模更新。
用抓取日志核对分片
分片写好并提交之后，可以通过日志做几项基础核对：
- 分片文件本身被访问的频率，是否和你的更新节奏大致对应。
- 分片请求的响应码，是否长期稳定在 200。
- 从分片被读取，到分片内 URL 被访问，中间隔了多久。
- 哪些分片几乎没有被读取过，是否存在地址写错或长期未更新的情况。
需要说明的是，声明和读取不等于收录。分片被读了，只说明入口被发现；页面是否进入索引，还要看内容质量、重复度、站点整体表现等因素。分片的作用是把 URL 稳定地、可核对地暴露出来，而不是替代其他工作。
一套简单的维护清单
- 确认索引文件本身未被压缩，且能正常打开。
- 每个分片控制在限制以内，文件名与地址可预测。
- 更新时只重写有变化的分片，其余保持不动。
- lastmod 只在内容实际变化时更新。
- 定期看分片请求的响应码与访问频率。
- 分片结构发生变化时，同步检查 robots.txt 中的声明地址。
把这些基础工作做稳，后面排查“URL 为什么没被发现”之类的问题时，至少可以先排除掉 Sitemap 这一层的不确定性。