网站被 AI 彻底无视了三个月，问题出在一个没人怀疑的开关上。建站公司一直说"没问题"，我们接手后只改了一处，三个月被挡在门外的 AI 爬虫当天就回来了。

本文是一次真实排查复盘。为保护客户隐私，站点以「某 CNC 快速成型外贸站」代称，后台截图已做域名打码处理。

一、先说结论

如果你的外贸站挂在 Cloudflare 上，请立刻做一件事：

用爬虫的身份访问一次自己的首页，看返回的是内容，还是一张「Just a moment...」。

因为有相当一部分站长，正在毫不知情地对全世界的搜索引擎和 AI 关着门。人用浏览器打开一切正常，老板看着也正常，但 Googlebot、GPTBot、ClaudeBot 看到的只有一张验证页——而那张验证页的源码里，明明白白写着 noindex,nofollow。

这就是我们上个月遇到的真实情况。这个站被挡了大约三个月，期间运营方问过建站公司五六次「是不是 Cloudflare 有问题」，每次得到的回复都是「没问题」。

二、症状是怎么被发现的

客户方最早的感知很模糊，只有一句话：

"AI 引用和收录之前还比较多，后来有一阵就下降了。"

没人把这句话和三个月前上线的 Cloudflare 联系起来。直到我们用不同身份对首页做了一轮实测：

响应头里的关键证据是这一行：

HTTP/2 403

cf-mitigated: challenge

server: cloudflare

cf-mitigated: challenge —— Cloudflare 托管质询（Managed Challenge）。

更要命的是，sitemap.xml也是 403。这个站的 sitemap 里躺着 1414 条 URL，爬虫一条都拿不到。

三、为什么 robots.txt 放行了也没用

这是最多人踩的认知误区。

我们检查过，这个站的 robots.txt 是标准的 Allow: /，全放行，一点毛病没有。但问题根本不在 robots 层。

访问一个网站，请求要先过 Cloudflare 的边缘节点（WAF/安全层），才轮得到你的服务器。robots.txt 是"你到了我家门口之后，我告诉你哪些房间能进"；而 Cloudflare 的质询是小区保安在大门口就把你拦下了，你压根走不到门口，看不到那张告示。

被拦下之后爬虫拿到的是什么？一张需要执行 JavaScript 才能通过的人机验证页。而：

爬虫不执行 JS

爬虫不会点"我不是机器人"

那张验证页自带

三条叠加的结果是：这个网站在 ChatGPT、Claude、Perplexity 眼里等于不存在，在 Google 眼里等于一张空白的禁止收录页。你花几十万做的内容、结构化数据、多语言 hreflang，全部白做。

四、元凶藏在哪：Cloudflare 的四个排查位

Cloudflare 能发出质询的地方不止一个，而且分散在四个完全不同的菜单里。这也是为什么它这么难被发现——你关掉了一个，还有三个在生效。

按排查顺序：

① 安全性 → 设置 → "I'm Under Attack" 模式

最粗暴的一个。开了它，全站所有访客（包括所有爬虫）一律先过五秒盾。

本案检查结果：禁用状态，不是它。

安全性设置页，框出 "I'm Under Attack 模式：禁用"。

② 安全性 → 设置 → 自动程序流量 → AI 自动程序策略

这里有「搜索 / 代理 / 训练」三类开关，还有一个即将弃用的旧版「阻止 AI 自动程序」。很多人第一反应就是查这里。

本案检查结果：三类全是"允许（不阻止）"，旧版开关也是关的，还是不是它。

⚠️ 但这里要提醒一句：Cloudflare 公告这套 AI 策略将于2026 年 9 月 15 日取代旧版「阻止 AI 自动程序」服务。如果你之前只关了旧版开关，届时要回来确认新策略的三个选项。

自动程序流量设置页，框出「搜索 / 代理 / 训练」三个"允许"状态。

③ 安全性 → 安全规则 → 自定义规则 ← 本案元凶在这里

这是最隐蔽的一层，也是外包建站公司查五六次都没查出来的地方。因为它不是一个开关，而是一张有顺序、有优先级的规则表。

打开一看，这个站有两条规则：

问题一目了然：

第 1 条本来是给爬虫开的"绿色通道"，但它被人禁用了。于是所有流量都直接掉进第 2 条的质询关卡。

