AI收到的所有“OK”网页响应中，有20%其实并不正常

我最近进行的 AI 辅助网页抓取实验，让我切身体会到网络正变得越来越“封闭”。促使网站采取这种收紧措施的原因，当然是 AI 网页抓取的惊人增长；对新数据的不懈需求最终甚至可能令网站域名下线。

这给了网站一个很好的理由，让它们可以做许多早就想做的事：只有用户登录后才能访问网站内容（不过，Googlebot 通常可以畅通无阻）。Facebook 于2023 年完成了这项政策的逐步实施，Twitter/X 也在同一年采取了同样做法。Reddit 将于本月晚些时候实施这项政策。

这样一来，网站就能更轻松地遵守各国针对年龄限制的执行规定，因为用户已经注册。更重要的是，用户数据可以被保存下来，用于本地分析；在当地法律允许的情况下，还可以出售给数据经纪商和 AI 公司。

据 Cloudflare 称，其他专门用于防御机器人（而非招揽用户）的措施同比增加了逾 58%；机器人活动不断升级，自然也促使网站仔细审查VPN 和代理地址，这可能会连同任何“恶意”流量一起，阻止合法用户访问。

从个人体验来看，我似乎越来越频繁地遇到“拦截”响应或验证挑战，以至于有时甚至会放弃访问一个开始加载这些内容的网站。既然研究发现 CAPTCHA 验证墙会劝退用户和潜在客户，我们不难想象，这会给域名所有者带来多大压力，促使他们不顾这种负面影响也采用这些措施。

archive.is 的验证码。该网站是众多采用验证挑战的网站之一，通常是为了应对过多的自动化请求（而非人工请求）。

这些新增的、更严格的访问障碍，部分出于实际需要（因为并非所有网站都能承受这波冲击），但往往也像是一种谈判策略，旨在试探 AI 公司是否愿意为它们极其渴求、长期以来一直免费获取的数据，提供单独或集体的报酬。如今，这种免费获取的局面即将改变。

由于 AI 爬虫必须大规模运行，它们往往会在 Playwright 框架下使用“无头”Chrome 实例。如今，越来越多的网站会对此返回 403（“禁止访问”）错误（也就是说，主机知道你发来的是自动化流量，于是让你滚蛋）：

changedetection.io 的本地安装程序尝试轮询某个网站，但该网站不接受框架所使用、且被检测到的浏览器，因此返回 403（“禁止访问”）响应。

人们想要的是 “200”（“正常”）客户端响应；即使为了得到它，必须掏出一大笔钱交给住宅代理农场，并配合其他各式各样、偷偷摸摸的非人类手段，也在所不惜。

没有什么比 200 响应更好了；也就是说，没有哪种客户端响应代码能传递更强的正面信号。它也不是一种模棱两可的响应：它绝不会是“差不多正常”、“过一会儿就会正常”，或“正在变得更正常”；它就是“正常！”。如果情况不正常，那就不是 200 响应。

你好！请走开

不过，一篇新论文指出，这种缺乏细分的情况可能会严重扭曲 AI 数据集、统计估算，以及在实际情况并非如此时报告的“良好”状态。

这项研究*估计，约五分之一的 200 类响应完全不含可用的网页内容，而是返回空白的网站框架、CAPTCHA 验证挑战、访问限制或替代页面。

论文指出：

“静态客户端收到的状态码为 200 的页面中，有 20.9% 不包含页面的主要内容：应用程序框架、机器人验证挑战、拦截页面、错误页面和占位页面，以及不完整内容。”

在这方面，缺乏耐心的自动化系统反而会被自身的简单粗疏绊住脚，因为“200”响应可能被视为抓取成功，即使抓取结果只是 CAPTCHA 验证墙、付费墙或其他障碍。

论文列出了经常导致 200 响应变得复杂的七类内容：

200 响应中绝非“正常”的七类内容。 来源

这项研究历时三天，使用基础网页抓取程序和能够加载 JavaScript 的浏览器，对 10,307 个网址进行了测试，并根据实际获取的内容而非 HTTP 状态码对响应进行分类。

在无法使用的 202 响应中，数量最多的是空白网站框架以及错误页或替代页，这两类合计占失败案例的三分之二以上。

至于空白网站框架，网站可能会显示菜单和导航，却将用户请求的文章或产品列表留空；后一种情况下，显示的也可能是无关页面或首页，而不是用户请求的内容。不过，这两种情况都可能收到与成功获取到可用且有价值内容时相同的 HTTP 200 状态码。

作为解决办法，论文建议网页抓取工具报告实际获取到的内容，而不是依赖 HTTP 状态码，因为只需检查页面是否异常短、是否存在可疑重定向，以及内容是否类似不存在的页面，就能识别大多数失败情况。

