SEO 日志文件分析：读取服务器日志并修复抓取浪费

快速测验

SEO 适合您吗？该如何开始？

第 1 题，共 4 题25%

人们会在 Google 上搜索您卖的东西吗？

会，我觉得会不会，这是新东西或非常小众我不知道

服务器日志记录了什么，以及它为何优于你的其他数据

每当有文件从你的服务器被请求，服务器就会在访问日志中写入一行。大多数服务器使用接近 Apache "combined" 的格式。一条 Googlebot 请求的样子如下：

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

从左到右阅读：IP 地址、时间戳、HTTP 方法和 URL、状态码（此处为 200）、发送的字节数、来源页（referrer）以及用户代理（user agent）。每一个请求都记录在内，包括那些在分析工具中从不会显示为页面浏览的请求：图片、CSS 文件、重定向和 404 错误。

你的其他数据来源各自只能看到其中一部分。Search Console 中的抓取统计报告是汇总数据，且只涵盖 Google 的抓取工具。分析工具只记录浏览器运行了你网站 JavaScript 的访问者。Screaming Frog 之类的站点爬虫显示的是沿着你的链接能够访问到的内容，这与 Google 实际选择请求的内容并不相同。只有服务器日志记录了真正发生的事情。

为什么日志分析很重要：用通俗的话讲抓取预算

抓取预算是 Google 能够并且愿意抓取你网站上的 URL 集合。Google 对此有所描述，包含两个因素。第一个是抓取能力上限：Google 的抓取工具可以同时与你的服务器保持多少连接而不致使其过载。网站保持健康时，这个上限会提高；响应变慢或返回 5xx、429 错误时，则会降低。第二个是抓取需求，它取决于网站的规模、内容更新的频率、质量以及页面的受欢迎程度。

Google 把这个话题作为面向大型网站的进阶指南。其大致门槛是：拥有 100 万个或更多独立页面、内容约每周更新一次的网站；以及拥有 10000 个或更多独立页面、内容每天更新的网站。有大量 URL 处于"Discovered - currently not indexed"（已发现，当前未编入索引）状态的网站，同样属于这一范畴。较小的网站通常只需保持站点地图更新，并定期检查网页索引报告即可。这并不意味着日志对它们毫无用处。当抓取出现问题时，日志是最快准确定位问题所在的方式。

如果你的网站处于这一范围，问题就不再是要不要读取日志，而是多久读取一次。一次性审计可以告诉你当前的浪费情况，每月导出则能显示你的修复是否改变了 Googlebot 的时间分配。关于术语背景，抓取预算词条涵盖了基础知识，而 Discovered, currently not indexed 指南解释了通常会触发此类审查的状态。

分步方法

下面的流程适用于任何服务器和任何工具。后续章节会详细解释每一步，并给出可以立即对原始日志文件运行的命令。

从正确的层获取日志

向你的开发人员或主机服务商索取 Web 服务器（Apache、Nginx 或 IIS）的原始访问日志。开始之前检查三件事：日志格式、时区和保留期限。根据你的配置，旧日志可能在几天或几周后被轮换删除，因此请现在就索取导出，而不是等以后。

这一层比很多人预想的更重要。如果 CDN 从缓存中响应请求，你的源服务器永远看不到这个请求。Googlebot 可能抓取一个从未出现在源站日志中的 URL，因此只导出源站会低估对缓存内容的抓取量。也要导出 CDN 日志，并在相信任一总数之前，对几个 URL 比较两个来源。

用几条命令过滤并统计 Googlebot

在 combined 格式的日志中，状态码是第 9 个字段，URL 路径是第 7 个字段。这两列可以回答大多数初步问题。以下命令按状态码统计 Googlebot 请求：

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

这条命令列出 Googlebot 请求最多的 20 个路径，并去掉查询字符串，使筛选器的变体归并在一起：

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

第一条命令读取的是用户代理文本，任何人都可以伪造。在完成下一节之前，请把它的输出当作候选列表。另外，如果你的日志使用自定义格式，字段编号会变化，因此在相信这些列之前，先用眼睛检查一行。

按照 Google 的描述验证 Googlebot

