如果你想判断 AI crawler 到底值不值得放行，先守住一条底线：相信已验证的日志，不要相信截图、传闻或单纯的 user-agent 文本。
Google 官方文档明确建议用反向 DNS 或 Google 公布的 IP 范围验证 Googlebot。OpenAI 官方文档把搜索、训练和用户触发访问拆成不同 crawler。Cloudflare AI Crawl Control则提供请求量、允许请求量、数据传输、热门路径和状态码分布。把这三层证据放在一起，你才能决定该放行、收窄、限流还是屏蔽。
这篇文章给你一套可执行的日志分析工作流，避免把真实 bot、伪造字符串和用户触发访问混为一谈。
每类数据源分别能告诉你什么
不要把所有 dashboard 当成一回事。
| 数据源 | 最适合回答什么 | 它缺什么 |
|---|---|---|
| 原始服务器或 edge 日志 | 谁在什么时间请求了什么 URL、返回了什么状态码、消耗了多少字节 | 需要自己清洗和验证 bot 身份 |
| Cloudflare AI Crawl Control | 请求量、允许请求量、edgeResponseBytes、状态码分布、热门路径、crawler/operator 过滤、付费版 referrer | 它是产品分析层，不是原始 origin 日志替代品 |
| Search Console Crawl Stats | Google 在你站点上的抓取历史，包括请求数、下载大小、响应时间、抓取目的和 Googlebot 类型 | 只看 Google，且只适用于 root-level property， totals 也可能和你自己的日志不同 |
robots.txt 规则 | 你声明了什么抓取策略 | 规则本身不能证明 crawler 是否遵守，也不能证明流量值不值得服务 |
两个限制需要先写清楚：
- Search Console Crawl Stats讲的是 Google 在你网站上的抓取历史，不覆盖 OpenAI 或其他 operator。
- Cloudflare 的 robots.txt violations 视图会拿你当前规则去比过去的请求，所以新加的规则可能把历史上原本合法的请求也标成“违规”。
如果你手上只有一个数据源，先用起来；如果你要据此做策略决策，至少要把日志和一个验证层配在一起看。
第 1 步：先拉一段干净的 7 天或 30 天窗口
不要一上来就拉全年的日志。
优先使用这些输入：
- Web 服务器访问日志
- CDN edge logs
- Cloudflare AI Crawl Control 指标
- 负载均衡日志
- Search Console Crawl Stats 作为 Google 专属背景
第一次分析建议只做这几件事：
- 只保留生产环境 host。
- 去掉健康检查和内部监控流量。
- 把 HTML 页面请求和静态资源分开。
- 统一到一个时区。
- 把
/与/zh/之类的语言目录拆开看。
这样你才有一段可以周周复盘的窗口。
第 2 步：先验证身份，再相信标签
这是最容易偷懒，也最容易做错策略的一步。
验证 Googlebot
Google 的 crawler 文档明确说，验证 Googlebot 最稳妥的方式是反向 DNS 或与 Google 公布的 IP 范围比对。不要看到日志里的 Googlebot 字符串就直接当真。
可以先从 shell 做最基础的验证：
host 66.249.66.1
dig -x 66.249.66.1 +short
如果反向解析结果落在 googlebot.com、google.com 或 googleusercontent.com 这类 Google 主机名下，还要再确认这个主机名能正向解析回同一个 IP，才算完成验证。
验证 OpenAI crawlers
OpenAI 的 crawler 文档把不同访问目的拆成不同 user agent：
| User agent | OpenAI 官方定义 | 日志里为什么要分开看 |
|---|---|---|
OAI-SearchBot | 用于 ChatGPT 搜索结果中的网页发现与展示 | 这才是和 ChatGPT 搜索可见性最直接相关的 crawler |
GPTBot | 抓取可能用于改进生成式基础模型的内容 | 训练用途不要和搜索用途混在一起判断 |
ChatGPT-User | 用户在 ChatGPT 或 Custom GPT 中主动触发的抓取 | 这不是自动全网抓取，robots.txt 也未必适用 |
OpenAI 也在同一页文档中公布了这些 crawler 的 IP ranges。真正做放行或屏蔽决策时，应该同时验证 crawler 角色和来源 IP，而不是只看 user-agent。
能用 verified bot 元数据时，就别只靠字符串
如果你的 CDN 或 edge provider 能提供 verified bot 元数据，优先用它。
Cloudflare AI Crawl Control 的 GraphQL 文档明确区分了：
userAgent_like：可被伪造botDetectionIds_hasany：Cloudflare 标注为可靠验证
日志分析也应该照这个顺序来：先用已验证 detection，再用原始字符串做兜底。
第 3 步：保留真正支持决策的字段
每条请求建议至少保留这些字段：
| 字段 | 作用 |
|---|---|
| 时间戳 | 识别抓取高峰，并对比策略改动前后 |
| Host | 区分生产、预发和多语言 host |
| 请求路径 | 判断 crawler 在抓 canonical 页面还是垃圾 URL |
| Query string | 发现参数型和 faceted crawl 浪费 |
| User agent | 给 crawler 初步分组 |
| Verified bot 或 detection ID | 区分真实身份和伪造字符串 |
| 状态码 | 衡量成功率和错误率 |
| 返回字节数 | 计算抓取成本 |
| Referrer | 在有值时识别用户触发访问 |
| Cache 状态或 edge 结果 | 判断 CDN 是否挡住了 origin 压力 |
| IP 地址 | 在没有 verified metadata 时支持 bot 验证 |
如果你使用 Cloudflare，可以把自己的分析口径对齐到它文档里明确提供的字段和表：
- Analyze AI traffic里有 total requests、allowed requests、unsuccessful requests、
edgeResponseBytes、status-code distribution、top referrers 和 most popular paths。 - GraphQL API里可按 host、path、状态码范围、user agent、referrer host 和 verified detection IDs 过滤。
第 4 步：先做一张每周都能复用的汇总表
如果你还没有正式报表层，先从一个 7 天窗口开始。
下面这张表是示例视图，不是 Fennec 生产数据：
| Crawler | 请求数 | 2xx 比例 | 主要路径模式 | 返回字节 | 建议动作 |
|---|---|---|---|---|---|
Googlebot | 4,820 | 98.7% | canonical 文章与文档页 | 1.4 GB | 放行并监控 |
OAI-SearchBot | 640 | 97.8% | 公开博客与功能页 | 214 MB | 放行，并复查落地页 |
GPTBot | 1,120 | 95.1% | 博客页加参数 URL | 690 MB | 收窄低价值路径 |
ChatGPT-User | 74 | 100.0% | 深链到具体指南页 | 19 MB | 保持公开页面健康 |
未知 Googlebot 字符串 | 910 | 82.4% | 错误页与异常参数混杂 | 508 MB | 先验证再判断 |
只要你先把这张表整理出来，团队讨论就会从“要不要喜欢这个 bot”变成“这个已验证 crawler 到底抓了什么、花了多少成本、该不该继续服务它”。
第 5 步：查询时先用已验证流量
如果日志已经进了数仓，优先按已验证标识来查。
对于 Cloudflare 场景，官方 GraphQL 示例给了两种思路：
- 用
botDetectionIds_hasany查可靠验证过的 crawler - 只有拿不到 detection ID 时，才用
userAgent_like
下面这个查询就是按这个思路写的：
{
viewer {
zones(filter: { zoneTag: "<ZONE_ID>" }) {
httpRequestsAdaptiveGroups(
filter: {
datetime_geq: "2026-07-19T00:00:00Z"
datetime_leq: "2026-07-26T00:00:00Z"
requestSource: "eyeball"
botDetectionIds_hasany: [123815556, 132995013, 126255384]
}
limit: 5000
) {
count
dimensions {
datetimeHour
botDetectionIds
clientRequestHTTPHost
}
sum {
edgeResponseBytes
}
}
}
}
}
如果你用的是 BigQuery、ClickHouse、Athena 或其他数仓，可以先从最基础的汇总开始：
SELECT
verified_bot,
COUNT(*) AS requests,
ROUND(100 * AVG(CASE WHEN status BETWEEN 200 AND 299 THEN 1 ELSE 0 END), 1) AS rate_2xx,
SUM(bytes_sent) AS bytes_served
FROM edge_logs
WHERE ts >= CURRENT_TIMESTAMP - INTERVAL '7 days'
AND host = 'www.example.com'
GROUP BY verified_bot
ORDER BY bytes_served DESC;
再把真正消耗抓取预算的路径排出来：
SELECT
verified_bot,
request_path,
COUNT(*) AS requests,
SUM(bytes_sent) AS bytes_served,
ROUND(100 * AVG(CASE WHEN status BETWEEN 200 AND 299 THEN 1 ELSE 0 END), 1) AS rate_2xx
FROM edge_logs
WHERE ts >= CURRENT_TIMESTAMP - INTERVAL '7 days'
AND host = 'www.example.com'
GROUP BY verified_bot, request_path
ORDER BY bytes_served DESC
LIMIT 50;
如果你手里没有 verified bot 字段，就用当前最干净的识别层替代，并在汇总里明确写出限制。
第 6 步：重点看四类信号，不只看抓取量
把 crawler 分组清洗好以后，重点评估这四类运行信号：
| 信号 | 健康模式 | 风险模式 |
|---|---|---|
| URL 质量 | canonical 页面、文档、博客、产品页 | 参数页、搜索结果页、后台路径、重复 URL |
| 响应健康度 | 主要是 200 和少量有意义的 301 | 大量 404、5xx、重定向循环 |
| 成本 | 适中的 HTML 字节消耗 | 大量媒体下载、频繁 cache miss、突发式资源抓取 |
| 业务价值 | 命中可索引且有价值的页面 | 预算主要耗在低价值路径上 |
这样你做的就不是抽象站队，而是运营判断。
第 7 步：把结论落成可执行策略
最后的动作应该比“允许 AI”或“屏蔽 AI”更细。
| 场景 | 更好的动作 |
|---|---|
| 已验证 crawler，URL 健康，成本可控 | 放行并监控 |
| 有价值的 crawler，但重复路径很多 | 放行，但缩窄路径规则 |
| 用户触发访问主要落在公开重要页面 | 保持开放，并提升页面质量 |
| 未验证或明显滥用的流量 | 限流或屏蔽 |
| 高成本抓取主要发生在资源或私有路径 | 只限制这些路径，不要误伤整个公开站点 |
如果你要继续细化训练用途的决策，可以接着看 GPTBot 决策框架。如果要把日志结果和页面控制项对上，再一起检查 Robots.txt Checker、Canonical Checker、Sitemap Checker 和 Technical SEO Audit。
常见误判与失败模式
这几个地方最容易把日志看错：
| 失败模式 | 常见原因 | 更好的检查方式 |
|---|---|---|
| “Googlebot” 流量看起来特别大 | 直接相信原始 user-agent 字符串 | 先做反向 DNS 或 Google IP 范围校验 |
| OpenAI 流量看起来很乱 | 把 OAI-SearchBot、GPTBot、ChatGPT-User 混成一类 | 拆开看搜索、训练和用户触发访问 |
| Cloudflare 在新规则后突然出现大量违规 | dashboard 用当前规则去比历史请求 | 先核对规则生效日期，再判断是否真的不合规 |
| Search Console 数字和日志对不上 | Crawl Stats 只看 Google，且本来就可能和服务器日志不同 | 把它当作 Google 上下文，不要当成全站 crawler 总账 |
| 字节成本看起来过高 | 把静态资源或 cache miss 路径一起算进来了 | 分开看 HTML、媒体、参数页和语言目录 |
每周复查清单
这套清单适合做成固定巡检：
- 导出最近 7 天的 crawler 流量。
- 分开 verified bots 和未验证 user agents。
- 把搜索、训练和用户触发访问拆开。
- 按请求量和字节数排序热门路径。
- 统计每类 crawler 的
2xx、3xx、4xx、5xx比例。 - 对照 canonical 与 sitemap 覆盖。
- 规则改动后一周，用同样窗口复跑一次。
这通常足以抓住最贵的错误：假 bot 流量、重复 URL 浪费、多语言路径异常，以及错误地屏蔽了该放行的内容。
用 Fennec 落地的下一步
如果你想快速从日志发现走到执行动作，建议按这个顺序做：
- 先用 Bot Simulator 复测日志里请求量最高的 5 个 HTML URL。
- 用 Robots.txt Checker 核对抓取规则。
- 用 Canonical Checker 检查重复路径控制。
- 用 Sitemap Checker 检查 sitemap 覆盖。
- 再用 Audit 或 GSC Management 把 crawler 行为和整体索引问题连起来看。