只有在页面似乎未能正常加载时，才可使用资源消耗更大的浏览器工具。此外，AI 评估可以检查引用的来源是否确实包含预期信息，而不是想当然地认为 HTTP 200 响应就意味着内容已成功获取。

这项新研究的作者还指出，使用页面长度、重定向以及与不存在页面的相似度等基础检查，“廉价启发式方法”就能轻松识别约 86% 的不可用响应：

网页抓取策略比较：仅渲染被标记为可疑的页面，获取到的可用内容略多于渲染所有页面（81.4% 对比 80.3%），同时将平均每页获取时间从 20.6 秒缩短至 5.8 秒。

为什么会有这么多错误的 200 响应？

多年来，开发者社区中一直有人争论，认为202（“已接受”）错误（“请求已接受，但尚未完成”）可以区分这些状态为 200、实际却“失败”的请求；但事实上，202 无法涵盖这篇新论文列出的所有情况，而且目前也没有任何现成代码能够做到这一点。

尽管论文没有深入探讨这个问题，但域名所有者为何会允许出现 200 错误，或许值得未来相关研究进一步调查。

原因之一可能是，任何非 200 响应本质上都属于某种错误页面或阻碍，其中包括最常见的404（“未找到”）错误——这表示目标内容根本不存在。有人认为，此类错误过多会导致 SEO（以及可能还有GEO）受到惩罚，但 Google否认了这一点。

事实上，Google 将错误的 200 响应视为“软”404；这类响应显然比普通 404 错误更可能被视为问题，因为无论是否出于故意，它们本质上都是“具有欺骗性”的结果。

引用漂移

如果这一切听起来像是在吹毛求疵，就应当考虑到，为了训练 AI，人们经常收集（或试图收集）的数据规模可达拍字节级别。如果其中整整五分之一的数据不可靠或具有明显欺骗性，其后续影响就很难被轻描淡写地归为某种“附带误差”；相反，这类错误响应可能会显著不利地影响数据集中的数据分布，以及使用这些数据训练 AI 模型所产生的结果。

例如，错误的 200 响应涉及的一个突出问题是“引用漂移”：AI 生成的回答不再能从最初作为证据引用的网页中得到支持。也就是说，页面可能已经更改，相关文本可能已被删除，或者链接现在可能指向别处。

这项新研究发现，如果将所有 HTTP 200 响应都视为成功获取，而不论其中包含什么内容，表面上的引用漂移比例就会从 5.8% 升至 21.9%。

这意味着，CAPTCHA 验证码、空白页面或其他阻碍内容可能取代了原始材料并被获取，结果导致人们错误地认为某个来源已经更改、消失，或不再能为 AI 生成的主张提供支持。

只管说它存在！

针对故意编造的不存在网址进行的测试，也证明了这一问题。向网站请求随机编造的路径时，作出响应的网站中有 13.1% 返回了 200（“正常”）状态，尽管请求的页面并不存在^†。

“对随机路径探测作出响应的网站中，有 13.1% 返回了 200（S1 10.5%、S2 13.3%、S3 17.3%、S4 13.7%、S5 13.1%）。按定义，这类响应全都是软 404，但并非每个响应都会表明这一点。”

“在对 172 个软 404 响应进行的探索性分类中，标注人员将 98 个归为错误或替代页面，32 个归为框架页，28 个归为内容页：在随机路径下呈现的主页或列表页，看起来就像普通页面。”

结论

如果能在更高层面上识别这一问题，IANA 或许可以设立一个新的、更加贴切的 HTTP 状态码，例如 [X] （“请求已成功，但未提供所请求的内容”）。这确实能描述实际发生的情况，但自然也要求主机端对事务有非同寻常的洞察力，而这不太可能实现。

虽然已有一些类似的状态码，但都不太适用：451（“因法律原因无法提供”）含义模糊，而且相当令人不安（！）；206（“部分内容”）从技术角度看很贴切，但它原本用于不完整的数据（获取）；而令人意外的是，竟然还存在 203（“非权威信息”）这一状态码，它创建于 1997 年，与眼下的使用场景只有间接关联。

或许最接近的候选项其实是名称不太直观的 103（“早期提示”），它表示该 URL 的资源尚未全部加载完成（不过，这显然会严重曲解该状态码的本意）。

* 题为《当 200 OK 并非答案：智能体式网页内容获取中的静默抓取失败》。请注意，这篇论文显然主要是为机器读取而写，或许是为了供 AI 查询；论文自身并不容易读懂。

^†抱歉引用这种机械化的表述，但正如我上文所说，整篇论文都采用这种写法，旨在便于“机器读取”，而非供人理解；不过，它还没有采用 JSON 格式。

首次发表于 2026 年 11 月 4 日，星期三