via https://moz.com/blog/analyze-log-files-ai-search
大多数团队在过去两三年里，把大量时间和预算投入到 AI 搜索中。但许多团队并没有确认：AI 机器人能否访问到他们的重点页面，或者是否在页面加载完成前就放弃了。
我从事 SEO 已超过 15 年，但我仍然看不到足够多的人关注服务器日志文件——而这些答案就藏在日志里。
本文将向你展示如何获取服务器日志、识别经过验证的机器人，并找出阻止 AI 爬虫获取你内容的问题。
日志文件里有什么？
日志文件每记录一个请求就包含一行。每当一个人、爬虫或抓取程序向你的服务器请求某个资源时，服务器就会记录该请求。
下面是一个示例：
text
203.0.113.42 [12/Aug/2026:14:28:19] "GET /guides/pricing" 200 48213 "ChatGPT-User/1.0"
从左到右，这一行告诉你：
- 谁发起了请求：访问者的 IP 地址——
203.0.113.42 - 何时访问：精确到秒的日期和时间——
12/Aug/2026:14:28:19 - 想要什么：请求的确切页面和请求方法——
GET /guides/pricing - 结果如何：响应码——
200 - 发送了多少内容：以字节为单位的响应大小，这可以帮助你发现某个页面返回的内容比预期少——
48213 - 它自称是谁：声明的用户代理——
ChatGPT-User/1.0
一行来自 ChatGPT-User 请求
/guides/pricing的服务器日志，标注了 IP 地址、时间戳、请求页面、响应码和发送字节数。
日志文件会重复这样的行，有时包含更多字段，可能重复数百万次：每记录一个请求就有一行。这些是你的日志设置所捕获的真实请求记录。
提示词跟踪显示的是当有人提出某个具体问题时，助手说了什么。分析工具中的引荐数据告诉你人类何时点击进入。两者都不能告诉你助手最初是否真的能访问到你的页面，但日志可以。
六个请求，五种不同情况
同一网站的六行日志：两个干净的机器人请求、一个等待 31 秒后的 ChatGPT-User 499、一个来自 chatgpt.com 引荐的人类访问、一个仅返回 3,104 字节的 GPTBot 200，以及一个 Claude-User 403。
注意：末尾的rt和cache字段并非所有设置中都是标准字段。第 2 步会进一步说明。
前两行是干净的：
- Googlebot 和 OAI-SearchBot 都请求了定价页面，并在不到半秒内从缓存中收到
200 OK状态码和完整的 48,213 字节。这就是理想状态。
第 3 行放弃了等待：
- ChatGPT-User 是响应用户请求实时抓取页面的代理。它请求了与第 1、2 行相同的页面，但由于缓存未命中，它等待了超过 31 秒后挂断。
- 服务器记录了
499状态码，并且没有发送任何字节。 - 由于这些日志配置为记录缓存状态，可以考虑评估其他未缓存请求，看看它们是否也很慢。
第 4 行是真人：
- 请求的是同一个页面，但用户代理标识的是普通浏览器，并且引荐来源指向 ChatGPT。请将这些引荐而来的人类访问与机器人请求分开跟踪。
第 5 行显示 200 OK 响应，但只是一个空壳：
- GPTBot 收到了成功响应，但字节数只是预期的一小部分。如果页面依赖客户端渲染，机器人可能只收到了一个没有内容的模板。可通过在不执行 JavaScript 的情况下抓取该 URL 并检查返回内容来调查。
第 6 行表明你的防火墙正在阻止访问：
- Claude-User 请求了 San Diego 地点页面，但仅在 6 毫秒内就收到了
403 Forbidden。响应如此之快，很可能是安全规则在请求到达应用之前就将其拦截。检查你的 Web 应用防火墙（WAF）或机器人管理规则以确认。
一个重要说明：
日志文件只显示你在所选时间范围内、从所拉取层级捕获到的请求。如果你的 CDN 从缓存响应了大多数请求，而你只看源服务器日志，你就会漏掉流量。采样排除主机名和记录在其他位置的子域名，也可能导致数据集不完整。
分析 AI 搜索日志文件的六步框架
第 1 步：获取正确的日志并打开一个可管理的样本
你从哪里获取这些文件，取决于你的组织和其技术栈。我建议从三个地方开始：
- 公司已经付费使用的工具：已经有一个可以摄取日志数据的平台，这种情况出奇地常见。
- 你的 CDN（内容分发网络）：如果你需要追溯到源头，CDN 日志是黄金标准。与你的 DevOps 或托管团队沟通以获取访问权限。
- 你的 Web 服务器：不要轻视它，但要记住，当页面在边缘缓存时，CDN 会响应请求，而你的源服务器根本看不到它。因此，源日志会低估缓存页面的请求量。
表格比较三种日志来源（CDN、Web 服务器和现有 SEO 工具）各自捕获什么、该找谁以及典型交付周期。
一个能让你和团队省去很多麻烦的提示：先要一个样本。几百行应该足以检查文件能否打开、你的工具能否读取该格式，以及它是否包含你需要的字段。要在有人花一周时间导出 40GB 你却用不了的数据之前做这件事。
第 2 步：索取正确的数据
如果你向 DevOps 团队要“日志文件”，你可能会得到几个字段，但漏掉真正重要的字段。
按名称指定你的字段：
- 请求方 IP 地址
- 请求的页面及请求方法（例如 GET 或 POST）
- 日期和时间
- 用户代理（访问者自称的身份）
- 响应码
- 发送字节数（实际发送了多少）
另外两个字段取决于你的技术栈，但值得索取：
- 响应时间：服务器响应花了多长时间。这通常不在 nginx 的默认日志格式中，但你的 CDN 或负载均衡器可能已经记录了它。
- 缓存状态：请求是从缓存提供，还是传递到了源服务器。当出现慢请求时，这往往是第一条线索，帮助你检查缓存未命中是否导致了延迟。
下面是一封你可以改编使用的示例邮件：
主题：用于 SEO 分析的日志文件导出请求
你好 [姓名]，
我正在研究搜索引擎和 AI 爬虫如何访问我们的网站，想从访问日志开始。你能先拉一个小样本吗（几百行即可），这样我可以在导出更大数据之前确认格式是否可用？
来源：如果可用，[CDN——例如 Cloudflare、Akamai、Fastly]，否则 [Web 服务器——例如 nginx、Apache]
域名：[example.com，以及任何子域名]
必需字段：
- 客户端 IP 地址
- 请求的 URL 和请求方法（GET、POST 等）
- 请求日期和时间
- 用户代理
- HTTP 响应码
- 发送字节数
如果可用：
- 响应时间（服务器响应花了多长时间）
- 缓存状态（HIT、MISS 等）
样本确认无误后，我大约需要 [两周] 的数据用于完整分析。请告诉我哪种格式最容易导出（CSV 或原始日志文件都可以），以及关于我们的日志如何采样或过滤，有没有什么我需要知道的。
谢谢！
[你的名字]
多少数据？
没有完美答案，但一旦你确认输出符合要求，可以考虑这些起点：
- 一到两周有助于识别具体问题
- 一到两个月可显示一般抓取行为
- 更长的时间范围（90 天或以上）如果你关心训练型爬虫，这会有帮助，因为它们访问频率较低
第 3 步：打开文件并评估
你不需要数据仓库就可以开始。这里有两个选项：
- 使用公司已经付费的工具：像 Profound 这样的平台可以帮助你处理和评估日志文件。
- 从 Screaming Frog 的 Log File Analyser 开始：这是与它的 SEO Spider 分开的工具，可以导入日志并检测 AI 机器人用户代理。
一个重要说明：
导入日志时启用机器人验证。在 Screaming Frog 的 Log File Analyser 中，寻找“Verify Bots When Importing Logs”，以确保受支持的机器人确实是它们声称的身份。我将在下一步解释为什么这很重要。
如果你的日志已经管道传输到某个地方，就使用那个地方，尤其是如果它能把日志与你的抓取数据连接起来。对于拥有数百万行日志的大型网站，BigQuery 和 SQL 可以提供帮助，但你不需要它们也能开始。
第 4 步：看看谁在敲门
打开日志文件后，先弄清楚谁在出现。这是很多人出错的地方，因为 AI 机器人分为四类，每一类服务于不同目的，并按不同时间线运作。
- 第 1 层 训练：收集文本以训练模型
- 第 2 层 索引：构建列表，AI 助手搜索以找到可能引用的内容
- 第 3 层 实时获取：响应用户问题时抓取你的页面
- 第 4 层 执行：代理代表某人浏览你的网站
AI 机器人的四个层级：训练（数月）、索引（数周）、实时获取（数秒）和执行（数秒）。
理解第 3 层和第 4 层的方式是：第 3 层读取你的页面，而第 4 层使用你的网站。目前，代理主要是在评估，然后转交给人类。Google 目前是一个有限的例外，符合条件的商家可以让代理在客户确认后完成购买。
以下是截至 2026 年 10 月，你可能在每个组中看到的样本。随着模型发布和新玩家进入，这些名称可能会变化，而且这里没有列出许多较小的机器人：
按层级列出 AI 机器人用户代理的参考表，包括 GPTBot、ClaudeBot、OAI-SearchBot、PerplexityBot、ChatGPT-User、Claude-User 和 Google-Agent。
一个有用的提示：名称中的“-User”通常意味着实时获取，但请把它视为命名惯例，而不是规则。Google-Agent 也会响应用户请求，并在用户代理字符串中标识自己。OpenAI 的浏览器代理使用签名请求头进行验证。
这引出了更大的问题：检查机器人是否真的是它声称的身份。
许多网站犯的两个错误
陷阱 1：阻止了错误的机器人
以 OpenAI 为例。阻止 GPTBot 是告诉 OpenAI 不要将你的内容用于模型训练，这是一个合理的商业决定。但阻止 OAI-SearchBot 可能会阻止你的内容出现在 ChatGPT 搜索答案中。一条笼统的“阻止 AI 机器人”规则可能把两者都阻止。
检查你的 robots.txt 和 CDN 规则，找出哪些机器人被阻止。如果有人告诉你他们阻止了 AI 机器人，你的第一个问题应该是：“哪些？”
陷阱 2：相信机器人自称的身份
用户代理是请求者给自己起的名字。任何人都可以在浏览器或抓取工具中通过向请求头添加“GPTBot”来覆盖它。抓取程序可能夸大你的数字，而旨在阻止假机器人的安全规则也可能意外阻止真机器人。
机器人验证有助于在你统计请求之前标记这些冒名者。取决于运营方，验证可能涉及检查公开的 IP 范围、确认 DNS 记录或验证签名请求头。
第 5 步：要寻找什么
本文聚焦 AI 机器人，但日志文件分析也有助于你评估抓取预算使用情况，并发现传统搜索中的抓取低效问题。不要忽视日志文件，尤其是在抓取预算优化作用更大的大型网站上。
打开日志并筛选出已验证机器人后，重点关注三个问题：
- 它们能进来吗？ AI 机器人访问哪些页面？
- 它们得到了什么？ 它们收到的是你的页面还是错误？
- 它们会等待吗？ 还是你的服务器响应太慢？
它们能进来吗？
这里主要评估两件事：
- 没有 AI 机器人访问过的页面：无论这些页面在 Google 中排名多好，它们对 AI 搜索都是不可见的。如果你的重点变现页面在这个列表上，调查为什么爬虫找不到或到不了它们。
- 只有机器人知道的页面：这些是多年前有人链接过的旧 URL，但机器人仍在请求。检查它们应该返回真实页面，还是重定向到相关替代页面，因为外部仍有东西在请求它们。
这两个列表编译起来比听起来容易。使用 Moz Site Crawl 运行一次普通抓取，将 All Crawled Pages 报告导出为 CSV，然后在电子表格或日志文件分析器中将这些 URL 与日志文件数据进行比较。
Moz Pro Site Crawl 的 All Crawled Pages 报告，箭头指向 Export CSV 按钮。
这两个问题的修复都属于技术 SEO：合理的内部链接策略和 XML 站点地图。
它们得到了什么？
接下来，查看每个机器人收到的 HTTP 响应码：
- 200 OK：机器人收到了成功响应，但检查发送字节数以确保它得到了完整页面。
- 301/302 重定向：检查是否存在多次重定向跳转或重定向循环。
- 403 Forbidden：你拒绝了请求。检查你的防火墙或机器人设置。
- 404 Not Found / 410 Gone：页面不可用，但机器人仍在请求。如果有相关替代页面，考虑重定向。
- 499 Client Closed Request：客户端在响应完成前关闭了连接。稍后会进一步说明。
- 500 Server Error：你的服务器无法完成请求，AI 机器人没有返回。
当 AI 机器人收到 HTTP 状态码 200、301、403、404/410、499 和 500 时分别意味着什么。
关注每个机器人的错误率，而不是全站错误率。即使很小的错误率，也可能意味着失去来自 AI 助手（如 ChatGPT）的宝贵实时流量。
调查时，从 403 开始；意外的防火墙或机器人管理规则可能正在阻止合法请求。
它们会等待吗？
这是许多审计会跳过的问题。查看按机器人和文件夹划分的平均响应时间，重点关注两种模式：
- 某个机器人得到的响应比其他机器人慢
- 网站某个部分的运行速度比全站慢
这很重要，因为搜索引擎爬虫可能会等待慢页面加载，或者稍后再回来。而回答问题的助手背后有一个人在等待答案，所以它们可能会在你的服务器交付内容之前放弃。
前面的问题关注机器人是否能到达你的页面。这个问题问的是它是否停留足够久以读取页面。这就是 499 状态码的用武之地。
第 6 步：调查 499
让我们回到前面日志示例中的第三行：
text
23.102.140.7 [12/Aug/2026:14:32:07 +0000] "GET /guides/pricing HTTP/1.1" 499 0 "-" "…ChatGPT-User/1.0" rt=31.412 cache=MISS
499 状态码意味着“客户端关闭请求”。请求方在你的服务器完成发送之前挂断了。
这不是官方 HTTP 状态码；而是 nginx 发明的，许多 CDN 和负载均衡器采用了它（有些系统用不同标签记录它）。
在这个示例中，ChatGPT-User 在一次缓存未命中后等待超过 31 秒后断开连接，服务器没有发送任何字节。这让响应时间值得调查，尽管仅凭该状态码并不能告诉你请求方为什么断开连接。
这就是为什么我认为 499 是日志中最有趣的状态码之一，因为它记录了别人对你做出的决定。
然而，它也很容易被忽视。专注于 500 级服务器错误的监控可能会忽略 499。乍一看，它们像是访问者的错，所以团队可能会不以为意。但如果它们发生在 ChatGPT-User 或 Claude-User 身上，助手可能不得不在不引用你内容的情况下回答用户的问题。
如何调查反复出现的 499
单个 499 并不能有力证明任何事情。人们可能关闭浏览器标签页，机器人也可能被限流或重启。与其他状态码一样，要寻找模式。
将反复出现的 499 与以下内容对照检查：
- 响应时间：检查请求持续了多久客户端才挂断。5 到 6 秒的 499 与 200 毫秒的 499 讲述的是不同故事。
- 缓存状态：查看 499 是否集中在缓存未命中上。如果同一 URL 的缓存请求很快，而未缓存请求超时，这可能就是罪魁祸首。
- 受影响的 URL：检查失败是否集中在某个模板、文件夹或重型页面类型上。某个模板背后的慢数据库查询可能解释这种模式。
- 同一机器人的其他请求：比较全站失败情况。如果该机器人在各处都收到 499，调查限流、WAF 挑战或源服务器过载。
不要把所有断开连接的请求都当作服务器慢的证据，尤其是当你需要其他团队来解决它时。给你的队友一个清晰的模式和支持数据去调查。
目标是确定爬虫是否收到了页面。你的日志显示响应码、发送字节数，以及客户端是否断开连接。
修复问题是否会带来更多引用或提及，是另一个问题，你需要使用 Moz AI Visibility 等工具在 AI 答案中进行衡量。
你的品牌在 AI 搜索中被提到了吗？
立即在 Moz Pro 中查找 AI 引用！
日志文件告诉你该修什么
以下是基于你所看到情况的高层修复清单：
表格将日志文件发现（499、403、404、机器人从未到达的页面、重定向链和 CSS/JS 请求）映射到建议修复。
最后一行值得强调。日志中出现大量 CSS 和 JavaScript 请求本身并不是阻止它们的理由。这些资源是某些爬虫渲染和理解你页面的方式。
这在真实网站上是什么样？
几个月前，一位客户找到我们 iPullRank，明确提出要通过试点项目证明短期影响。
我们从技术部分开始，注意到他们的日志文件显示访问限制问题，包括很大一部分 AI 爬虫请求以 499 结束。我们修复了这些问题，以及若干可抓取性问题。
我们将其与一个更广泛的 AI 搜索项目并行推进，该项目涵盖内容和衡量，所以我不能把结果单独归因于日志修复。但在我们解决技术问题后，AI 可见性在接下来几个月有所提升。
折线图显示，在实施技术修复后，某客户的 AI 可见性呈上升趋势。
这不仅仅是一个客户
我们与 Profound 合作扩展了分析，在 2026 年 4 月查看了 700,000 个页面，以下是我们发现的结果：
- 当 OpenAI 尝试抓取时经常超时的页面，其引用量比没有超时的页面少 18 倍。
- 在超过四分之三的抓取尝试中失败的页面，经常完全没有引用。
对 700,000 个页面分析的三项发现：经常超时的页面引用量少 18 倍；许多失败超过四分之三的页面引用量为零。
我们在 iPullRank 网站上的《AI Citation vs Page Speed Analysis》中更详细地介绍了这些发现。需要明确的是，这是一项相关性分析，不是对照测试。
结语：资格就是新的排名
清晰、权威且结构良好的内容，只有在助手收到它时才有意义。你的日志文件可以帮助你确定页面是否具备资格。
以下是本周就可以开始的做法：
- 发一封邮件：向 DevOps 要一个小样本，然后要两周日志，包含第 2 步中的六个基本字段，以及可用时的响应时间和缓存状态。
- 打开日志：使用 Screaming Frog 的 Log File Analyser 等工具。在支持的地方启用机器人验证，并优先处理来自“-User”代理和 Google-Agent 的已验证请求。
- 调查访问失败：从重点页面上的 403 和反复出现的 499 开始，然后处理其余重定向和错误。