排查 Cloudflare 是否误拦 AI 搜索抓取

dev.to · AI#Cloudflare#AI 搜索#爬虫

Editor brief · 编辑速览

文章区分用于模型训练、搜索索引和用户触发访问的 AI 爬虫，说明 Cloudflare 边缘设置可能分别影响这些请求。内容包含相关配置检查、curl 测试及响应解读方法。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

网站迁到 Cloudflare，DNS 正常、HTTPS 正常、浏览器也能打开，仍不能证明 AI 爬虫能读到页面。作者提醒：Cloudflare 的多套策略会分别处理搜索、训练和用户触发的抓取，一处配置就可能改变网站在 AI 搜索中的可见性。

这篇解读最值得看的是排查方法：先分清要放行谁，再检查边缘规则，用 curl 找线索，最后回到控制台核对真实爬虫记录。作者依据的是 2026 年 10 月的文档，没有给出某个站点调整前后的实测数据。

想被 AI 搜到，不等于要同意模型训练

「允许 AI 爬虫」不是一道开关题。作者把流量分成三种用途：收集内容用于训练、建立搜索索引，以及用户提问后临时打开页面。

Cloudflare 对应的分类是 Training、Search 和 Agent。Agent 包括聊天抓取机器人和 browser-use agents，也就是替用户实时访问网页的程序。

同一家公司的机器人也有不同职责。GPTBot 与 OAI-SearchBot 不能混为一谈，ChatGPT-User 又是另一类。原文转述 OpenAI 的说明：拒绝 OAI-SearchBot，网站就不会出现在 ChatGPT 搜索答案中。OpenAI 和 Perplexity 还表示，用户触发的 ChatGPT-User、Perplexity-User 可能不遵循 robots.txt，因为访问由用户发起。

搜索可见性、训练授权和即时访问，需要分别决定。

对希望被 AI 答案引用的业务，作者建议 Search 设为 Allow；Agent 要结合用途判断；Training 则自行取舍。这里的 Allow 只是允许访问，并不保证网站一定被索引或引用。

五处配置会叠加，最容易误判的是训练开关

第一处是 Security Settings > Configure AI bot policies。Search、Agent、Training 都可选 Block、Block on pages with ads 或 Allow。自 2026 年 9 月 15 日起，Training 还增加了 Disallow AI Training。

按原文引用的公告，Disallow AI Training 会在 robots.txt 表达拒绝训练的偏好，同时保留 Cloudflare 称为「Accountable」的混合用途爬虫访问搜索内容，包括 Applebot、Bingbot、Googlebot，并阻止其他训练爬虫。Training 的普通 Block 和 Block on pages with ads 则也会作用于这些混合用途爬虫，连带影响搜索。

旧的「Block AI bots」开关已经弃用，原有设置会迁移。作者因此强调，迁站后要检查最终配置，不能凭旧开关的印象判断。

新域名的引导预设也有区别：不靠广告变现的网站，三类均为 Allow；广告变现网站则是 Search Allow、Training Disallow AI Training、Agent Block on pages with ads。这是引导时提出的预设，仍要以控制台为准。

第二处是 Bot Preference Sync，旧称 managed robots.txt。启用后，只要至少一项策略采用阻止或拒绝训练选项，它就会向现有 robots.txt 前面加入托管指令和 Content Signals Policy；没有文件时则创建一个。原文称，新客户默认开启。

Content Signals 包括 search、ai-input、ai-train。它们表达内容使用偏好，遵守与否取决于访问方。部署目录里的 robots.txt，也未必等于线上实际返回的版本。

第三处是 AI Crawl Control，旧称 AI Audit，所有套餐均可用。这里逐个阻止爬虫，会创建或更新 WAF custom rule。付费套餐可以选择返回 403 Forbidden 或 402 Payment Required。Free 套餐依据 User-Agent 字符串识别 AI 爬虫，付费套餐则可使用 Bot Management 检测。

第四处是 Bot Fight Mode。它会对符合已知机器人模式的流量发出计算挑战，也可能影响 API 或移动应用流量。WAF custom rules 和 Page Rules 中的 Skip、Bypass、Allow 都无法绕过它。文档给出的处理方式是关闭它，或改用支持 Skip 规则的 Super Bot Fight Mode。

