Sitemap 本身不复杂，难的是站点规模上来之后怎么维护。一个栏目几百个 URL 时，随便生成一个 XML 文件就够用；当 URL 数量到了几万甚至几十万，单个文件迟早会撞上协议上限，抓取入口就需要重新设计一遍。

先确认单文件的上限

Sitemap 协议对单个文件有明确限制，超出部分不会被处理：

• 一个文件最多 50,000 条 URL；
• 未压缩状态下不超过 50MB；
• 一个文件里的 URL 应属于同一站点，跨站需要分开。

这两个数字是硬约束，不是「差不多就行」。超过之后，文件可能被截断读取，后面的 URL 就等于没提交。

索引文件是给蜘蛛的目录

URL 数量超过上限时，标准做法是拆成多个子 Sitemap，再用一个 Sitemap 索引文件（sitemap index）把它们列出来。索引文件里每一条只写子文件的位置和最后修改时间，本身不包含具体 URL。

可以把它理解成一份目录：蜘蛛先读索引，知道有哪几个分片可取，再按需抓取。这样既避免了单文件过大，也让更新可以局部进行——只改动某个分片，不必整份重建。

分片怎么切比较顺手

按栏目或业务线切

商品、文章、标签页、专题页各自一个分片。好处是边界清楚，某个栏目出问题时，影响的只是它对应的那一份，排查范围小很多。缺点是各栏目 URL 数量差异可能很大，需要留意别让某个分片长期贴着 50,000 的上限。

按更新节奏切

把高频更新的内容（新闻、商品上新）和低频内容（关于我们、帮助中心）分开。这样 lastmod 的变动会更集中，也方便观察蜘蛛对不同分片的回访差别。

分片之后常见的几个坑

• 分片 404：拆文件时改了命名规则，旧分片删掉但索引没同步，蜘蛛拿着过期地址取不到内容。
• 索引没更新：新增子分片后忘记写进索引文件，等于白做。
• lastmod 假更新：每次生成都写当前时间，看起来天天在变。时间久了这个字段就失去参考意义。
• 压缩处理不一致：压缩文件的扩展名和响应头对不上，读取时可能直接失败。

这些问题都不难修，但都需要有人定期看一眼抓取日志，而不只是把文件生成出来就结束。

Sitemap 之外，内链仍然是主路

分片再整齐，Sitemap 也只是「告知」有哪些 URL，蜘蛛走不走、走多深，依然看站内的链接结构。栏目页、列表页、分页、相关推荐这些位置如果完整，蜘蛛可以顺着链接自然展开；如果某些 URL 只在 Sitemap 里出现、站内没有任何入口，抓取优先级通常不会高。

比较稳的做法是：Sitemap 负责覆盖全量和更新提示，内链负责提供合理的抓取路径，两边不要互相替代。

服务器这一头的成本要算进去

不少站点用动态接口实时生成 Sitemap，每次请求都要查一遍数据库。URL 多的时候，这个过程本身就很重，遇上蜘蛛集中抓取，容易把响应时间拖长，反过来影响其他页面的抓取。

更省事的做法是把分片结果定时生成、写到静态文件或缓存里，蜘蛛来取时直接返回。抓取高峰时段尽量避免重建大文件，也别把生成任务和维护窗口排在一起。

把 Sitemap 当成一份需要长期维护的清单，而不是一次性提交的文件；索引、分片、lastmod 三者能对上，抓取入口才算稳。