AI 抓取分成检索、训练、代理三类，站点要单独决定哪一类

AI 抓取被分成检索、训练、代理三类之后，站点要单独决定哪一类的放行，这是当下访问控制里最实际的一条分界线。检索类抓取替搜索引擎与问答产品读取可以被引用的页面，放行它才有出现在答案里的机会；训练类抓取读取正文用于模型训练，通常不给站点带回即时流量；代理类抓取代表用户完成这一次访问，读的是当次答案需要的页面。过去把这些共用一个总开关处理，站点想收紧训练的同时会连带把检索与代理一起挡在门外，收录与被引用的可见度同时下滑，而这两件事本来就不该绑在一起决定。

三类抓取各自给站点什么

三类抓取读的内容形态接近，但给站点的回报差别很大。检索类读的是栏目页、正文页与说明页，产出的是索引与引用来源；训练类读大批量语料，产出的是模型内部的知识，站点侧看不到直接回流；代理类由用户当次问题触发，读得少但意图明确，往往直接对应一次访问或一个转化。把这三类混成一栏来判断，很容易得出「AI 抓取没有价值」或「AI 抓取必须全开」这种一边倒的结论。

一个开关管三类会误伤什么

单一开关的问题在于混合用途。已有统计口径把相当一部分已验证流量归为混合用途抓取，同一个用户代理既可能替检索读取，也可能替训练批量下载。按整段区间收紧时，站点想挡的那一类没挡干净，想留的那一类先被拦下，事后从报表上只能看到整体抓取量下降，看不出到底是哪一类被误伤。更麻烦的是这种误伤往往滞后：收录下滑要几周才反映到自然流量上，而站点的训练类拦截统计却显示「生效了」。

按类别决定放行的判断顺序

先按类别设默认值，再看数据微调，顺序大致是这样：

判断时先问一句：这一类被引用会不会带来访客。会，就先放行再优化承接页；不会，就单独收紧这一类，别顺带动到前两类。

后台 robots 配置与 llms.txt 生成落在哪一步

落到操作层面，robots 文件表达的是访问意愿，告诉抓取方哪些路径可以读、哪些不要读，它管的是能不能进；llms.txt 表达的是阅读路径，告诉大语言模型这个站点有什么内容、从哪里开始读，它管的是进来之后怎么走。两者不是替代关系，只配其一都会留缺口。AnQiCMS 的后台里这两处都有独立入口：Robots.txt 配置用于设置抓取规则，站点 LLMs.txt 由系统自动生成，改完不需要手写文件。

改完之后的核对也别省：先看访问日志确认实际到访的是哪一类，再看收录与引用报表确认放行的类别没有受影响。只在后台改开关而从不见证日志，很容易把「配置生效」当成「意图达成」。

常见问题

只挡住训练类，会影响搜索收录吗？ 只要检索类的放行规则没变，索引读取不受影响。风险在于混合用途的那部分流量，收紧后要盯一段抓取日志，确认被挡的对象确实是训练用途。

llms.txt 能不能代替 robots 文件？ 不能。一个说明站点内容与结构，一个说明访问许可，作用面不同。已经放了 robots 的站点仍值得生成 llms.txt，让模型按站点希望的顺序读；反之也一样。

站点没有 AI 访客，要不要干脆全关？ 全关省了带宽，也断了出现在答案来源里的路径。更稳妥的做法是先放行检索类，把训练类按业务判断单独收紧，观察一个周期再决定。

改完类别开关，多久能看出效果？ 检索类的变化通常要先等一轮抓取与索引，再等报表口径同步；短期内先以日志核对「有没有按新规则进」，把排名与流量的判断留到后续周期。