第五处是自己的 WAF 规则。国家限制、复制来的 User-Agent 黑名单，都可能误伤爬虫。多数安全功能的 Block 返回 403，限流返回 429；Challenge 则要求客户端通过挑战。原文举例，Anthropic 表示其机器人不会尝试绕过 CAPTCHA。

curl 能发现误拦，但不能冒充真实爬虫

作者给出的检查方法，是对同一 URL 更换 User-Agent，对比状态码、响应大小和 Cloudflare 响应头。下面这段应在支持关联数组的 Bash 中运行，并先替换目标 URL：

URL="https://example.com/pricing"

declare -A UA=(
  [browser]="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
  [GPTBot]="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot"
  [OAI-SearchBot]="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot"
  [ChatGPT-User]="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"
  [PerplexityBot]="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)"
  [Perplexity-User]="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)"
  [ClaudeBot]="Mozilla/5.0 (compatible; ClaudeBot/1.0)"
)

for name in "${!UA[@]}"; do
  curl -s -o "out_$name.html" -D "hdr_$name.txt" -A "${UA[$name]}" \
    -w "$name\t%{http_code}\t%{size_download} bytes\n" "$URL"
  grep -i -E "^(cf-mitigated|cf-ray):" "hdr_$name.txt" | sed 's/^/    /'
done

重点看 -A "${UA[$name]}"：它只修改请求头里的身份声明。版本号可能变化；ClaudeBot 一行只是包含产品标识的最小测试字符串，因为原文所引 Anthropic 页面没有公布完整 UA。

再读取线上 robots.txt 的前 80 行：

curl -s https://example.com/robots.txt | sed -n '1,80p'

重点看 sed -n '1,80p'：这里只展示前 80 行，应留意 BEGIN Cloudflare、Content-signal:，以及相关 User-Agent 下的 Disallow: /；文件更长时还要继续检查。

借用爬虫的 User-Agent，只能验证部分规则，不能证明真实爬虫的访问结果。

请求仍来自自己的 IP。Cloudflare 还会通过 Web Bot Auth 签名、公开 IP 列表或反向 DNS 验证机器人。这个测试适合发现基于 UA 的拦截，包括 Free 套餐的 AI Crawl Control，但也可能得到与真实爬虫不同的结果。

最终要去 Security > Analytics > Events 查哪个服务采取了动作，再到 AI Crawl Control 的 Crawlers 标签查看各爬虫的请求和失败请求。

我的判断

作者最有用的提醒，是把 robots.txt、流量识别和实际拦截拆开。只改 robots.txt 解决不了 WAF 挑战，只添加 WAF 放行规则也解决不了 Bot Fight Mode。

安全上，按 UA 放行很容易被伪造。原文推荐使用 cf.client.bot、cf.verified_bot_category 等验证信息；Perplexity 的文档则建议结合 UA 与公开 IP 范围。相比直接相信请求头，这些依据更适合正式规则，但具体该匹配什么，仍取决于站点要允许的机器人类别。

局限也明确：作者没有给出配置调整前后的抓取成功率、索引变化或业务收益。「希望被 AI 找到就允许 Search」是有文档依据的起点，无法直接推导出流量增长。文末提到的 AURA GEO 也没有对照测试，不能据此判断它优于控制台记录加自建脚本。

能拿来做什么

把 AI 爬虫检查加入迁站验收，对官网、文档站和定价页分别比较浏览器与爬虫 UA 的响应，并核对线上 robots.txt。
为搜索、训练和用户即时访问分别记录策略，尤其检查旧开关迁移结果，避免用 Training 的 Block 误伤 Googlebot、Bingbot。
遇到 AI 无法读取页面时，先查响应头与安全事件，定位 AI Crawl Control、Bot Fight Mode 或自定义 WAF 中实际生效的一层，再修改规则。
将 curl 脚本用于定期发现响应变化，同时保留真实爬虫的控制台记录；合成请求通过后，继续确认真实访问是否成功。