Google 自己确认访问者是 Googlebot 的方法使用 DNS。对日志中的 IP 地址执行反向 DNS 查询，检查主机名是否以 googlebot.com、google.com 或 googleusercontent.com 结尾，然后对该主机名执行正向查询，并检查它是否返回原始 IP。Google 的文档使用了这个示例：66.249.66.1 反向解析为 crawl-66-249-66-1.googlebot.com：

host 66.249.66.1

正向检查是第二条命令，且必须返回相同的 IP：

host crawl-66-249-66-1.googlebot.com

如果你要处理数百万行，DNS 查询会变慢。Google 还公布了其抓取工具 IP 范围的 JSON 文件，其中包括 Googlebot 的 common-crawlers.json。与这些范围进行匹配更快，官方验证指南在 Google 的 Googlebot 验证指南中描述了这两种方法。

分组、测量并解读结果

逐个 URL 的原始计数很难采取行动。先按模板对 URL 分组，因为修复通常针对模板，而不是某一个页面。然后为每组测量四项指标：相对于其业务重要性，它获得了多少 Googlebot 命中；状态码的构成；新页面在发布后获得首次命中的速度；以及命中是否集中在你希望获得排名的页面上。

要把结果当作模式来解读，而不是单个数字。如果大多数 Googlebot 命中落在筛选器 URL 上，只有少数落在产品页上，那么抓取预算正在流失，问题很可能出在内部链接或参数处理上，而不是产品页本身。下一节列出了应该关注的信号。

日志中隐藏的七个信号

当 Googlebot 的记录行经过验证并完成分组后，七个信号就能解释大多数抓取问题。下表给出了应寻找的模式以及通常的修复方法。每项修复都是对网站的修改，因此要在下一次导出中加以确认。

信号	日志显示的内容	应采取的措施
抓取浪费	Googlebot 命中了筛选器、排序、站内搜索和会话 URL	用 canonical 进行合并，删除指向这些 URL 的内部链接，并在无法合并时在 robots.txt 中屏蔽无意义的变体
重定向	命中 301 或 302 响应，以及两次或更多跳转的重定向链	直接链接到最终 URL。301 与 302 指南可帮助你选择正确的重定向类型
错误	反复命中 404 或 410，以及 5xx 响应的激增	恢复或重定向仍然重要的页面，并修复服务器错误，因为 5xx 响应会减少 Google 的抓取量
缺失的抓取	在时间窗口内完全没有 Googlebot 命中的重要 URL	检查内部链接、站点地图条目以及可能让抓取工具远离它们的 robots.txt 规则
重复内容	同一内容被多个 URL 命中，包括末尾斜杠、大写字母或参数	选定一个规范 URL，并在各处链接到它
首次抓取时间	新页面从发布到第一次 Googlebot 命中之间的时间	从经常被抓取的页面链接到新页面，并保持站点地图整洁
响应时间	Googlebot 命中最多的模板响应缓慢	优先加速这些模板，因为 Google 表示响应缓慢会导致它抓取更少

"缺失的抓取"这一行常被忽略，却往往代价最高。在日志中从未出现的页面，即使内容出色，也可能毫无排名。如果一个 URL 在你的站点地图中，却从未出现在日志里，那么该页面很可能只能通过抓取工具不会跟随的路径访问。Crawled, currently not indexed 指南涵盖了另一种情况，即 Googlebot 确实访问了页面，但仍未编入索引。

三种运行分析的方式对比

你可以用脚本、桌面应用程序或平台来运行日志分析。每种方式适合不同的数据量和不同的团队。正确的选择更多取决于你需要答案的频率，以及谁来阅读，而不仅仅是网站的规模。

命令行：grep、awk 和 Python

原理：用脚本解析原始文件，并把结果写入文件或电子表格。适用场景：一次性检查、小型网站，或希望完全掌控的开发人员。优点：免费，你能看到每一行，并且可以通过定时任务自动化。局限：编写和维护需要时间，运行速度受限于你的机器，没有图表，并且必须自己验证机器人。

示例：方法部分中的命令，如果每月对同一份导出运行一次，就能给出 Googlebot 的状态码构成和主要路径。一个简短的 Python 脚本可以做同样的事，并加入 DNS 检查，虽然更慢，但更精确。

