一张站点地图能放多少条链接，超了怎么拆开

一个站点地图文件能放多少条链接？协议文档给出的是容量上限而不是建议值：每个站点地图文件不得包含超过五万条地址，文件解压后的体积不得超过 50MB。超过这个量就必须创建多个文件，再用站点地图索引把各分片列出来。索引文件本身也受同样的条数与体积上限约束，所以「拆」这件事最多两层，不能靠无限嵌套解决。

协议给的是容量上限不是建议值

这条上限容易被读成「建议控制在多少条以内」，实际它是硬性约束：超出上限的文件不合规，抓取方可能直接拒绝读取整份文件，而不是只忽略多出来的部分。体积限制同理，且明确针对解压后的内容——即便压缩传输，展开后超限仍然超限。

因此正确的读法是：先按上限倒推分片数量，再考虑怎么切得好维护。把全部地址塞进一个文件，在站点规模小的时候可行，一旦越过上限就是整份失效，风险比预期大得多。

拆分时索引文件承担什么

拆分后需要一份站点地图索引，它列出各个分片文件的地址与各自的最后修改时间。作用是给抓取方一个稳定的入口：分片增减只需更新索引，已提交给搜索引擎的地址不用换。

索引文件要控制数量增长：每个分片都放很少地址，会让索引本身变得冗长。合理的目标是让分片大小接近上限但留出增长余量。

分片的合理切法

两种切法最常见，取舍差别很大。按时间切（按月或按年）实现简单，但会带来分布不均：新栏目增长快，旧归档长期不动，最后既有超限的分片，又有几乎空的分片。按栏目切更容易保持均衡，也更符合内容管理逻辑——每个栏目的地址数量天然有边界，出问题时排查范围明确。

多语言与多站点场景建议再加一层维度：按站点切，站点内按栏目切。跨站点混在一个分片里，会让单点失败的影响面难以判断。

还要注意不该出现的地址不要留在清单里。AnQiCMS 的文档状态分为正式、草稿、待发布与回收站，删除正式文档是移入回收站而非物理删除，生成站点地图时只应包含对外可见的正式地址，草稿与回收站内容混进去等于主动暴露内部路径，还会带来大量错误响应。

站内站点地图由谁生成

手工维护清单在内容量上升后不现实。AnQiCMS 支持自动生成站点地图，栏目与文档变化直接进入清单，字段按站内规则统一给出，这一步也顺带保证分片结构的一致性。

生成之后仍然要人工核对两件事：文件体积是否接近上限，以及旧地址的去向。做过地址规则调整或栏目迁移的站点，还要检查历史地址是否已经安排重定向，AnQiCMS 支持 301 跳转管理来设置地址重定向，旧地址有承接才不会在清单里留下大量失效条目。

主动推送与站点地图是两条通道，不能相互替代。站点地图是全集清单，抓取方按自己的节奏回访；链接推送针对具体变更。AnQiCMS 的链接推送管理支持百度与 Bing 主动推送，新内容发布后走推送，历史与全量核对走站点地图，两条各自发挥作用。

常见问题

刚好接近上限要不要提前拆？ 要。增长中的站点如果停在临界值，一次批量导入就可能整份失效，提前分片更稳。

索引文件可以指向索引文件吗？ 不要这样设计。协议的分层是索引指向具体清单，多层嵌套会让结构难以核对。

gzip 压缩能绕过体积上限吗？ 不能。上限针对解压后的体积，压缩只减少传输开销。

分片地址要不要一起提交给搜索引擎？ 提交索引入口即可，抓取方会从索引读取各分片，避免逐个维护提交清单。