robots.txt允许但CDN拒绝：全球千站AI爬虫访问实测

大多数讨论AI爬虫封锁的文章只盯着robots.txt。但那份文件只是请求，不是锁——真正决定爬虫拿到什么的是服务器、CDN和机器人管理层的联合动作。一家研究机构对Tranco前1000名站点做了一次实测，结果值得每个依赖AI搜索流量的人重新审视自己的配置。

robots.txt与CDN之间的分歧

核心发现：14%的站点在与自己的政策打架

在549个对普通浏览器返回2xx的站点中，有78个（14.2%）拒绝了GPTBot、OAI-SearchBot、ClaudeBot或PerplexityBot中的至少一个——而它们的robots.txt明确允许这些爬虫。如果剔除那14个仅因429限流被拒的站点，仍有64个，占比11.7%。

这个数字的意义在于：robots.txt和真实放行行为之间存在一条裂缝。对依赖AI搜索引擎引流的站点来说，这条裂缝意味着它们可能正在悄无声息地把自己关在ChatGPT搜索、Perplexity等平台的引用池之外。

CDN与WAF层才是真正的守门人

最值得注意的数据来自OAI-SearchBot。它决定ChatGPT搜索能否引用你的内容，却在8%明确允许它的站点上被服务器拒绝。这些站点可能只是购买了某条机器人管理规则，或者翻开了某个"屏蔽AI爬虫"的开关，连带着把搜索和答案类爬虫也一道封了。

按爬虫分类的具体拒绝率如下：

GPTBot：14.4%被服务器拒绝，其中11.1%发生在robots.txt允许的情况下
ClaudeBot：14.8%被拒，10.9%在允许之下
PerplexityBot：11.3%被拒，8.4%在允许之下
OAI-SearchBot：9.8%被拒，8.0%在允许之下

429限流单列，因为它是一个判断边界——"慢一点"和"别来了"是两回事。但一个爬虫在对首页发起第一次请求、单一IP的情况下就被限流，实际效果等同于封锁。

镜像情况同样存在：53个站点在robots.txt里禁止GPTBot，却照常提供服务。robots.txt在两个方向上都是建议性的。

CDN、WAF与机器人管理层的分工。 CDN（内容分发网络）负责把内容缓存并就近分发，WAF（Web应用防火墙）负责拦截恶意流量，而机器人管理层是部署在这两者之上、专门识别和处置自动化流量的策略层。Cloudflare、Akamai、Fastly等主流厂商都内置了基于user agent、IP信誉、请求指纹的bot评分机制，很多还提供一键式"屏蔽AI爬虫"开关。问题在于：这些规则往往按厂商而非用途分类，一个"Block AI bots"的开关可能同时拦截训练爬虫和搜索答案爬虫，前者被拦影响不大，后者被拦就直接切断了来自ChatGPT搜索、Perplexity的引用流量。这就是为什么robots.txt里写着Allow，服务器却回403——请求还没走到应用层，就已经在边缘节点被拦下了。

robots.txt本身的统计

从可达站点的robots.txt解析结果看：

82.7%的可达站点有robots.txt
25.1%封锁了至少一个搜索或答案爬虫，10.2%封锁了大多数
26.0%封锁了至少一个训练爬虫，但只有2.6%做了指南推荐的事：只封训练爬虫，保持搜索和答案爬虫开放
2.5%带有Content-Signal指令，62.4%列出了sitemap

2.6%这个数字本身就是一个洞察。大多数做AI爬虫管理的站点并没有做精细化区分，而是用一刀切的方式处理所有AI相关流量。那些做了正确区分的少数站点，恰恰证明了按用途而非按厂商分类是可行的。

llms.txt的真实采用率被高估了

被广泛引用的llms.txt采用率数据，大多被"软404"污染了——站点对任何路径都返回200，内容却是一个HTML的"未找到"页面。研究者重新抓取了所有报告存在的llms.txt，只保留内容为文本文件且以Markdown标题开头的。

文件类型	任意2xx响应	真实文件
llms.txt	34.3%	15.1%
llms-full.txt	21.9%	未重新验证
agents.json	0.3%	—
Markdown版页面	3.5%提供，1.5%链接	—
WebMCP表单注解	254个有表单的站点中仅1个	—

真实的llms.txt采用率大约七分之一，而非三分之一。如果你在构建任何读取这些文件的工具，先测试软404：检查内容类型，检查第一行是不是标题。