而 AI 爬虫和搜索引擎爬虫，绝大多数跑在数据中心 IP 上，威胁分数天然偏高，必然触发 > 10 这个条件；它们又不会做 JS 验证，于是全军覆没。

这条 skip 规则是谁、什么时候、为什么被禁用的，已经不可考了。但这正是它可怕的地方——它不需要谁配置错，只需要有人手滑点一下"禁用"，网站就对全世界的 AI 关门了，而且没有任何报警。

④ Super Bot Fight Mode（Pro 及以上套餐）

这是第四个坑，也是一个重要的补充事实：Pro 计划下，自定义规则的 skip 管不到 Super Bot Fight Mode。

我们后续深挖后台数据发现，这个站还有一层 SBFM 在工作：sbfm_definitely_automated: managed_challenge（明确自动化流量 → 托管质询），24 小时内拦截 3.26 万次。

好消息是它的另一项配置 sbfm_verified_bots: allow——已验证爬虫直接放行。所以修好第 3 层之后，主流爬虫全部畅通。

但如果你的站 SBFM 里"已验证爬虫"不是 allow，那就是第四个必须处理的地方。

五、我们只改了一处

把 allow-search-engine 规则的状态从「已禁用」切回「活动」，保存。

就这一步。没有关闭任何安全防护，没有降低任何安全等级：

Cloudflare 已验证爬虫（Google、Bing、GPTBot、ClaudeBot、OAI-SearchBot、Applebot 等）→ 走绿色通道，跳过质询

普通可疑流量 → 依然被第 2 条规则照常质询

安全性一点没降，只是把该放的放了。

六、怎么验证真的修好了（这里有个大坑）

❌ 错误做法：在自己电脑上用 curl 伪装成 GPTBot

curl -A "GPTBot/1.0" https://你的域名/

这个方法永远测不准。

因为 Cloudflare 识别"已验证爬虫"靠的是IP 反查 + ASN，不是 User-Agent 字符串。你在自己家宽带上把 UA 改成 GPTBot，Cloudflare 一查 IP 根本不是 OpenAI 的段，照样判定为伪装者，照样质询。

改完之后 curl 依然 403，是正常现象，不代表没修好。很多人卡在这一步，误以为改了没用，然后去把安全设置全关了——那才是真的出事。

✅ 正确做法（三选一，建议都做）

1. 看 Cloudflare 自己的安全事件日志（最快，几分钟就能验证）

到「安全性 → 事件」，按动作筛选 skip。因为这条 skip 规则之前是禁用的，日志里任何一条 skip 记录都必然发生在修改之后，这是最干净的因果证据。

本案修改后 3 小时内的实际放行记录：

2. 看 AI Crawl Control 指标里的"失败的请求"

修改前的数据触目惊心：过去 7 天 AI 爬虫共15.7 万次请求，其中1.4 万次失败（全部是被质询挡掉的）。修改后应该趋近于零。

3. 用 Google Search Console 的「网址检查 → 测试实际网址」

这是唯一能确认真 Googlebot 待遇的权威方式。

七、给运营的三条提醒

第一，上 Cloudflare（或任何 CDN/WAF）之后，必须做一次爬虫可达性验证。

这件事没人会提醒你。建站公司管交付，安全服务商管防护，中间这个缝隙里躺着的就是你的自然流量。上线当天测一次，之后每季度复查一次。

第二，把"AI 引用变少了""收录掉了"当成技术信号，不要当成内容问题。

本案客户最早的感知就是这句话，但所有人第一反应都是去改内容、加文章。内容侧折腾三个月，不如去后台点一个开关。

第三，别信"我查过了没问题"，要信日志。

一个开关是不是开着，一眼就能看到；但一张有顺序的规则表里，某条规则被禁用了——这需要真的逐条点开看。本案建站公司回复了五六次"没问题"，问题却一直在第一行躺着。

判断标准只有一个：拿出 Cloudflare 安全事件日志里的 skip 记录，或者 GSC 的实际抓取测试结果。拿不出证据的"没问题"，等于没查。

最后

这次排查从发现症状到定位修复，实际耗时不到两小时，改动只有一个开关的状态。

但在此之前，这个网站已经对全世界的搜索引擎和 AI 关了三个月的门。

这大概是外贸站里投入产出比最高、也最容易被忽略的一次检修。建议每一位把网站挂在 Cloudflare 上的朋友，今天就去点开「安全性 → 安全规则 → 自定义规则」看一眼。两分钟的事。