桌面工具：Screaming Frog Log File Analyser

原理：将原始日志导入桌面项目，工具会对机器人进行分组、检查其身份并绘制图表。适用场景：在拥有数万个 URL 的网站上工作的顾问或内部分析师。优点：它可以读取 W3C Extended 格式的 Apache、IIS 和 Nginx 日志，验证搜索引擎机器人，并标记大型或缓慢的页面。局限：免费版有限制，能加载的数据量取决于你的硬盘。

购买前请阅读 Screaming Frog 的 Log File Analyser 页面。关于与之配套的爬虫的完整教程，请参阅我们的 Screaming Frog SEO Spider 指南。日志分析工具完成了爬虫无法完成的一项工作：它显示机器人在现实中实际请求了什么，而不是你的链接所暗示的内容。

平台：持续的日志监控

原理：平台按计划接收你的日志，通常来自 CDN 或服务器，并将其与你网站的抓取数据和索引数据进行关联。适用场景：需要每周跨多个市场监控抓取的大型电商网站或企业团队。优点：可扩展到超大规模的日志，保留历史记录，并允许多个团队共享仪表板。局限：成本更高，接入需要时间，供应商锁定是真实存在的，因此在承诺之前，请确认如何导出你的数据。该类别的供应商包括 Oncrawl 和 Botify，值得向每一家询问它们如何验证机器人。

标准	命令行	桌面工具	平台
成本	免费	1000 个日志事件以内免费，完整许可证每年 99 英镑	订阅制，价格取决于数据量
设置	由你编写并维护脚本	安装、导入、启动	连接器与入门引导
数据量	受限于你的机器	受限于硬盘和许可证	专为超大规模日志构建
机器人验证	手动，使用 DNS 或 IP 范围检查	内置	询问供应商
最适合	一次性检查和小型网站	顾问和中等规模网站	需要每周监控的企业和电商团队

Google 的抓取统计报告：有用，但不够

在导出任何日志之前，先打开 Search Console 中的抓取统计报告。它显示抓取请求总数、下载总大小、平均响应时间、按类型分组的响应、文件类型、抓取目的，以及每个请求所属的 Googlebot 类型。对于趋势检查，它是你能获得的最快视图，而Google Search Console 教程解释了在哪里找到它。

它的局限性解释了为什么日志仍然重要。该报告仅适用于网域资源和根级 URL 前缀资源。它只涵盖 Google 的抓取工具，因此 GPTBot、ClaudeBot 和其他机器人都不在其中。它对数据进行分组，而不是逐个列出 URL，所以它能告诉你抓取请求下降了，却无法告诉你哪些模板失去了这些请求。用它来发现发生了变化，然后用日志查明是什么。

Google 的抓取统计帮助页面描述了每种分组方式。当图表与你的日志导出结果不一致时，在检查时间窗口和验证步骤之前，两者都不要相信。这类不一致大多来自时间窗口不同、CDN 从缓存响应，或机器人计数中包含了未验证的请求。

发现后修复抓取浪费

修复措施源于各项信号。其中大多数归结为三个动作：停止把抓取工具引向无关紧要的页面，在页面已迁移时直接将其指向最终 URL，以及让重要页面加载得更快。

分面导航。筛选器和排序顺序会产生许多内容几乎相同的 URL。在可能的情况下用 canonical 进行合并，并删除指向没有搜索价值的变体的内部链接。如果某个变体无法合并且必须排除在抓取之外，就在 robots.txt 中屏蔽它。Google 在这方面的指导很明确：不要为此使用 noindex，因为 Google 在看到该标签之前仍需请求该页面。以下是需要测试的规则示例：

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

robots.txt 的改动要有分寸。Google 表示，屏蔽 URL 不会为你的其他页面释放抓取预算，除非网站已经达到其能力上限。屏蔽适用于没有价值的 URL，而不是把预算推向你最好的页面的手段。我们的 robots.txt 词条解释了该文件是如何被读取的。

重定向链。当一个页面移动了两次，抓取工具每次都会经过两次重定向。更新内部链接，使其指向最终 URL，然后为外部链接保留旧的重定向。在永久重定向与临时重定向之间做选择，也出于同样的原因，301 与 302 指南对此有详细说明。