软404为何会污染统计。 软404指服务器对不存在的路径返回HTTP 200成功码，但实际内容是"页面未找到"的HTML提示页。很多单页应用、静态托管平台和CDN的默认配置都会这样处理——只要路径匹配某个catch-all路由，就永远返回200。爬虫扫描器如果只看状态码，就会把每个域名下的llms.txt、agents.json、ai.txt都统计为"存在"，从而虚高采用率。识别软404的方法是检查Content-Type是否为text/plain（或text/markdown），以及响应体首行是否以Markdown标题（#）开头。研究者据此重抓后，llms.txt真实采用率从34.3%降到15.1%，说明近六成"存在"都是假阳性。任何基于HTTP状态码的采用率调查都应先做软404过滤。

整体就绪度评分

使用该研究机构的检查器评分（v2版本，只计算为AI搜索和答案抓取页面的爬虫，并将主动封锁视为合法选择而非失败）：均值84.5，中位数90。355个站点属于AI就绪，106个属于主动限制，88个属于JavaScript依赖（爬虫被允许进入，但内容在客户端渲染，大多数爬虫不执行JS），126个因封锁了检查器本身而只能部分检测。

88个JavaScript依赖的站点是另一个隐性风险群体。它们在robots.txt和服务器层面都对AI爬虫开放，内容却因为渲染方式而无法被抓取。

JavaScript依赖为何构成隐性风险。 现代前端框架（React、Vue、Next.js客户端渲染模式）常在浏览器端执行JavaScript后才把内容注入DOM。传统爬虫只抓取服务器返回的初始HTML，不执行JS，因此看到的是一个空壳页面。GPTBot、ClaudeBot、PerplexityBot等主流AI爬虫目前基本不执行JavaScript，这意味着即使robots.txt和WAF都放行，它们拿到的内容仍然为空。解决办法是做服务端渲染（SSR）、静态站点生成（SSG）或预渲染（prerender），让内容在初始HTML里就存在。研究中88个"AI就绪"评分受影响的站点正属于这类——它们在政策层面完全开放，却在技术层面不可抓取，比明确封锁更隐蔽，因为站长往往以为自己是开放的。

如何在一分钟内测试你自己的站点

最快的方法是从终端执行两条命令。如果第一条返回200，第二条返回403，那么你的robots.txt就不是全部故事：

curl -sI -A "Mozilla/5.0" https://example.com/ | head -1
curl -sI -A "OAI-SearchBot/1.0; +https://openai.com/searchbot" https://example.com/ | head -1

研究使用的对比脚本是一个无依赖的Node文件，可以指向任何域名CSV。完整就绪检查在crawlreadiness.com提供，运行的正是研究使用的代码，51个爬虫每个都有参考页面，包含文档化的user agent、用途、是否遵守robots.txt，以及允许或封锁它的确切robots.txt行。

为什么要用真实user agent做请求验证。 curl的-A参数设置User-Agent请求头，服务器正是根据这个字符串来判断来者是普通浏览器还是特定爬虫。第一条命令伪装成Mozilla浏览器，第二条伪造OAI-SearchBot的官方标识。对比两者返回的状态码即可判断服务器行为是否与robots.txt一致：如果浏览器200、爬虫403，说明有CDN或WAF层规则在起作用；如果两者都200，说明放行；都403则说明应用层主动封禁。进阶验证还要检查返回内容是否为空壳（JS依赖）、是否被跳转到验证页面。注意user agent可以被伪造，所以这只是验证"服务器对你的声明身份作何反应"，不是身份认证。在做破坏性测试前，建议先查该爬虫的官方文档确认其真实user agent格式。

如果你落在那14%里，该怎么办

如果你发现自己中了招，解决路径清晰：

先看机器人管理层，再看robots.txt。 在Cloudflare上是Security → Bots，"Block AI bots"会同时封锁搜索和答案爬虫。其他CDN和WAF上，寻找匹配上述user agent字符串的托管规则。
按用途决策，而非按厂商。 封锁GPTBot（训练）同时允许OAI-SearchBot（ChatGPT搜索引用）是合理且常见的选择，那2.6%认真这样做的头部站点证明它有效。
通过请求验证，而非阅读文件。 上面的curl对只需十秒。

数据以CC BY 4.0发布，包含逐站点CSV、逐爬虫CSV和摘要JSON，每月重新运行并保留历史记录。如果你发现分类错误的站点，逐站点行会显示收到的每个状态码。