在讨论 AI 有没有引用你之前，先确认它有没有来读过。这件事有日志证据，且不依赖任何第三方数据。本文给出 16 个具名 AI 爬虫的 UA 标识、真爬虫与伪装的三条核验、robots.txt 放行矩阵的四种组合，以及「没被爬」和「没被引用」该怎么分别处理。
一个被忽略的事实：AI 有没有读过你的官网，是有日志证据的
讨论 GEO 的时候，大多数注意力都在「AI 有没有提到我」。但这个问题之前还有一个更基础的问题：AI 到底有没有来读过我的站？
这两件事的关系是单向的：没被读过，基本不可能被引用（除非它引用的是别人转述你的内容）；被读过也不一定会被引用。所以「读没读」是排查链路里最先要看的一环，而且它有一个别的指标都没有的优势——可以在你自己的服务器日志里验证，不依赖任何第三方数据。
平台把这件事做成了一个独立能力：上传 access.log，解析后按 AI 爬虫引擎归类，输出每个引擎的抓取次数、抓了哪些页面、按日趋势。
下面讲清楚三件事：日志里怎么认出 AI 爬虫、怎么分辨真爬虫与伪装、以及为什么「被拦」和「没来」必须分开处理。
一、日志里怎么认出 AI 爬虫
标准做法是看 User-Agent 里的标识串。目前主流 AI 公司都有自己的爬虫 UA，平台内置识别 16 个具名引擎：
| 引擎 | 主要 UA 标识 |
|---|---|
| OpenAI（ChatGPT） | GPTBot、ChatGPT-User、OAI-SearchBot |
| Anthropic（Claude） | ClaudeBot、Claude-SearchBot、Claude-User |
| Perplexity | PerplexityBot、Perplexity-User |
| Google AI | Google-Extended、Google-Agent、Google-NotebookLM |
| Apple AI | Applebot-Extended |
| Meta AI | Meta-ExternalAgent |
| Amazon | Amazonbot |
| Common Crawl | CCBot |
| 字节跳动 | Bytespider |
| 月之暗面 Kimi | Moonshot、Kimi |
| 通义千问 / 夸克 | Qwen |
| 智谱 GLM | Zhipu、BigModel |
| 百度文心 | Ernie |
| DeepSeek | DeepSeek |
| Cohere | Cohere-AI |
| You.com | YouBot |
不在清单里的 UA 归入「其他 AI 爬虫」，不会强行塞进某个已知引擎。
一个容易混淆的点：同一个引擎可能对应多个 UA，用途不一样。以 OpenAI 为例，GPTBot 用于训练语料抓取，ChatGPT-User 是用户提问时实时访问，OAI-SearchBot 用于搜索索引。它们在「AI 有没有读过我的站」这件事上有不同含义——训练抓取和实时检索是两条路径。平台把它们归在同一个引擎下展示，但日志明细里保留了原始 UA，需要细分时可以自己筛。
二、真爬虫与伪装：三条核验
UA 是客户端自己声明的字符串，任何脚本都能改成 GPTBot。所以只看 UA 会把大量扫描器、采集器、甚至恶意爬虫算成 AI 访问。
三条核验办法，可靠性递增：
① 反向 DNS 查证。 主流 AI 爬虫的官方 IP 段是公开的。对日志里的来源 IP 做反查，正向再解析一次确认闭环，是行业标准做法。反查结果和 UA 对不上的，就是伪装。
② 行为特征。 真爬虫通常遵守 robots.txt、有固定的抓取节奏、不会一次拉全站、不会带上奇怪的查询参数。伪装爬虫往往表现为：突然大量请求、抓取路径毫无规律、并发很高。
③ 页面访问的完整性。 真爬虫要读内容，会拉取 HTML 和关键资源；只请求首页就走的，多半是探测。
平台的解析器做了 UA 归类这一步，IP 反查与行为分析目前不代做——日志是你自己的，这类核验最好由你的运维按内网规范执行，我们不接管你的服务器基础设施。文章里给方法，是因为这部分你可以自己做完。
三、robots.txt 的「放行矩阵」：想拦的拦住了吗
这是 AI 爬虫监测里最有行动价值的一环。
很多站点在 robots.txt 里写了 AI 爬虫规则，但写了不等于生效。常见三种失效：
① UA 名字写错。 比如写 GPTBot/1.0 或者 OpenAI，实际规范是按 User-agent: GPTBot 匹配。写错的话规则整条不生效，爬虫照抓。
② 规则组之间互相覆盖。 robots.txt 里同一个 UA 出现多次时，不同爬虫的解析行为不一致。写多个 User-agent 段之前要确认它们是不是同一组。
③ 想放行却写了 Disallow。 这是最常见的反向错误：想让 AI 引用你，却在 robots 里把 AI 爬虫全拦了——有的模板默认就带 Disallow: /，套上去之后站点对新爬虫直接关门。
平台的放行矩阵就是把「你声明的意图」和「实际抓取行为」对照起来：
- 声明为允许、日志里确实来了 → 正常；
- 声明为允许、日志里从没出现 → 可能没被发现（sitemap / 内链问题），或者 UA 识别不上；
- 声明为拦截、日志里却出现 → 规则没生效，要回去查写法；
- 声明为拦截、日志里没有 → 正常。
四种组合对应四种处置，这才是“监测”该有的形态。只报一个“本月 AI 访问 328 次”的看板，无法回答任何一个实际问题。
四、「没被爬」和「没被引用」是两件事
这是我们最坚持的区分之一，也是排查顺序的根据。
| 现象 | 含义 | 第一步该做什么 |
|---|---|---|
| 日志里没有任何 AI 爬虫 | 站点对 AI 不可达，或被 robots 拦住 | 查 robots.txt、sitemap、是否要求登录 |
| 有爬虫但只抓首页 | 内链结构让爬虫走不进去 | 查导航、栏目页、内链密度 |
| 抓了目标页但没被引用 | 内容不具备可引用条件 | 查事实密度、来源可追溯、结构 |
| 被引用了但不是你的官网 | AI 引用的是平台上别处的转述 | 查信源构成，把内容铺到权威信源 |
如果跳过第一步直接改内容，可能改了三个月才发现爬虫根本进不来。这是典型的“优化了错误的对象”。
五、怎么开始：一次最小可用的排查
不需要任何工具也能先做一轮粗查：
- 下载最近 30 天的 access.log；
grep -i "bot\|spider\|crawler"粗筛，看有没有上面表格里的 UA；- 对命中的 UA 统计：请求数、访问的不同 URL 数、时间分布；
- 如果只有首页，去看内链和 sitemap；
- 如果完全没有，先确认 robots.txt 第 1 节的三种失效情况。
平台把这个过程做成了上传即解析、按引擎出报告，还支持 .log / .txt / .gz 三种格式（未压缩、纯文本、gzip 压缩的日志都直接吃）。做这一步的价值不在看板，而在于它能给你一个确定的起点：在讨论内容怎么改之前，先确认 AI 找得到你。