你不可能在 Google Analytics 中看到 GPTBot。GA4 和大多数第三方分析工具都依赖浏览器执行 JavaScript 来记录访问，而 GPTBot 不运行 JS，也不会触发这些跟踪代码。要证明 OpenAI 的爬虫是否真的访问过你的页面、抓取了什么内容，以及服务器返回了什么响应，唯一可信的证据就是服务器的原始访问日志。
为什么服务器日志才是唯一可信的依据
AI 爬虫和真实用户走的是两条不同的访问路径。真实用户打开浏览器、加载页面、执行 JS 并触发 GA4 事件，因此你能在数据面板中看到一次访问。GPTBot 这类爬虫只会发起 HTTP 请求，收取服务器返回的 HTML，然后离开。它们不会执行跟踪代码，所以分析工具会完全漏掉这些访问。服务器日志则不同：无论请求来自真实用户、Googlebot 还是 GPTBot，Nginx 或 Apache 都会逐条记录来源 IP、访问时间、请求路径、返回状态码和 User-Agent。前端无法阻止这类记录，请求方不运行 JS 也不会让记录消失。
先分清 OpenAI 的三个爬虫，不要只盯着 GPTBot
很多人以为 OpenAI 只有一个爬虫，因此只在日志中搜索 GPTBot，结果严重低估了网站在 OpenAI 体系中的可见度。OpenAI 至少有三个用途不同的爬虫，对应的 User-Agent 也不同。分析时应分别识别、分别统计。
- GPTBot：用于获取模型训练和改进所需的内容，User-Agent 中包含 "GPTBot"。它遵守 robots.txt，来源 IP 公布在 openai.com/gptbot.json。
- OAI-SearchBot：为 ChatGPT 的搜索功能建立索引，User-Agent 中包含 "OAI-SearchBot"。它与你的内容能否在 ChatGPT 回答中被“引用”关系最直接。
- ChatGPT-User：当用户要求 ChatGPT 读取某个链接时触发，User-Agent 中包含 "ChatGPT-User"。它一旦出现，说明有真实用户正在通过 ChatGPT 访问你的页面。
- 再进一步：同一份日志中通常还会出现 PerplexityBot、ClaudeBot、Google-Extended 等其他 AI 爬虫，分析方法完全相同。
第 1 步：从访问日志中找出 GPTBot 的踪迹
以最常见的 Nginx combined 格式为例，一行日志通常依次包含来源 IP、访问时间、"GET /blog/geo-audit HTTP/1.1"、状态码 200、返回字节数，以及最后的 User-Agent 字符串。GPTBot 请求的 User-Agent 末尾会带有以下标识：compatible; GPTBot/1.2; +https://openai.com/gptbot 利用这一特征，只需几行命令就能梳理它的抓取行为。
- 找出所有 GPTBot 请求：grep -i "GPTBot" /var/log/nginx/access.log
- 统计它今天访问了多少次：grep -ic "GPTBot" access.log
- 查看返回状态码的分布（combined 格式的第 9 列是 HTTP 状态码）：grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- 查看它最常抓取哪些页面（第 7 列是请求路径）：grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- 一次对比三个爬虫的抓取量：grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log
这些输出能直接回答三个问题：抓取频率如何——每天访问多少次、集中在哪些时段；覆盖范围如何——是否抓取了最重要的产品页面和文章，还是只在首页打转；响应是否正常——状态码是否几乎都是 200。如果 grep 没有任何结果，说明 GPTBot 在这段时间内根本没有来过，此时应回头检查 robots.txt 或防火墙是否把它拦住了。
第 2 步：确认这个 GPTBot 是真的
User-Agent 字符串可以随意伪造。任何爬虫，甚至恶意流量，都能在请求头中写入 "GPTBot" 冒充身份，从而绕过某些规则或消耗你的服务器资源。因此，找到相关记录后还必须验明真伪。下面两种方法的可靠性都很高。
- 对照官方 IP 列表：OpenAI 分别公布了各类爬虫的来源 IP 网段，地址为 openai.com/gptbot.json、openai.com/searchbot.json、openai.com/chatgpt-user.json。将日志中的来源 IP 与对应列表进行比对，只有落在相应网段内才算有效。
- 反向 DNS 验证：对来源 IP 执行 PTR 查询（host 或 dig -x），真正的 GPTBot 会反向解析到 OpenAI 名下的域名；随后再对该域名进行正向查询，确认它能解析回同一个 IP，也就是 forward-confirmed rDNS。正反向结果一致，才值得信任。
第 3 步：查看它抓取了什么，以及拿到了什么状态码
爬虫来了，不代表内容就成功被抓取。真正影响你的内容能否被 ChatGPT 引用的，是每次请求究竟拿到了什么。以下四个信号最值得关注。
- 状态码：理想情况下应全部为 200。大量出现 403，通常说明 Cloudflare 或 WAF 把 GPTBot 当作可疑流量拦截；404 表示 sitemap 或内部链接指向了无效 URL；持续出现 5xx，则说明爬虫访问时服务器发生错误。
- 页面覆盖情况：检查抓取路径列表，确认最需要获得引用的定价页、方案页和深度文章是否在其中。如果它只抓首页和几篇旧文章，说明你的核心内容对 AI 仍然不可见。
- llms.txt 与 robots.txt 的访问情况：从日志中可以看到爬虫是否请求了 /llms.txt 和 /robots.txt。如果部署了 llms.txt，却从未被读取，说明该爬虫目前并不采用这套文件，不要高估它的作用。
- 抓取频率与内容新鲜度：对照文章发布或修改的时间，查看 GPTBot 多久会回来重新抓取。如果回访间隔过长，新内容进入模型认知所需的时间也会更长。
先读懂日志，再谈优化
在投入精力编写 llms.txt、补充 Schema 和重写内容之前，先花十分钟用 grep 检查访问日志。Tenten 曾接手过一个案例：客户的 llms.txt 和 Schema 都做得很好，但深入排查日志后才发现，整整半年里，GPTBot 每次访问都被 WAF 返回 403，之前的优化因此全部落空。日志会如实告诉你 GPTBot 有没有来、抓取了什么，又在哪里被拦住。这是所有 GEO 技术优化中成本最低、也最重要的一步。如果你想了解日志中隐藏了哪些可见度缺口，以及哪些问题最值得优先修复，可以预约一次 30 分钟的 GEO 诊断。我们会直接检查你的抓取状态，并指出最具可执行性的改进方向。
