外贸站被安全插件拦截爬虫时，怎么做白名单和风险评估？

外贸站被安全插件拦住 AI 爬虫时，第一步不是把爬虫加入白名单，而是确认拦截发生在哪一层、请求要访问什么路径、身份证据够不够。公开产品页可以评估最小范围放行；后台、登录、提交接口、上传目录和客户资料不能跟着一起放开。

这篇只讲安全插件 AI 爬虫白名单评估。
不写某个插件的安装教程，也不把白名单配置写成排名、收录、AI 引用或询盘保证。

先判断是不是安全插件拦的

浏览器能打开，爬虫请求却返回 403、429、挑战页或空 HTML，不代表问题一定来自 WordPress 安全插件。

可能的拦截层包括：

先做一个普通请求和一个 User-Agent 对照请求：

SITE="https://www.example.com"
PAGE="$SITE/products/industrial-valve/"

curl -sSIL -L "$PAGE" |
  grep -Ei '^(HTTP/|location:|content-type:|server:|cf-ray:)'

curl -sSIL -L \
  -A "GPTBot/1.0" \
  "$PAGE" |
  grep -Ei '^(HTTP/|location:|content-type:|server:|cf-ray:)'

这个对照只用于复现差异。
User-Agent 是请求头里的字符串，不能单独证明请求确实来自 GPTBot、ClaudeBot、PerplexityBot 或 Googlebot。

第二步：把“身份线索”和“身份验证”分开

建议把证据分成三层：

Google 官方建议通过反向 DNS 和正向 DNS 验证 Googlebot，而不是只看 User-Agent。Cloudflare 的 Verified Bot 也只是 Cloudflare 的验证信号，不等于绝对安全来源。

Googlebot 的验证可以做成只读检查：

IP="203.0.113.10"

PTR="$(dig +short -x "$IP" PTR | sed -n '1p' | sed 's/\.$//')"
printf 'ptr=%s\n' "${PTR:-NONE}"

if printf '%s\n' "$PTR" | grep -Eq '(^|\.)(googlebot\.com|google\.com)$'; then
  dig +short A "$PTR"
  dig +short AAAA "$PTR"
else
  printf 'not_verified_by_google_dns\n'
fi

这段命令只是示意验证流程。
不要把示例 IP 当成真实 Googlebot 地址，也不要把它套用于 OpenAI、Perplexity 或 Anthropic。

第三步：先查安全事件，再谈白名单

在安全插件或 CDN/WAF 面板里，至少记录这些字段：

如果插件有 JSON 日志，可以只筛事件字段，不把 Cookie、Authorization 或客户表单内容复制出来：

EVENT_LOG="/path/to/security-events.jsonl"

rg -Ein \
  'GPTBot|OAI-SearchBot|ClaudeBot|PerplexityBot|Googlebot|blocked|challenge|rate.?limit|403|429' \
  "$EVENT_LOG"

如果安全事件里有记录，而源站 access log 没有对应请求，说明请求可能在边缘层就结束了。
如果源站收到请求但返回 403，再查服务器、WordPress 或应用层。

第四步：把 URL 按风险分层

白名单不要按“所有 AI 爬虫”设计，要按“具体来源 + 具体路径 + 具体方法”评估。

用路径分层时，不要让规则只匹配 bot 字符串。
例如下面是风险记录，不是某个安全插件可以直接粘贴的通用配置：

exception_id: public-content-read-only-001
method:
  - GET
  - HEAD
path:
  - /products/
  - /faq/
  - /case-studies/
exclude:
  - /wp-admin/
  - /login
  - /api/submit/
  - /uploads/
action: observe
expiry: 2026-09-30
rollback: remove_exception_and_restore_original_rule

不同安全插件的字段和优先级不一样。
真正上线前，必须把这份决策映射到当前插件的实际规则，并先在测试或观察模式验证。

第五步：用五个维度评估风险

不编造统一的“AI 爬虫风险分数”，用理由评估更可靠。

可以用三档判断：

risk_level,signal,interpretation,action
low,"公开产品页 GET 返回 200，规则误报证据明确","只读公开内容被误拦","观察后做最小路径例外"
medium,"公开页返回 403/429，身份只有 User-Agent 线索","可能误报，也可能是异常流量","先记录、限路径、复测负载"
high,"登录、上传、提交接口出现放行请求","可能接触敏感数据或改变状态","不建立 AI crawler 例外"
high,"公开页返回 5xx","源站或应用故障","按故障流程处理，不先改白名单"

第六步：分阶段放行，不要一步到位

建议按四个阶段做：

1. 观察：记录命中规则、路径、方法、状态码和请求量。
2. 复现：用普通浏览器 UA 和 crawler UA 对照，确认差异。
3. 最小例外：只覆盖已确认的公开路径和只读方法。
4. 复测回滚：检查正文、事件、源站日志；异常就撤销例外。

复测命令可以固定下来：

SITE="https://www.example.com"

for path in \
  "/" \
  "/products/" \
  "/products/industrial-valve/" \
  "/faq/" \
  "/case-studies/"
do
  for ua in "Mozilla/5.0" "GPTBot/1.0" "PerplexityBot" "ClaudeBot"; do
    printf '%s\t%s\t' "$ua" "$path"
    curl -sS -L \
      -A "$ua" \
      -o /dev/null \
      -w '%{http_code}\t%{content_type}\t%{url_effective}\n' \
      "$SITE$path"
  done
done

模拟 UA 的结果只能证明“这个请求在当前规则下表现如何”。
它不能证明真实平台身份，也不能证明平台已经抓取、索引或引用。

第七步：给白名单设置失效和撤销条件

任何例外都要有记录：

出现这些信号时，不要等月度巡检：

• 公开页突然变成 403、429 或挑战页
• 例外规则命中后台、上传或提交路径
• 请求量明显异常，源站资源受影响
• IP、规则顺序或安全插件配置发生变化
• 白名单对象无法通过平台或日志证据解释

41 的主线不是“怎么放行更多 AI 爬虫”，而是“怎么证明这次例外只影响公开、只读、可回滚的范围”。

参考资料

• Cloudflare: Verified bots
• Cloudflare: WAF concepts
• Cloudflare: Security Events
• Cloudflare: User Agent Blocking
• Google: Verify Googlebot and other Google crawlers
• Google: Introduction to robots.txt
• OpenAI: Overview of OpenAI crawlers
• Perplexity Docs: Perplexity crawlers
• Anthropic Help Center: Anthropic crawlers and robots.txt