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

📅 2026-10-12 👁️ 0

有测量说抓取脚本只挑一部分排除规则遵守,比例差在哪,答案是差的不是脚本种类而是指令类型。一份覆盖三十六个机构站点、四十天流量、约一百三十个自报身份抓取脚本的测量给出的差值是:抓取频率类指令的遵守率约 60.9%,精确路径禁止约 31%,整段禁止约 30.7%。也就是说,越接近「请你少来」的规则越容易被听,越接近「这里不许进」的规则越容易被忽略。

这组数字测的是什么

研究对象是在这些站点上自报身份的抓取脚本,判定方式是看它的后续请求有没有落在自己声称遵守的规则之内。这类测量只能覆盖愿意自报身份的那一批程序,匿名或伪装来源不在其中,所以数字要当作行为倾向读,不能当作全站结论。样本跨三十六个机构站点、时间跨度四十天,比单次抓包更能说明规则类型带来的差异。

不同指令类型的遵守率差多少

频率类指令最高,约 60.9%。这类规则的内容是「两次请求之间至少间隔多久」,脚本照做不需要放弃任何数据,成本只是慢一点,所以配合门槛低。整段禁止和精确路径禁止明显更低,分别是约 30.7% 与约 31%。这两类要求脚本放弃一整块内容,收益与代价不对等,遇到没有强制力的约定时更容易被忽略。

指令类型 脚本要付出什么 测量到的遵守率 站方该把它当什么
抓取频率控制 拉长请求间隔,数据照拿 约 60.9% 有一定约束力,适合压抓取压力
精确路径禁止 放弃某一段内容 约 31% 约定为主,不能当访问控制
整段禁止 放弃整个站点 约 30.7% 最容易被忽略的一类

为什么重新读取的比例更要紧

同一份测量还给出一个容易被忽略的数字:不到四成的脚本会在一百六十八小时内重新读取这份排除文件。含义是规则改了之后,旧规则在相当一批脚本上继续生效。站方今天收紧一条限制,指望一周内全网生效并不现实;反过来,误写一条排除导致抓取中断,恢复也不会立刻发生。改动前后的观察窗口都要拉长。

把排除文件当单一手段为什么不成立

协议本身就把这套规则定位成抓取约定,而不是访问授权。这组遵守率数据把它的实际效果量化了一遍:约三成到约六成的差距,落在同一份文件里。真要限制某段内容被取走,得叠加别的层。AnQiCMS 在站内提供 robots 配置入口,负责表达抓取意图;防采集干扰码负责在页面输出时加入干扰,让批量采集拿到的正文失真;后台与用户组权限负责挡住不该公开的入口。三层各有各的适用面,缺一层都会留下空隙。

复查抓取日志时看哪三步

第一步分身份:把自报来源与匿名请求分开统计,自报那批的遵守情况才和这组比例可比。第二步看类型:哪些路径在被无视排除规则反复请求,频率类规则有没有真的拉开间隔。第三步看时间:一条规则改动之后,请求量的变化出现在第几天,据此判断重新读取的实际节奏。三步走完再决定是补规则还是换层——多数情况下,反复被无视的路径需要的是权限控制,而不是再多写两行排除条目。

常见问题

问:遵守率高是不是说明这层防护有效? 答:只说明配合的是自愿的那部分,而且对象是频率类这种低代价规则。高遵守率不等于数据安全。

问:既然整段禁止容易被绕,还要不要写? 答:要写,它仍会拦住自愿遵守的抓取方,成本也最低。只是不能只写它。

问:改了规则迟迟看不到效果,是不是配置没生效? 答:先确认服务器返回的是新版本,再考虑重新读取的时间差——多数脚本不会在一百六十八小时内回来重读。

相关文章

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

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

2026-10-12

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

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

2026-10-12

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

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

2026-10-12

服务器默认把程序版本写进响应头和错误页,要不要收掉这层指纹

多数 Web 服务器默认把程序版本写进 Server 响应头和错误页,Nginx 的 server_tokens 指令默认就是 on,关到 off 之后两处都不再带版本信息。收掉这层指纹能减少按版本撞库的便利,但它只是减少信息暴露,不构成防线。本文讲版本号从哪两处漏出去、关掉后还剩什么,以及宝塔、Docker 等不同部署方式各要在哪一层改。

2026-10-12

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

2026 年 9 月 15 日的一份边缘平台公告把搜索、AI 训练、AI 智能体拆成三项独立控制,站方不必再在保留搜索和挡住训练之间二选一。公告同时给出两个占比:混合用途爬虫占已验证抓取流量的 36.6%,站点侧不到百分之一会挡搜索爬虫、约百分之十七限制 AI 训练。开关拆开之后,放行规则要按访问用途判,而不是按来源域名判。

2026-10-12

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

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

2026-10-12

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

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

2026-10-12

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

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

2026-10-12