爬虫排除规则能不能交给 CDN 层下发，两处配置各管什么

把爬虫排除规则交给 CDN 层下发，和站内自己配置一份 Robots.txt 不是替代关系。两层的规则各管多大范围差别很明显：站内配置管的是当前站点的目录、路径与例外，代理层管的是按访问用途统一下发，管到多个站点与所有经它转发的请求。

文件由谁生成，谁负责更新

站内自己维护时，这份文本跟着模板或静态文件一起走，改了要确认输出的是最新版本。交给代理层则有两种落地方式：与站点上已有的文件合并，或者从头生成一份托管文件。合并的好处是不丢站内已写的规则，代价是排查时要分清某条指令来自哪一层——同一目录被两层各写一遍时，读到的结果未必是你预期的那一份。

规则由什么驱动

代理层的规则通常不是手写的。以托管方案为例，其机器人管理文档写明：Bot Preference Sync 会依据 Search、Agent 与 Training 三类策略自动生成托管指令，触发条件是至少有一条策略设为阻断、在含广告的页面上阻断，或把训练类设为不允许。也就是说，改的是用途开关，文本是结果。站内配置反过来：你直接写路径，用途归类要自己表达。

写了不等于被强制

同一份文档也点明了边界：robots 文件本身并不在技术层面阻止爬虫访问内容。它是一份声明，配合愿意遵守的抓取方生效。要让限制真的落到请求上，需要另外启用边缘阻断——把训练类设为不允许并开启该能力后，AI 训练类爬虫的请求才会在边缘被拦掉。这层区别直接影响验收方式：只看文件内容会以为已经生效，实际要确认拦截开关与拦截记录。

模型抓取与搜索抓取分开看

站内还有两处设置容易被混为一谈。一处是 Robots.txt 配置，管抓取声明；另一处是面向大语言模型的站点清单，AnQiCMS 支持自动生成 llms.txt，用途是让模型侧更容易理解与索引站内内容。这类清单解决的是”读不读得懂”，排除规则解决的是”让不让抓”，两边都要按 GEO 场景各自的口径核对：先确认哪些路径不该被读，再确认被读的内容组织得是否清楚。

常见问题

托管文件生成后，站内那份还要不要维护？ 要看采用合并还是从头生成。合并时站内规则仍是输入之一，删了会同步消失；从头生成时以代理层为准，站内文件要停更并记录说明。

多个站点共用一套 CMS 时该在哪一层统管？ 全站级的用途限制适合放在代理层统一表达，单站特有的目录限制留在站内配置里，避免为了一个站点放开整体规则。

怎么确认限制真的生效？ 查边缘的拦截记录与抓取日志，而不是只看文件文本；文本正确但开关未开，是两层配置最常见的落空方式。