把搜索和训练拆成两个开关之后,放行规则按哪个用途判

📅 2026-10-12 👁️ 0

把搜索和训练拆成两个开关之后,放行规则要按访问用途判,而不是按来源域名判。一家边缘平台在 2026 年 9 月 15 日的公告里说明,搜索、AI 训练、AI 智能体已成为三项独立控制:站点可以只让内容进入搜索结果,而不把同一份页面交给训练用途。这改变了过去的困境——想挡训练就得连搜索一起挡,代价太大,于是多数站点选择全放。

三个开关各管哪一种访问

用途拆开之后,三类访问的边界比较清楚。搜索类是把页面收进索引并展示给用户,站方通常愿意配合;训练类是批量取走语料,是否要给它收益由站点自己判断;智能体类是替某个用户临时代取内容,它既可能是一次性访问,也可能持续出现。三者的动机不同,回荐给站点的流量也不同,用同一个开关处理必然失真。

混合用途抓取占比说明什么

公告里有一个数字容易被跳过:混合用途爬虫占已验证抓取流量的 36.6%。含义是同一批请求并不属于单一用途,同一个来源既可能服务于搜索索引,也可能把内容送进模型训练。这个比例决定了开关拆开之后能不能真的用起来:约三分之一多的流量落在两类之间,如果站方仍然按域名放行,两个开关就会互相打架;只有请求侧带着用途标识,按用途判才有可执行的对象。

用途 它取内容是为了什么 站点通常的诉求 放行规则按什么判
搜索 建索引、把用户带回站点 希望被完整收录 按搜索类放行,保持清单与抓取路径畅通
训练 批量取语料,不承诺回访 收益不确定,倾向收紧 单独拒绝,不影响搜索收录
智能体 代某个用户临时代取 看具体请求方是谁 按代取行为限频,保留可复核记录

站点的真实选择分布

公告给出的另一组数据是站方偏好:不到百分之一的站点会挡搜索爬虫,约百分之十七限制 AI 训练。这两个数字放在一起更能解释开关为什么要拆。搜索收录对多数站点是必需项,几乎没人愿意放弃;训练用途的分歧大得多,接近两成的站点已经想限制它,只是过去没有只针对它的控制手段。拆成独立开关之后,这类意愿第一次可以单独表达,而不用整站二选一。

按用途放行前要确认的三件事

第一件是请求侧到底带不带用途标识。没有标识就只能按来源与路径猜,规则写出来也难以复核。第二件是自己站点的抓取日志能不能分类统计,能把三类访问分开计数,才谈得上分别放行;否则改动带来的差别看不出来。第三件是排除规则与开关的关系。按用途的控制面通常位于边缘层,排除文件则是一份面向自愿遵守者的约定,两边写出的意图如果不一致,抓取行为会按其中更宽松的一侧表现。

常见问题

问:拆成三个开关之后,是不是就不用改排除文件? 答:不能替代。开关管的是可识别的抓取请求,排除文件表达的是站方意图,两者作用面不同,仍要一起维护。

问:混合用途那部分怎么办? 答:先按最保守的一侧处理,再观察实际行为。占比接近三分之一说明这部分不是边角情况,值得单独做统计口径。

问:限制训练会不会影响搜索收录? 答:这正是拆开开关要解决的问题。只要请求侧能区分用途,训练类收紧不必以放弃搜索收录为代价。

相关文章

有测量说抓取脚本只挑一部分排除规则遵守,比例差在哪

一项覆盖三十六个机构站点、四十天流量、约一百三十个自报身份抓取脚本的测量显示,遵守率按指令类型差别很大:抓取频率类指令约 60.9%,精确路径禁止约 31%,整段禁止约 30.7%;而且不到四成的脚本会在一百六十八小时内重新读取排除文件。这组数字说明只靠排除文件这一层手段并不成立,站内还要有防采集与权限层。

2026-10-12

Robots 文件本身读不到的时候,抓取方按什么规则继续

排除协议原文把读取失败分成两种相反结果:响应状态码落在五百段到五百九十九这段服务端错误时,抓取方必须视为全部禁止;落在四百段到四百九十九这段客户端错误时,抓取方可以访问服务器上任意资源。协议还写明这些规则不是访问授权,也不能替代内容安全措施,站内的后台与用户组权限才是真正的一道门。

2026-10-12

给大模型的站点说明文件是给人读的还是给智能体用的,提案改过说法

这类站点说明文件按提案的现行说法是帮智能体使用网站,早期表述才是帮语言模型读懂网页,服务对象从模型扩展到智能体。文件是纯文本清单,规范要求里只有一项必填:带项目或站点名称的一级标题,其余摘要段、说明段和按二级标题分组的文件清单都是可选。AnQiCMS 支持自动生成站点 llms.txt,并与站点地图分工不同。

2026-10-12

调整页面排版会不会更容易被生成式引擎引用,实验给出两个百分比

有一项生成式引擎优化研究把内容结构拆成文档架构、信息分块与视觉强调三层,在六个主流生成式引擎上做实验,报告被引用率提升 17.3%、主观质量提升 18.5%,且不改主题内容。本文解释这两个百分比各自指什么、结构提升为什么不等于内容质量提升,以及它和站内自动生成 llms.txt 这类站点说明的分工。

2026-10-12

安全响应头加了但有些响应里没有,状态码条件和层级继承怎么查

加了安全响应头却在部分响应里看不到,通常卡在两处:一是加头指令只在特定响应码生效,主流 Web 服务器文档列出的生效码包括二百段成功与三百段跳转,非成功响应要靠带 always 参数才无条件添加;二是层级继承规则——同层一旦定义了加头指令,上一层的整组定义就不再继承。排查顺序是先复现缺头的那个响应码,再定位它是哪一层配置生成的。

2026-10-12

首屏资源提前加载的中间响应码,为什么多数情况只在多路复用协议下发

用于首屏资源提前加载的 103 中间响应,是服务器还在组织最终页面时先发出的提示,客户端可以提前预连接或预加载资源。官方文档建议出于兼容与安全考虑只在 HTTP 协议 2 或更高版本上发送,多数浏览器也只在这个条件下支持。原因是旧协议下中间响应与最终响应之间的边界处理不一致,容易和等待中的响应内容混淆。

2026-10-12

前端监控里跨域图片的加载耗时全是零,该补哪个响应头

跨域图片的加载耗时在前端监控里读成零,缺的是计时放行响应头。官方文档的定义是:该头指定哪些来源被允许看到通过资源计时接口取到的属性值,否则这些值会因跨域限制被报告为零。取值可以是一个星号放开全部来源,也可以是逗号分隔的来源清单。它只影响计时读数,不改变资源的访问权限,所以补这个头解决的是归因问题,不是访问问题。

2026-10-12

页面被别的站点嵌进去时,登录凭据按顶层站点分区是怎么回事

带分区属性的登录凭据会按顶层站点分开存储:同一个地址直接被访问时读到一份,被别的站点嵌进页面时读到另一份,两者不共享。官方文档写明该属性表示凭据应使用分区存储,并且设置它就必须同时设置安全标记,还建议用带主机名前缀的名字把凭据绑定到主机而非可注册域。站点若假定登录态全局共享,嵌入场景下就会读不到。

2026-10-12