已删除的页面。对于永久移除的页面，返回 404 或 410。Google 表示软 404 会持续被抓取并浪费抓取预算，因此以 200 状态提供"页面未找到"信息，比真正的 404 更糟。

响应时间与缓存。Google 表示缓慢或失败的响应会导致它抓取更少。请支持 304（Not Modified）响应，使未变化的页面可以从缓存中提供。然后查看接收 Googlebot 命中最多的模板，优先加快这些响应。

代价最高的错误，以及如何避免

大多数出错的日志分析，都会犯下少数几种错误中的一种。下面每种错误都有一个你可以在数据中发现的症状，以及一项可以在同一周内应用的修复。

相信用户代理字符串

是什么：把每个声称自己是"Googlebot"的请求都计为 Google 的抓取。如何发现：来自无法反向解析为 Google 主机名的 IP 地址的 Googlebot 命中，或来自单个地址的突然激增。如何修复：在统计任何内容之前运行方法部分中的验证，并把未验证的命中保存在单独的分类中，以便你仍能看到爬虫的活动。

只阅读 200 响应

是什么：只关注返回 200 的页面，忽略其余页面。如何发现：你的报告没有 3xx、4xx 或 5xx 部分，或者从未讨论过状态码构成。如何修复：始终从状态码分布开始。404 命中的上升可能揭示一个失效的内部链接，5xx 命中的上升则可能揭示拖慢整个抓取的服务器问题。

屏蔽你想从索引中移除的页面

是什么：为同时带有 noindex 标签的页面添加 robots.txt 规则。如何发现：页面仍在索引中，而日志里没有 Googlebot 命中，因为抓取工具被阻止请求它。如何修复：移除屏蔽，使 Google 能读取 noindex 标签，等待页面退出索引，然后如果你仍需要屏蔽，再把它加回去。Blocked by robots.txt 指南解释了这种情况下会出现的 Search Console 状态。

比较不同长度的时间窗口

是什么：把修复前 3 天的导出与修复后 30 天的导出进行比较。如何发现：总数变化很大，但每个模板的占比没有变化。如何修复：尽量比较相同的天数，并在一年中的相同时段进行比较；当数量发生变化时，比较占比而不是原始总数。

测量命中，而不是价值

是什么：为 Googlebot 命中数的增长而欢呼，却不检查这些命中是否到达了会被编入索引的页面。如何发现：命中集中在未编入索引或从不带来流量的 URL 上。如何修复：把日志分组与 Search Console URL 检查工具给出的索引状态结合起来，只有当抓取转向重要页面时，才把一项修复视为成功。

AI 机器人在同一日志中的位置

同样的日志也显示了 AI 抓取工具在你网站上的行为，方法相同：对它们分组，在供应商提供验证方式时进行验证，并阅读状态码。AI 抓取工具日志指南涵盖了需要查找的机器人，以及它们与 Googlebot 的区别。本文深入讲解 Googlebot 的方法，下一节则展示如何把两者合并到一份报告中。

机器人类型	示例	在日志中检查什么	在哪里阅读更多
搜索抓取工具	Googlebot	按模板统计的命中、状态码构成、新页面的首次抓取时间	本文上面的各节
训练抓取工具	GPTBot、ClaudeBot、CCBot	它们是否根本请求你的内容，以及它们是否遵守 robots.txt	AI 抓取工具的 Robots.txt
检索抓取工具	ChatGPT-User、PerplexityBot	与用户提问相关的短时访问高峰，以及这些高峰所到达的页面	AI 抓取工具日志

训练与检索之间的区分，来自 AI 抓取工具的文档记录方式。训练抓取工具为模型收集内容，检索抓取工具则在用户提出问题时获取页面。你的报告应当把两者分开，因为对其中一种做出的政策决定，不会自动适用于另一种。

如果你想在实施这些修复的同时，并排查看 Google 流量和 AI 流量，Sorank 的 GEO / SEO 仪表板可以在一个视图中同时显示两者。用它来检查你根据日志所做的更改是否改变了流量，而不仅仅是抓取计数。