Cloudflare 放行搜索引擎爬虫:WAF、Bot 与 robots.txt 配置指南

Cloudflare 放行搜索引擎爬虫:WAF、Bot 与 robots.txt 配置指南

作者:maxaeo.cn|发布日期:2026-08-30|更新日期:2026-08-30

Cloudflare 放行搜索引擎爬虫,不是简单把 Googlebot、Bingbot 的 User-Agent 加白名单,而是要让已验证搜索机器人绕过会产生拦截、质询或限速的安全规则,同时保留对恶意爬虫的防护。

Cloudflare 放行搜索引擎爬虫的规则链路示意图

什么情况下需要放行搜索引擎爬虫?

当 Search Console 出现 403、抓取异常、页面可访问但无法编入索引,或 Bing/Google 抓到的是验证页、验证码页时,就应检查 Cloudflare 是否误拦。

常见触发点有四类:

  1. 开启 Bot Fight Mode、Super Bot Fight Mode 后,爬虫被 JavaScript 挑战拦住。
  2. WAF 自定义规则按国家、ASN、请求频率或 User-Agent 误伤。
  3. Rate Limiting 对爬虫批量抓取过于敏感。
  4. robots.txt 放行了爬虫,但 Cloudflare 网络层仍然拦截。

Google 官方说明,robots.txt 主要用于管理爬取流量,不适合作为隐藏页面的索引控制手段;如果爬虫在到达源站前已被 WAF 拦下,robots.txt 写得再正确也不会生效,可参考 Google Search Central 的 robots.txt 说明

放行的核心原则:验证身份,不信任 UA

正确做法是优先使用 Cloudflare 的 Verified Bots 或 bot category 字段,而不是只匹配 User-Agent 字符串。UA 很容易伪造,验证字段更适合生产环境。

Cloudflare 文档将 Verified Bot 定义为经过确认、会如实标识身份且行为不过度滥用的机器人,其中包括搜索引擎爬虫、监控服务等,见 Cloudflare Verified Bots 文档

推荐优先级如下:

目标 推荐匹配方式 不推荐方式
放行搜索引擎 cf.verified_bot_category eq "Search Engine Crawler" 只写 contains "googlebot"
放行所有可信机器人 cf.client.bot 放开所有 bot 流量
排查单个爬虫 结合日志、IP、反向 DNS、Cloudflare 字段 仅看访问日志里的 UA
控制 AI 抓取 按搜索、训练、助手用途分层 一键全封 AI bot

如果站点还涉及 AI 搜索抓取,可继续看 AI 爬虫访问被拦截的排查方法,避免传统搜索放行了,AI 搜索信源却仍然被挡在 WAF 外。

Cloudflare WAF 中怎样配置跳过规则?

最稳妥的配置是:新建一条靠前执行的 Skip 规则,让已验证搜索引擎爬虫跳过会误伤的安全动作,但不要跳过全部安全能力。

可使用的表达式思路:

cf.verified_bot_category eq "Search Engine Crawler"

或在需要更宽松时使用:

cf.client.bot

动作建议选择 Skip,跳过对象优先限于:

  1. WAF 自定义规则;
  2. Rate Limiting;
  3. Bot Fight Mode 或 Super Bot Fight Mode 相关挑战;
  4. Browser Integrity Check 等可能返回挑战页的功能。

Cloudflare 官方也给出过使用 cf.client.bot 允许搜索引擎等已验证机器人的 WAF 示例,见 Cloudflare 允许 Verified Bots 的 WAF 用例

这里的关键不是“全站放开”,而是最小跳过:只让可信搜索爬虫绕过拦截型规则,仍保留缓存、DDoS 防护和必要的安全检查。

Bot Fight Mode 误伤时如何最小修复?

Bot Fight Mode 误伤时,先不要关闭整套 Cloudflare 防护。更安全的顺序是:查 Security Events,再建 Skip 规则,最后复测 Googlebot 与 Bingbot。

排查路径:

  1. 进入 Cloudflare 后台的 Security Events。
  2. 筛选 Googlebot、Bingbot、Applebot 等爬虫请求。
  3. 查看触发了哪条规则:WAF、Bot、Rate Limiting 还是 Managed Challenge。
  4. 在对应规则前添加 Verified Search Bots 的 Skip 条件。
  5. 用 Search Console URL 检查工具、Bing Webmaster Tools 和日志重新验证。

如果问题集中在 Bot Fight Mode,可参考站内的 Cloudflare Bot Fight Mode 放行最小修复方案。如果是 WAF 规则泛化导致,可对照 WAF 误伤机器人流量的排查清单逐项定位。

