站点地图的地址写在排除文件里还是提交给搜索引擎，两种声明各给谁看

站点地图的地址是写在排除文件里，还是提交给搜索引擎控制台，两种声明方式各给谁看？两种都做才完整：协议原文写明「可以用排除文件来指定站点地图的位置」，同时可以在一个排除文件里列多条站点地图行；而提交到搜索引擎侧是另一条路径，读取时机和读取方都不同。协议对规模也给了硬数字：单个站点地图文件不能超过五万条地址、未压缩体积不能超过五十兆（原文写作 50MB，即 52,428,800 字节），索引文件列出的子文件同样不能超过五万个、体积上限一致。

两种声明分别在什么时机被读到

排除文件那一行是给「先来读规则、再来取内容」的抓取方看的。抓取程序按惯例会先取排除文件，看到站点地图行就知道去哪儿找完整清单，不需要额外被告知。它的优点是自动：配置一次，之后所有按规则办事的抓取方都能发现。

提交那一路是给「需要建立站点关系」的搜索侧看的。提交动作通常伴随站点归属校验，提交之后能看到处理进度与条目状态——这些是排除文件声明给不了的反馈。

两者不是替代关系。只写排除文件不提交，新站或改版后可能长时间没人来取；只提交不写排除文件，那些只做常规抓取、不按控制台走的一方就少了一个发现入口。

协议里关于位置和上限的原句

三句原话能定住实践边界：

位置声明句——「可以用排除文件来指定站点地图的位置」，写法是在文件里加一行，包含站点地图的完整地址；并且「一个排除文件里可以指定多条站点地图行」。

规模上限句——「每个站点地图文件的地址数不能超过五万条，未压缩大小不能超过五十兆」，索引文件「列出的站点地图不能超过五万个，大小同样不能超过五十兆」。

这里有个容易忽略的点：上限按「未压缩体积」计，服务端开压缩传输时，实际传输量小得多，但分片判断要按解压后的尺寸来。

按这两句做的实际安排是：内容量到万级就把清单拆成按栏目或按类型的多个文件，再用一个索引文件把它们列起来；排除文件里指向索引文件，而不是把一堆分片地址逐条写进排除文件。

站内两项配置的配合顺序

AnQiCMS 支持站点地图自动生成，也支持 robots 与排除规则配置，两项要按顺序配，否则会出现「清单已生成但没人知道」的状态。

推荐的顺序与对照关系如下：

第四行值得多说一句：主动推送解决的是「这条新地址请尽快看」，清单解决的是「全站地址在哪儿」。前者不能替代后者，因为推送有规模与节奏限制，而清单是全覆盖的底账。

常见不一致与自查

三类不一致最常见。

一是排除文件指向的地址打不开，或者返回的是 HTML 而不是清单内容。多发生在伪静态规则调整之后，清单地址被重写规则拦掉了。

二是清单里有站外或测试域名地址。通常来自迁移或体验环境留下的历史数据，逐条核对地址前缀能查出来。

三是分片与索引对不上。索引列了十个文件，实际生成了十二个，或者反过来。按生成结果重新出索引，而不是手工维护那份列表。

自查动作可以固定成四步：取排除文件看有没有位置行；取那一行指向的地址确认能打开；看清单里条目数量是否接近上限、需不需要分片；确认搜索侧看到的站点状态与清单地址一致。

常见问题

排除文件里写了还要提交，是不是重复？ 不重复。前者是发现机制，后者是建立站点关系与取得反馈的机制，用途不同。

清单条数接近上限怎么办？ 按协议口径分片：拆成多个文件，再用一个索引文件把它们列起来，排除文件指向索引。

多站点要各配一份吗？ 要。排除文件与站点地图都按站点独立生效，每个站各自声明自己的清单地址；跨站指同一份清单会让地址归属混乱。

清单里要不要包含带参数地址？ 按内容管理侧的口径筛：只放希望被抓取的那一种形态，与站内规范地址的处理保持一致，两处不要互相矛盾。