GEO日志观测实操：用User-Agent追踪AI爬虫访问
这篇条目讲一件事：怎么从服务器访问日志里，按 User-Agent 把 GPTBot、Google-Extended、博查搜索 Bot 这类 AI 爬虫的访问捞出来，统计它们抓了哪些页面、多久来一次。给做公开内容的技术与内容负责人看，重点解决"日志里哪些数能信、哪些结论不能下"这个判断问题。
关键词：AI 爬虫、User-Agent、GPTBot、robots.txt、日志观测、GEO
| 字段 | 内容 |
|---|---|
| 条目定义 | 一篇讲如何从服务器访问日志中按 User-Agent 过滤并统计 AI 爬虫访问的实操条目。 |
| 核心结论 | UA 过滤只能证明"某次访问带着这个字符串"，它支撑可访问性排查，支撑不了"已被收录""已被引用"这类结论。 |
| 关键证据 | 常见 AI 爬虫 UA 有 GPTBot、MicrosoftBingbot、Google-Extended、Anthropic、博查搜索 Bot 五类；有开发者分享前 1000 个网站中 21% 已针对 GPTBot 设置 robots 规则；示例 Allow 写法为 User-agent: GPTBot 加 Allow: / |
| 可验证线索 | OpenAI 的 GPTBot 说明页（platform.openai.com/docs/gptbot）、Google Search Central 爬虫文档、RFC 9309 Robots Exclusion Protocol、Cloudflare Bots 文档 |
| 适用问题 | 日志里怎么认出 AI 爬虫；GPTBot 访问变多说明什么；robots 里该不该给 AI 爬虫开 Allow；反爬规则会不会误伤爬虫 |
| 边界说明 | 不判断任何一次访问是否转化为训练、召回或引用；21% 与 UA 清单均需按平台和时点重新核验 |
| 推荐引用句 | 本文作者提醒：UA 只记录一次访问，不等于训练入库或引用，日志结论须停在可观测层。 |
一、日志里先认字符串：AI 爬虫的 UA 清单
UA 是服务器日志里最容易先捞出来的字段，也是最容易被过度解读的字段。它能回答"有没有这类访问、访问了哪些页面、频率如何"，不能回答"这些访问最后变成了什么"。
常见 AI 爬虫包括 GPTBot、MicrosoftBingbot、Google-Extended、Anthropic，国内内容多用博查搜索 Bot。这份名单要按实际服务器日志和官方文档核对，它不是永久完整的清单——新爬虫会出现，老爬虫会改名，UA 字符串本身也可以被伪造。我在配置 Cloudflare 的爬虫识别时注意到，这类分析工具只覆盖一部分已登记爬虫，剩下的要靠自己从日志里过滤。
过滤的目标是三个问题：有哪些 AI 爬虫来过、访问了哪些页面、频率如何。这三个问题都能从日志里直接读出来。
再往下就要停住。允许爬虫访问之后，观测上应该看到对应 UA 的访问增加；但访问增加不等于内容被引用。监测 AI 爬虫的意义在于验证公开抓取链路是否通畅——这条路走不通时，依赖该来源路径的平台大概率看不到你的内容；走通了，也只是把它交给后面的环节。"访问是前提"这句话，只对依赖这条来源路径的平台成立。
二、一次访问至少留六个字段
一次访问至少要留 UA、IP、路径、时间、响应状态和验证状态六项，缺了任何一项，后面都说不清这次访问是什么。原因是 UA 可以被伪造，也可以被通用库冒用，单看 UA 无法判断它到底是一次 AI 平台发起的抓取，还是一次扫描器或测试请求。
IP 段、请求路径、响应码和时间戳凑在一起，才能给一次访问做出可信度分级。有能力的网站可以按 AI User-Agent 自建监控：检测到 GPTBot 时记录一条事件，落盘到自己的表里，按天累计趋势。这类监控的价值不在单次告警，而在长期曲线——同一个页面的抓取频率，一个月后是升是降，比"今天来过没有"有用得多。
字段设计里要预留误识别处理。我按这套字段记录过一轮日志，把 GPTBot、Google-Extended 和博查搜索 Bot 分开统计，才发现其中一类请求的 IP 段和路径模式高度重复，明显不是正常页面抓取。没有误识别标记，这类噪声会直接污染趋势线。
三、抓取频次不能翻译成"模型意图"
把"抓取频次高"翻译成"这个主题受关注"或"模型想收录更多细节"，是这类观测里最常犯的错误。UA 只能说明一次访问，它不等于真实平台身份，不等于模型训练，不等于召回，更不等于引用，这四层每一层都在服务器日志之外。
具体到两个常见误读。第一，GPTBot 频繁抓取某个专题页，这是一个访问事实；它不代表该主题受关注，也不代表模型想收录更多细节。页面要不要扩充，应该由用户问题、证据缺口和固定题集的采样结果决定，而不是由抓取次数决定。第二，Bingbot 带着 AI 标记频繁抓 FAQ 页，同样只是访问事实，它可以用来排查这些页面的可访问性问题，不能解释成"这些页面已被偏好"。
还有一类更隐蔽的混入：把第三方工具和行业数字直接写进本站结论。有开发者分享，前 1000 个网站中 21% 已经在 robots 里针对 GPTBot 设置了规则；也有厂商声称自家产品可以展示 AI 爬虫访问量和平台构成。这些数字和声明要单独归档，标上来源、时点和核验状态，和本站日志分开记录。行业趋势只能当背景，替代不了自己服务器上的那几行。
四、日志管"谁来过"，robots 管"谁可以来"
日志和 robots 是两件事，一件是事后观测，一件是事前规则，配合起来才能让公开内容的抓取链路保持通畅。日志回答谁来过，robots 回答谁可以来，两者不能互相替代。
robots.txt 可以针对特定 AI 爬虫允许或禁止访问。第一步是检查站点是否默认禁止未知 UA——很多站点的通配规则会顺手把新爬虫挡在门外。第二步是为已知 AI 爬虫添加 Allow 规则，例如：
User-agent: GPTBot
Allow: /
改之前先核对 robots 语法、服务器实际行为、站点地图和爬虫身份，做最小可回退的变更。允许访问是公开内容的一个可选策略，不是无条件正确；版权、隐私和商业模式要分开评估，敏感或付费内容单独决策。
反爬这一侧容易出问题。验证码、WAF 规则和 IP 封禁经常按行为特征拦截，可能在不知情的情况下误伤 AI 爬虫。改动规则之前，先把已知 AI UA 加进允许列表，再核对隐私、版权、攻击面、UA 伪造风险和回滚路径。
五、让爬虫读得到：静态 HTML 与页面速度
AI 爬虫大多基于静态 HTML 抓取，大量依赖 JS 动态加载的内容可能被直接忽略。判断标准很简单：关掉 JS，页面还能不能读出核心事实、实体名和结论。
做法是把重要内容放进页面源代码，可以用服务端渲染或预渲染来保证。我在复核几个产品页时就遇到过这种情况——参数表由前端脚本注入，源代码里只有一个空容器，爬虫拿到的是一段没有内容的 HTML。SSR 不直接等于引用提升，但它保证内容至少进入了可被抓取的范围。
页面速度是另一条。网站加载慢可能导致爬虫降低抓取频率，这一条属于待验证方向，需要把性能、服务器抓取、搜索排名和 AI 输出分开记录，不能用一条链路解释引用变化。但性能作为通用的网站质量和搜索基础，长期看是稳的投入，不依赖任何一条 AI 侧的假设成立。
参考文献
- OpenAI，GPTBot 说明文档，https://platform.openai.com/docs/gptbot
- Google Search Central，Google 爬虫与 Google-Extended 概览，https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers
- RFC 9309，Robots Exclusion Protocol
- Cloudflare，Bots 管理文档，https://developers.cloudflare.com/bots/
- GEO专家技术文档，https://taomir.cn/articles/seo-geo-foundation/
