作者:maxaeo.cn|发布日期:2026-08-30|更新日期:2026-08-30
Cloudflare 放行搜索引擎爬虫,不是简单把 Googlebot、Bingbot 的 User-Agent 加白名单,而是要让已验证搜索机器人绕过会产生拦截、质询或限速的安全规则,同时保留对恶意爬虫的防护。

什么情况下需要放行搜索引擎爬虫?
当 Search Console 出现 403、抓取异常、页面可访问但无法编入索引,或 Bing/Google 抓到的是验证页、验证码页时,就应检查 Cloudflare 是否误拦。
常见触发点有四类:
- 开启 Bot Fight Mode、Super Bot Fight Mode 后,爬虫被 JavaScript 挑战拦住。
- WAF 自定义规则按国家、ASN、请求频率或 User-Agent 误伤。
- Rate Limiting 对爬虫批量抓取过于敏感。
- 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,跳过对象优先限于:
- WAF 自定义规则;
- Rate Limiting;
- Bot Fight Mode 或 Super Bot Fight Mode 相关挑战;
- 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。
排查路径:
- 进入 Cloudflare 后台的 Security Events。
- 筛选 Googlebot、Bingbot、Applebot 等爬虫请求。
- 查看触发了哪条规则:WAF、Bot、Rate Limiting 还是 Managed Challenge。
- 在对应规则前添加 Verified Search Bots 的 Skip 条件。
- 用 Search Console URL 检查工具、Bing Webmaster Tools 和日志重新验证。
如果问题集中在 Bot Fight Mode,可参考站内的 Cloudflare Bot Fight Mode 放行最小修复方案。如果是 WAF 规则泛化导致,可对照 WAF 误伤机器人流量的排查清单逐项定位。

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,并且页面内容不是验证码、验证页或空壳缓存页。
建议按这个顺序复测:
- 用 Google Search Console 的 URL 检查工具测试重点页面。
- 用 Bing Webmaster Tools 提交并检查抓取状态。
- 在 Cloudflare Security Events 中确认没有 Block、Challenge、JS Challenge。
- 在源站日志或边缘日志中查看状态码、UA、路径和时间。
- 观察 3–7 天索引、抓取频次和 AI 引用变化。
如果你正在做 AI 搜索优化,还要复测同一批问题下品牌是否被提及、排序是否变化、引用来源是否转向官网或权威页面。MaxAEO 支持每天自动监测 AI 平台回答变化,并保留 AI 原始回答,便于回溯具体句子。

常见问题
只放行 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,则继续查服务器、防盗链或应用规则。
