Cloudflare规则怎么检查？避免把AI爬虫当成异常流量拦掉

robots.txt 没挡，不代表 AI 爬虫真的拿到了页面。外贸站用了 Cloudflare 后，要重点查 WAF、Bot 规则、Rate Limiting、User-Agent Blocking、AI Crawl Control 和 Security Events；公开产品页应该能稳定返回真实 HTML，后台、提交接口和客户资料才应该严控。

这篇不讲“Cloudflare 会不会影响 SEO”的概念。
只讲一个很具体的问题：Cloudflare规则怎么检查，避免把 AI 爬虫当成异常流量拦掉。

先准备一组外贸核心 URL

不要一上来查全站。先抽样这些页面：

如果这些页面对普通浏览器能打开，但对 crawler User-Agent 返回 403、429、挑战页或空 HTML，就要查 Cloudflare 规则，而不是只改 WordPress。

第一步：先看响应头和状态码

先查普通访问：

URL="https://www.example.com/products/industrial-valve/"

curl -sS -o /dev/null \
  -D - \
  -w "\nhttp_code=%{http_code}\nremote_ip=%{remote_ip}\ntime_total=%{time_total}\n" \
  "$URL"

再用一个常见搜索爬虫 User-Agent 做对照。注意：这只是模拟请求，用来检查规则差异，不能证明真实 Googlebot 身份。

URL="https://www.example.com/products/industrial-valve/"
UA_GOOGLEBOT="Mozilla/5.0 AppleWebKit/537.36 \
KHTML, like Gecko; compatible; Googlebot/2.1; \
+http://www.google.com/bot.html"

curl -sS -o /dev/null \
  -D - \
  -A "$UA_GOOGLEBOT" \
  -w "\nhttp_code=%{http_code}\ncontent_type=%{content_type}\ntime_total=%{time_total}\n" \
  "$URL" | \
  grep -Ei '^(HTTP/|cf-ray:|server:|location:|content-type:|http_code=)'

重点看这些信号：

如果 cf-ray 存在，后面就可以拿 Ray ID 去 Cloudflare 面板里反查规则。

第二步：确认返回的是正文，不是挑战页

有些挑战页不一定只靠状态码能看出来。
所以要看 HTML 前几行：

curl -sS -L \
  -A "$UA_GOOGLEBOT" \
  "$URL" | \
  sed -n '1,60p'

如果看到的是 Cloudflare challenge、captcha、checking your browser、turnstile、access denied，而不是产品标题、参数、FAQ 正文，那就说明爬虫拿到的不是营销页面正文。

外贸 AI SEO 里，这一步很关键。
AI 搜索相关 crawler 需要读公开内容；如果拿到的是挑战页，它没有材料判断你的产品、案例和供应商信息。

第三步：去 Cloudflare Security Events 查证据

Cloudflare 排查不要凭感觉改规则。
建议按下面字段查：

Cloudflare Security Events 过滤条件：

Host:
www.example.com

Path:
/products/industrial-valve/

Action:
Block
Managed Challenge
JS Challenge
Interactive Challenge
Rate Limit

User Agent:
Googlebot
bingbot
GPTBot
OAI-SearchBot
PerplexityBot
ClaudeBot

Ray ID:
<curl_response_cf_ray>

重点记录这些字段：

如果 Security Events 有拦截记录，而源站 access log 没有对应请求，说明请求没有到达 WordPress 或源站应用。
这时改主题、改 SEO 插件通常没用。

第四步：逐项检查 Cloudflare 规则位置

这里不要直接写“放行所有 AI 爬虫”。
更稳妥的做法是：公开营销页面减少误拦，提交、后台、客户资料继续严格保护。

还有一个边界要写清楚：即使你在 AI Crawl Control 里允许某些 AI crawler，也要回头检查 WAF Custom Rules、Rate Limiting 和 Bot 相关规则。前置规则如果先 Block 或 Challenge，请求仍可能拿不到页面正文。

第五步：必要时用 Trace 做规则模拟

Cloudflare Trace 可以帮助你模拟某个 URL、User-Agent、请求头、地区等条件下会命中哪些规则。它适合做“规则会不会命中”的排查，不等于真实 crawler 已经访问。

可以把 Trace 结果和真实流量分开记录：

如果账户支持 Bot Management 字段，可以关注 verified_bot、bot score 或 bot 类别这类线索。不同 Cloudflare 套餐和产品能力不同，写排查 SOP 时不要假设每个站都有同样字段。

第六步：做一条观察规则，而不是全站白名单

排查阶段可以先用 Log 观察，不要一上来 Skip 全部安全规则。

Cloudflare WAF 自定义规则排查示例：

规则目的：
仅观察搜索和 AI crawler 相关请求，不直接放行。

Expression:
(
  http.host eq "www.example.com"
  and starts_with(http.request.uri.path, "/products/")
  and (
    http.user_agent contains "Googlebot"
    or http.user_agent contains "bingbot"
    or http.user_agent contains "GPTBot"
    or http.user_agent contains "OAI-SearchBot"
    or http.user_agent contains "PerplexityBot"
  )
)

Action:
Log

这类规则的价值是收集证据：哪些 URL 被请求、命中了什么策略、返回什么状态。
等证据稳定后，再决定是否对某些公开页面做精确例外。

第七步：把公开内容和敏感动作分层

外贸站常见错误，是用同一套 Cloudflare 策略处理所有路径。

公开内容层：
/products/
/category/
/case-studies/
/about/
/factory/
/faq/
/request-a-quote/

目标：
GET 请求返回 200 和完整正文。

敏感动作层：
/wp-login.php
/wp-admin/
/api/
/wp-json/forms/
/rfq-submit/
/upload/
/account/
/checkout/

目标：
鉴权、验证码、WAF、限速、日志审计。

公开 RFQ 说明页可以被读取，但 RFQ 提交接口必须保护。
这不是矛盾，是分层。

第八步：记录一个复盘表

注意，表里写的是“User-Agent 线索”。
真实身份还需要结合官方 crawler 文档、IP 验证、DNS 验证或平台工具，不能只凭字符串判断。

容易误判的地方

改完后复测什么

1. 首页、产品页、分类页、FAQ、案例、About、RFQ 说明页是否返回 200。
2. crawler User-Agent 模拟请求是否拿到真实 HTML。
3. Security Events 里是否还有 block、challenge、rate limit。
4. 源站 access log 是否能看到对应请求。
5. 后台、提交接口、上传目录是否仍然被保护。
6. robots.txt 的线上版本是否符合预期。
7. 是否留下 Ray ID、URL、规则名和处理动作，方便下次复盘。

Cloudflare 不是 AI SEO 的敌人。问题通常出在规则太粗：该公开的产品信息被挑战，该保护的提交动作却没有单独处理。把这两层分开，才是外贸站更稳的做法。

参考资料

• Cloudflare AI Crawl Control
• Cloudflare AI Crawl Control with WAF
• Cloudflare Managed robots.txt
• Cloudflare WAF Custom rules
• Cloudflare Security Events
• Cloudflare Trace a request
• Cloudflare Verified bots
• Cloudflare Bot Fight Mode
• Cloudflare User Agent Blocking
• Google: Verify Googlebot and other Google crawlers