“网站不收录，是不是被 Cloudflare 挡了？”——这是排查新站收录时最常被跳过的结论。实际情况是：Cloudflare 确实可能挡住爬虫，但收录失败的原因很多，canonical 写错、noindex 误设、页面返回 404 都可能造成同样的现象。先把具体 URL、请求时间和客户端 IP 对上，再决定要不要动防护规则，才是省时间的顺序。下面的分步流程与判断表，可以对照 光算关于 Cloudflare 拦截谷歌爬虫的排查说明 逐项核对。
第一步：判断请求到底在哪一层失败
在 Search Console 里对受影响的 URL 检查索引记录，然后执行实时测试，记录抓取失败信息和时间。接着到 Cloudflare 的安全事件里查同一时段、同一个主机和路径的动作、规则标识、产品来源与 Ray ID。最后再对照源站日志：被边缘层直接拒绝的请求，可能根本没有到达源站。
几种观察结果对应完全不同的下一步：
- Cloudflare 有对应的 Block 或 Challenge 事件：去看命中的规则、匹配范围和爬虫识别结果。
- 源站直接返回 403，边缘层没有对应拦截：查源站的 WAF、访问控制和应用权限，方向在服务器而不在 CDN。
- 响应是 200，但内容是挑战页或登录页：核对响应正文。状态码正常不代表内容可访问，搜索引擎拿到的是挑战页而不是正文。
- 5xx 或连接超时：排查源站可用性、连接、TLS 和负载，不能自动归因为防火墙。
- 正常 301 到最终 200：检查跳转目标与链路，重定向本身不是拦截证据。
第二步：核实 Googlebot 的身份
User-Agent 是可以伪造的。“包含 Googlebot”只说明这个请求声称自己是 Googlebot，不能证明它真的来自谷歌。官方验证指南给了两类方法：按请求 IP 做反向解析，再对返回的主机名做正向解析并确认 IP 一致；或者把请求 IP 与谷歌公布的相应爬虫 IP 范围做匹配。
检查域名后缀时要匹配完整域边界，不能只搜索字符串“google”。普通爬虫、特殊用途爬虫和用户触发的抓取工具属于不同类别，某次测试工具成功，并不等于所有 Googlebot 访问都已畅通。宽泛地放行谷歌所属的 ASN 或全部云计算地址，也不能代替身份验证。
在 Cloudflare 侧，官方搜索引擎机器人规则示例使用 cf.client.bot 字段来识别已验证的机器人。这个字段涵盖的是已验证机器人，并不等于“只有 Googlebot”；如果业务上需要更小的范围，就要结合所用产品实际支持的条件来配置。
第三步：修正命中的规则，而不是停用全部防护
假设一条按国家触发挑战的自定义规则误伤了已验证的搜索机器人，正确的做法是在这条规则里加入相应的排除条件。如果用 Skip 动作，必须写清楚跳过的是哪些规则或产品、顺序如何、路径是否只限公开页面。不同防护产品和套餐的可跳过能力并不相同，把一条 Skip 规则理解成“无条件绕过一切防护”会留下明显的安全缺口。
动手之前先保存当前的表达式、动作和顺序，确定回滚版本。调整范围应当严格按实际命中的证据来缩小，同时保留后台、登录和敏感接口的访问保护。部署后再检查两类情况：同类请求是否仍然命中挑战，其他异常请求是否仍然受防护。如果边缘层已经放行而源站仍在拒绝，就继续修源站规则，不要反复扩大边缘白名单。
第四步：验证抓取恢复，再观察索引
重新执行实时网址测试，并检查响应 HTML 中的正文、robots 与 canonical，同时观察经过身份核实的真实爬虫后续请求。用命令行把 UA 换成 Googlebot 可以辅助发现那些按 UA 分支处理的问题，但它不能模拟真实的谷歌网络来源，更不能单独作为修复成功的证明。
别忘了 CSS、图片和必要脚本的可访问性。HTML 能打开而关键内容资源受阻，页面渲染仍可能是不完整的。手机与桌面端的响应有差异时，也要核对差异是否符合预期。
抓取成功之后，谷歌仍然要自己决定是否索引和展示。记录修复时间、被改动的原规则、验证过的 URL 和后续日志，不要承诺“解除拦截后固定几小时收录”。如果到时间仍未被索引，可以继续检查站点地图、规范地址与页面内容。
三个不要做的动作
- 不要全站关闭防火墙。它通常既没有必要，也不能解决 canonical、noindex 或内容层面的问题，只是把风险敞口打开。
- 不要只凭“网站不收录”就认定是 CDN 问题。先按上面的四步对齐证据，方向错了，改再多规则也没用。
- 不要用换 UA 的命令行结果当作验收。它只覆盖了 UA 分支这一条路径。
整套流程的关键不在于最后改了几条规则，而在于每一步都有对应的时间、主机、路径和 Ray ID 可以复查。排查记录留得住，下次类似的问题就能从已有证据开始，而不是从零猜。