站点地图单文件上限是多少，URL 过万时怎么拆成索引文件

站点地图（sitemap）单个文件能放多少条 URL、规模超过上限时怎么拆，是很多内容量大的站点迟早会遇到的问题。答案不在某家系统的设置里，而在站点地图协议本身：协议对单文件的条数和体积都设了上限，超限就必须拆分，用一份索引文件把多份子地图组织起来。理解上限从哪来、拆分按什么维度，才能在大站上把地图这件事做稳，而不是等收录出问题才发现地图超限。

单文件上限由谁规定

上限来自站点地图协议，而不是某个平台或某套系统。协议对单个 Sitemap 文件规定了两道约束，两者只要碰到其一就该拆；索引文件本身也有条数上限。下面是对照。

需要提醒：这里的条数与体积是「单个文件」的上限，靠的是索引文件来突破总规模限制。所以真正支撑超大站点的方式，不是一份地图硬塞所有 URL，而是「索引文件 + 多份子地图」的分层结构。

超上限后按什么维度拆分

拆分不是机械地每若干条切一刀，而要选一个对收录和运维都有意义的维度。常见有三种。按栏目或内容类型拆，新闻、产品、文档各自成组，便于定位问题分组。按更新时间拆，把高频更新的活跃内容和很少动的归档内容分开，让引擎对活跃分组更勤快地来抓。按语言或站点拆，多语言、多站点场景下每套独立成组，边界清晰。

拆完之后，用一份 Sitemap 索引文件把各子地图登记起来，引擎读索引就知道有哪些子地图可抓。层级上保持「一个索引指向一组子地图」的清晰结构，避免同一 URL 重复出现在多份子地图里，减少不必要的抓取浪费。

拆分后怎么确认新分组仍被抓到

拆成多份子地图后，最容易漏的是「新分组没被登记或没被推送」。站点地图提供的是全量清单，但它不保证时效——刚发布或刚改动的内容，靠地图等引擎来巡往往不够快。这时要用主动推送补上：系统内置 Sitemap 自动生成，并支持向搜索引擎做链接主动推送，加速新内容被收录。拆分出的新子地图，应在生成后被索引文件收录、并纳入主动推送的范围，而不是只生成文件却没人通知引擎。

也就是说，站点地图解决「全量交底」，主动推送解决「变更及时」，两者配合才完整。大站在拆分地图时把这条链路配齐，才能既覆盖历史全量，又照顾新增与更新的时效。

常见问题

URL 没到五万条要不要拆？ 规模没触顶时可以不拆，但按栏目或更新频率预先分组，通常比将来被迫一次性重拆更好维护。

索引文件和子地图是什么关系？ 索引文件本身不列具体内容 URL，只登记各子地图的地址，相当于一份「地图的目录」。

拆完还要主动推送吗？ 要。地图偏全量、推送偏时效，新分组纳入链接主动推送，才能让刚发布的内容更快被收录。