站点刚上线时，一份 Sitemap 通常就能装下全部 URL。等到栏目铺开、商品或文章累积到几千上万条，单文件里的记录越来越长，更新一次就要整体重新生成，蜘蛛每次拉到的还可能是一份正在变化中的数据。这时候更省力的做法，是把 Sitemap 拆成若干分片，再用一个索引文件把它们串起来。

索引文件不列 URL，只列分片

Sitemap Index 本身不包含具体地址，它列出的是一批子 Sitemap 的位置和各自的最后修改时间。蜘蛛先读索引，再按需要去读对应分片。这样做的直接好处有两点：

• 单个文件体积可控，生成、缓存和传输都更轻；
• 更新只影响少数分片，lastmod 传达的信号更接近真实情况。

常见的单文件上限是 5 万条 URL、未压缩 50MB，多数站点远没到这个量级，但按栏目拆分依然值得做，理由是维护成本，而不是容量限制。

分片按什么维度切分

常见的切法有三种，可以按站点实际情况选一种或混用：

• 按栏目切：商品、文章、专题各一份，出问题时排查范围小，也方便单独重新生成；
• 按时间切：按发布时间倒序分片，新内容集中在最新分片，历史分片基本不动；
• 按站点或语言切：多语言、多子站的场景，每套语言一份，避免互相牵扯。

无论怎么切，都要保证同一批 URL 不会同时出现在多个分片里。同一个地址在索引中重复出现，等于让蜘蛛反复处理同一份清单，也容易让抓取配额浪费在无意义的比对上。

lastmod 是最容易写错的字段

不少站点每次生成 Sitemap 都无条件把 lastmod 更新为当前时间，看起来数据很新，实际让这个字段彻底失去参考价值。更稳妥的做法是：只在页面内容真的发生变化时更新该条记录，格式统一使用带时区的完整日期时间，不要一会儿写日期一会儿写时间戳。

分片文件自身的 lastmod 同理。如果索引里每个分片的修改时间天天都在变，蜘蛛读索引的成本就上去了，而分片内容其实没什么变化。

哪些地址不该放进目录

• 已经返回 404、410 的失效地址；
• 还在做 301、302 跳转的旧地址，应当写跳转后的最终地址；
• 页面本身带 noindex 的地址，放进 Sitemap 与页面信号自相矛盾；
• 需要登录、蜘蛛拿不到正文的页面；
• 筛选、排序、跟踪参数组合出来的地址，这类应通过 URL 规范化收口。

Sitemap 替代不了内链

Sitemap 解决的是“告诉蜘蛛这里存在一个地址”，内链解决的是“这个地址在站点结构里处在什么位置、有多重要”。只靠 Sitemap 存在、站内没有任何入口指向的页面，抓取频次通常明显偏低，更新也不容易被及时发现。合理的做法是让两者互相印证：Sitemap 覆盖全集，内链负责把重要页面串成可走通的路径。

传输与响应也要照顾到

分片文件动辄几百 KB 到几 MB，开启 gzip 压缩、设置合理的缓存头，能减少蜘蛛每次重复下载的开销。同时确认 Sitemap 文件本身返回 200 且是 XML 内容类型，不要被安全策略、登录跳转或 CDN 的缓存规则拦在外面。索引和分片都放在稳定可访问的路径下，比放在临时目录更省事。

提交之后看什么

观察服务器日志里对 Sitemap 文件本身的请求，以及对分片内 URL 的抓取情况。如果索引被反复读取，但分片很少被访问，多半是索引中的 lastmod 一直在变，或者分片地址本身不稳定。反过来，如果分片被读了却迟迟没有对应的页面抓取，就要回到内链和页面本身的质量上找原因。

把 Sitemap 当成一份需要长期维护的目录，而不是一次性提交的动作。分片清晰、lastmod 可信、内链走得通，这份目录才真正发挥作用。