当团队只看截图、个别测试结果，或者听别人转述某个 bot 的表现时，AI crawler 策略很容易跑偏。
真正稳定的证据层是服务器日志。它能告诉你：到底是谁在请求你的 URL、请求频率如何、返回了什么状态码、你实际提供了多少字节，以及这些抓取行为到底有价值还是只是浪费资源。
这篇文章给你一套可执行的工作流，用日志而不是猜测来判断 AI crawler 流量。
为什么日志比“该不该屏蔽某个 Bot”的争论更重要
Google 明确要求在日志里验证 Googlebot，因为 user-agent 字符串可以被伪造。OpenAI 也明确区分了不同用途的 user agent，例如 GPTBot、OAI-SearchBot 和 ChatGPT-User。Cloudflare 现在则能直接给出 AI crawler 的请求量、放行请求量、传输字节和热门路径等分析。
这意味着你不能只做一个笼统判断。你需要回答这些问题：
- 到底是哪一类 crawler 真正在访问你的网站
- 它们访问的是关键 HTML 页面，还是低价值资源
- 返回状态码是否健康
- 这些抓取带来的是可见性价值、基础设施成本，还是两者都有
如果你只改 robots.txt，你只能看到规则，看不到运行结果。日志分析最好和 Bot Simulator、Robots.txt Checker、Technical SEO 一起使用。
至少要保留哪些日志字段
每条请求建议至少保留这些字段：
| 字段 | 作用 |
|---|---|
| 时间戳 | 识别抓取高峰和日常节奏 |
| 请求路径 | 判断 bot 是否在抓 canonical 页面还是垃圾 URL |
| Query string | 发现参数污染和 faceted crawl 浪费 |
| User agent | 给 crawler 分组 |
| 状态码 | 衡量抓取成功率与失败率 |
| 返回字节数 | 计算抓取成本 |
| Referrer | 在有值时识别用户触发访问 |
| Host | 区分生产、预发和多语言域名 |
| Cache 状态或 edge 结果 | 判断 CDN 是否替你挡住了压力 |
| IP 地址 | 支持 bot 验证 |
如果你现在只有 dashboard 汇总，也可以先开始；如果能导出原始日志，效果会更好。
第 1 步：先拉一段干净的 7 天或 30 天窗口
不要一上来就分析整年的日志。
优先从这些来源拿数据：
- Web 服务器访问日志
- CDN edge logs
- Cloudflare AI Crawl Control 分析
- 负载均衡日志
- Search Console 的 Crawl Stats 报告（补充 Google 专属背景）
第一次分析建议只做这几件事：
- 只保留生产环境 host
- 去掉健康检查和内部监控流量
- 把 HTML 页面请求与静态资源分开
- 全部统一到一个时区
如果你的网站有 / 和 /zh/ 这种语言目录，也要分开看。这样更容易判断 crawler 是否稳定抓取了两个语言版本。
一张可直接开始用的周汇总表（Sample）
如果你还没有现成报表，先从 7 天导出的日志做一张周汇总表。
下面这张表是示例视图，不是 Fennec 生产数据。它展示的是你在改 crawler 策略前，至少应该先整理出来的摘要：
| 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 听起来重不重要”，转到“这类已验证流量的错误率、字节成本和页面价值到底如何”。
第 2 步：按“用途”分组，而不是只按厂商分组
不要把所有流量都塞进一个“AI bots”桶里。
更好用的分组方式是：
| 分组 | 示例 | 核心问题 |
|---|---|---|
| 搜索发现型 crawler | Googlebot、OAI-SearchBot、Bingbot | 这些请求是否支持发现和引用可见性？ |
| 训练型 crawler | GPTBot | 你是否接受这种用途？ |
| 用户触发型 agent | ChatGPT-User | 是否真的有用户通过助手来抓你的页面？ |
| 疑似伪造或未知流量 | 未验证字符串 | 这到底是不是真 crawler？ |
这比“允许 AI”或“屏蔽 AI”更贴近官方文档的实际语义。
做策略判断时，把日志结果和 canonical、sitemap、以及当前 robots 规则 一起看。
第 3 步：先验证身份，再相信标签
很多团队就是在这里偷懒。
Google 建议通过反向 DNS 验证 Googlebot，并再次确认主机名确实属于 Google。原因很简单：日志里伪造 Googlebot 的流量并不少见。
对 OpenAI crawler，也应该先看官方 crawler 文档，以及 OpenAI 公开提供的 IP 范围指引，再决定是否把它当成真实 bot。若你的 CDN 已经提供 verified bot 元数据，应优先使用这个字段，而不是只靠 user-agent 文本匹配。
建议按这个顺序验证：
- CDN 或 edge provider 提供的 verified-bot 字段
- 官方反向 DNS 或 IP range 校验
- 只在兜底时再用 user-agent 字符串匹配
如果一个 crawler 验证不过，就不要拿它的流量来做 SEO 决策。
可直接复用的查询示例
如果你的日志已经进了 BigQuery、ClickHouse、Athena 或其他数仓，可以先跑这种 7 天汇总：
SELECT
user_agent,
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'
AND REGEXP_LIKE(user_agent, 'Googlebot|OAI-SearchBot|GPTBot|ChatGPT-User|Bingbot')
GROUP BY user_agent
ORDER BY bytes_served DESC;
然后把真正消耗抓取预算的路径排出来：
SELECT
user_agent,
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'
AND REGEXP_LIKE(user_agent, 'Googlebot|OAI-SearchBot|GPTBot|ChatGPT-User|Bingbot')
GROUP BY user_agent, request_path
ORDER BY bytes_served DESC
LIMIT 50;
如果你现在还没有数仓，先导出 CSV 也可以。重点不是一开始就把可观测性做到完美，而是先回答三个问题：哪些已验证 crawler 在访问、它们打到了哪些 URL、这些请求带来了多少状态异常和字节成本。
第 4 步：重点看四类信号
把 crawler 清洗干净后，重点评估四类运行信号：
| 信号 | 健康模式 | 风险模式 |
|---|---|---|
| URL 质量 | canonical 页面、文档、博客、产品页 | 参数页、搜索结果页、后台路径、重复 URL |
| 响应健康度 | 主要是 200 和少量有意义的 301 | 大量 404、5xx、重定向循环 |
| 成本 | 适中的 HTML 字节消耗 | 大量媒体下载、频繁 cache miss、突发式资源抓取 |
| 业务价值 | 命中可索引且有价值的页面 | 大多在低价值路径上消耗预算 |
这样一来，你做的就不是抽象辩论，而是运营判断。
第 5 步：用一个简化的 Crawler Action Score
下面这张表适合每周复用：
| 检查项 | 分值 |
|---|---|
| 请求主要落在 canonical HTML 页面 | +2 |
2xx 比例高、5xx 比例低 | +2 |
| 主要内容和多语言目录都按预期被抓取 | +1 |
| 抓取量稳定，不是异常尖峰 | +1 |
| 请求大多 cache 友好 | +1 |
| 流量集中在参数页、重复 URL 或错误页 | -2 |
| 验证结果弱或不确定 | -3 |
| 返回字节成本偏高但价值不高 | -2 |
解释方式：
4分及以上：通常可以放行并持续监控1到3分：可以放行，但要加护栏，例如更细的路径规则或限流0分及以下：优先调查、收紧或直接屏蔽
这个分数模型不会保证你拿到更好的排名或 AI 引用，它只是让 crawler 决策更干净、更少靠感觉。
第 6 步：把日志结果和抓取控制项对上
日志发现只有和页面控制项连起来才有意义。
建议同时检查：
- Robots.txt Checker：确认 allow / disallow 是否冲突
- Canonical Checker：确认是否存在重复路径漂移
- Sitemap Checker：确认 canonical URL 是否缺失或过期
- Audit：发现模板级技术问题
- AI Overview：把抓取权限和引用导向页面联系起来
比如：
- 如果
OAI-SearchBot主要在抓 sitemap 里没有的 URL，先修发现链路。 - 如果
GPTBot把预算花在大量 faceted URL 上，优先收窄路径，而不是直接全站屏蔽。 - 如果用户触发型 agent 访问后落到
404或多跳转链路，先修页面，再谈 crawler 策略。
第 7 步：把结论落成可执行策略
最后的动作应该比“AI 好”或“AI 坏”更细。
更实用的策略通常长这样：
| 场景 | 更好的动作 |
|---|---|
| 有价值的 crawler，URL 健康，成本可控 | 放行并监控 |
| 有价值的 crawler，但重复路径很多 | 放行，但缩窄规则 |
| 用户触发访问主要落在公开重要页面 | 保持开放，并提升页面质量 |
| 未验证或明显滥用的流量 | 限流或屏蔽 |
| 高成本抓取主要发生在资源或私有路径 | 只限制这些路径，不要误伤整个公开站点 |
如果你调整了策略，最好在一周后用同样的日志窗口再跑一次。重点是测效果，而不是改完 robots.txt 就结束。更细的策略判断可以接着看 GPTBot 决策框架。
每周复查清单
这套清单适合做成固定巡检：
- 导出最近 7 天的 crawler 流量
- 分开 verified bots 和未验证 user agents
- 按请求量和字节数排序热门路径
- 统计每类 crawler 的
2xx、3xx、4xx、5xx比例 - 对照 canonical 和 sitemap 覆盖
- 标记高成本路径，决定做 cache、限流或规则调整
- 用 Bot Simulator 复测关键 URL
这套流程通常足以抓住最贵的错误：假 bot 流量、重复 URL 浪费、多语言路径异常，以及错误地屏蔽了该放行的内容。
用 Fennec 落地的下一步
如果你想快速从日志发现走到执行动作，建议按这个顺序做：
- 先用 Bot Simulator 复测日志里请求量最高的 5 个 HTML URL
- 用 Robots.txt Checker 核对抓取规则
- 用 Canonical Checker 检查重复路径控制
- 用 Sitemap Checker 检查 sitemap 覆盖
- 再用 Audit 或 GSC Management 把 crawler 行为和整体索引问题连起来看