Cloudflare WAF 与 Bot Fight Mode 对搜索爬虫的误拦排查表

robots.txt 要怎么配合 Cloudflare?

robots.txt 负责表达“允许抓哪些 URL”,Cloudflare 负责决定“请求能不能到站点”。两者必须一致,否则会出现协议放行但网络层拦截的假阳性。

一个基础写法如下:

User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

如果你想限制训练型 AI 爬虫,不要误伤搜索型机器人。Google 的爬虫体系中,不同 user-agent token 对应不同产品;例如 Googlebot 与 Google-Extended 的用途不同,可查看 Google 常见爬虫列表

对希望进入 AI 搜索回答的品牌来说,还应单独评估 AI 搜索爬虫、训练爬虫和用户触发型抓取。国内平台场景可参考 国产 AI 爬虫 UA 识别与放行配置

一手排查框架:三层放行矩阵

实操中,单看某一条规则很容易漏判。MaxAEO 在做 SaaS 官网 AI 搜索可见性诊断时,更推荐用“三层放行矩阵”记录每类爬虫的真实状态。

层级 要回答的问题 验证方式
协议层 robots.txt 是否允许抓取? 访问 /robots.txt,检查对应 User-agent
网络层 Cloudflare 是否返回 200? 看 Security Events、边缘状态码、挑战记录
引用层 搜索或 AI 是否实际引用页面? 查索引、AI 回答、引用来源和品牌提及

这个框架的价值在于:它不把“能访问”误判为“能被引用”,也不把“robots.txt 正确”误判为“爬虫一定可抓”。尤其在 AEO/GEO 场景下,最终要看的不是爬虫请求有没有来,而是品牌页面是否成为 AI 回答的可信信源。

MaxAEO 国内版覆盖豆包、DeepSeek、腾讯元宝、通义千问、文心一言、Kimi 等 9 个中国大陆 AI 平台,可监测品牌提及率、排序、情绪评价与引用来源。若需要把搜索爬虫排查延伸到 AI 搜索,可用 MaxAEO 官网 的免费诊断先建立基线。

验证是否真正放行成功

放行成功的标准不是规则保存成功,而是爬虫请求在同一 URL 上获得稳定 200,并且页面内容不是验证码、验证页或空壳缓存页。

建议按这个顺序复测:

  1. 用 Google Search Console 的 URL 检查工具测试重点页面。
  2. 用 Bing Webmaster Tools 提交并检查抓取状态。
  3. 在 Cloudflare Security Events 中确认没有 Block、Challenge、JS Challenge。
  4. 在源站日志或边缘日志中查看状态码、UA、路径和时间。
  5. 观察 3–7 天索引、抓取频次和 AI 引用变化。

如果你正在做 AI 搜索优化,还要复测同一批问题下品牌是否被提及、排序是否变化、引用来源是否转向官网或权威页面。MaxAEO 支持每天自动监测 AI 平台回答变化,并保留 AI 原始回答,便于回溯具体句子。

Cloudflare 放行搜索引擎爬虫后的日志与索引验证流程

常见问题

只放行 Googlebot 和 Bingbot 够吗?

不一定。传统 SEO 至少要考虑 Googlebot、Bingbot、Applebot、DuckDuckBot 等;如果品牌依赖 AI 搜索,还要区分 AI 搜索抓取、训练抓取和用户触发型抓取。

可以直接按 User-Agent 放行吗?

不建议作为唯一条件。User-Agent 可伪造,生产环境应优先使用 Cloudflare Verified Bots、bot category、IP 验证或反向 DNS,必要时再叠加 UA 精细筛选。

Cloudflare 放行后为什么还是不收录?

放行只解决“能不能抓”的问题。页面质量、重复内容、noindex、canonical、内部链接、站点权威度和搜索需求都会影响收录。要同时检查技术可抓取性与内容价值。

AI 爬虫和搜索引擎爬虫要用同一套规则吗?

不建议。搜索引擎爬虫通常用于索引和检索,AI 爬虫可能用于搜索、摘要、训练或助手访问。更稳妥的做法是按用途分层:搜索放行、训练审慎、异常频率限速。

如何判断是 Cloudflare 而不是源站拦截?

看响应头、状态码、Cloudflare Security Events 与源站日志。如果 Cloudflare 有 Block 或 Challenge 记录,而源站没有对应请求,说明请求在边缘层被处理;如果源站也有 403,则继续查服务器、防盗链或应用规则。