Log File Analysis 怎么做：用服务器日志看 Googlebot 抓了哪些页、抓取预算浪费在哪

想知道 Googlebot 抓了哪些页，Search Console 和服务器日志都能看，但分工不一样：整站抓取趋势、可用性问题看 Search Console，具体某个 URL 有没有被抓过、什么时间抓的、返回了什么状态码，只能翻服务器日志。Google 在抓取错误排查文档里写得很清楚，Search Console 不提供可按 URL 或路径筛选的抓取历史。Log File Analysis 就是拿服务器日志回答两个问题，抓取预算浪费在哪，该抓的页面有没有被抓。

对做出海站的人来说，这件事的价值全在抓取预算上。页面少、当天就被抓的站不用管；页面多、更新快、搜索结果里该出现的页面一直不出现的站，日志能把每个请求对上。抓取预算被不想被抓的页面吃掉，该抓的页面就会迟迟不被抓，这是 Google 文档里讲得很直接的一层。

• 是什么：用服务器日志看 Googlebot 抓了什么，判断抓取预算浪费在哪、该抓的页面有没有被抓
• 官方怎么说：Search Console 不提供可按 URL 或路径筛选的抓取历史，具体 URL 的抓取记录得查日志
• 怎么做：先确认请求真来自 Google，再看状态码、文件大小上限、robots.txt 与 sitemap 口径
• 要多久：抓取本身可以花几天到几周，改完不要当天就下结论
• 常见误区：用 noindex 代替 robots.txt 屏蔽不重要页面会浪费抓取时间；用 robots.txt 临时腾预算不会转移给其他页面

这篇讲的是从拿到日志到读出 SEO 结论、再到下一步改什么。抓取只是 Google SEO 里的一层，这篇从日志开始拆。

Log File Analysis 是什么：用服务器日志看 Googlebot 抓了什么

Log File Analysis 就是拿服务器上的访问日志，把 Googlebot 的请求一条条挑出来，看它抓了哪些 URL、多久抓一次、返回了什么状态码、抓了多大。这件事在 SEO 里的位置很明确：Search Console 告诉你整站抓取的趋势和可用性问题，日志告诉你具体到每个 URL 的事实。

Googlebot 是两类爬虫，日志里怎么认

Googlebot 是 Google 搜索用的两类网络爬虫的统称，一类是 Googlebot Smartphone，一类是 Googlebot Desktop。日志里区分它们靠 HTTP user-agent 请求头，移动版和桌面版的 user-agent 不一样。但有个限制得知道，这两类爬虫在 robots.txt 里遵守同一个 product token，你没法在 robots.txt 里只指定其中一类。

多数站点现在主要索引移动版内容，Googlebot 的抓取请求大部分来自移动爬虫，少部分来自桌面爬虫。日志里移动版请求占多数，是正常现象，别当成异常去查。

抓取预算是什么，为什么日志能看出来

抓取预算指 Google 能且想抓的 URL 集合，由两个因素决定：crawl capacity limit（服务器能承受多少抓取）和 crawl demand（Google 有多想抓你的页面）。这两个词听着绕，落到日志里就是两件事：Googlebot 一共来了多少次，每次都抓了哪些 URL。

在抓取预算的语境里，Google 把一个站点定义为一个唯一主机名，不同子域算不同站点，各有各的预算。所以 www 和 blog 这种子域要分开看。另外，Google 的爬虫分布在全球多个数据中心，日志里看到来自多个 IP 的访问是正常的。

Search Console 给不了什么，日志能补什么

Search Console 不提供可以按 URL 或路径筛选的站点抓取历史。你能在里面看到抓取统计的总体趋势、可用性问题、哪些 URL 被索引了，但想查某个具体 URL 有没有被 Googlebot 抓过、什么时候抓的，得去翻服务器日志。这就是日志分析在 SEO 工作流里的位置：补上 Search Console 给不了的那一层细节。

抓取只是第一步，后面还有索引和排名，爬虫索引排名全流程把这个链路串起来了。

为什么要做日志分析：抓取预算浪费在哪、该抓的没抓

日志分析要回答的核心问题就两个：Google 的抓取时间是不是花在了你不想被抓的页面上，以及该被抓的页面是不是一直没被抓。前者叫抓取浪费，后者叫漏抓。两个问题在日志里的表现不一样，处理的顺序也不一样。

抓取预算被浪费的几种典型

几种页面会让 Googlebot 白跑一趟。最典型的是加了 noindex 的页面，Google 仍然会请求，看到 noindex 标签或响应头之后才丢弃，请求已经发生了，抓取时间就浪费了。还有被 robots.txt 屏蔽的 URL，这些 URL 会在抓取队列里留更久，解除屏蔽后还会被重抓。soft 404 页面也一样，页面返回 200 但内容是「页面不存在」，Google 会继续抓。

浪费的来源还有几种。sitemap 里放了不想被索引的 URL，Google 会照抓，抓完发现不该索引。分面导航、会话标识、购物车页、无限滚动页、执行动作的页面（比如注册页、立即购买页），这些 URL 大量暴露在站上，Google 会同样对待地抓。官方把这一类叫「不想被搜索抓取的 URL 暴露太多」，说这会对抓取和索引产生负面影响。

该抓没抓的四种原因

新增页面迟迟不被抓，Google 在文档里给了四个可能：Google 不知道这个页面、内容被屏蔽了、站点达到了最大服务容量、抓取预算用完了。四个原因对应四种排查动作：看内链和 sitemap 有没有把这个 URL 暴露出去、看 robots.txt 和 noindex 有没有挡、看服务器是不是扛不住、看日志里 Googlebot 的抓取是不是都花在别的页面上。

这四个原因里，前两个是 Google 想抓但抓不到，后两个是 Google 能抓但不想抓或抓不过来。排查按这个顺序走，比一上来就加服务器资源要准。

什么站点才需要看抓取预算

Google 的抓取预算指南面向三类站点：100 万以上唯一页面且内容每周变化一次的大站，1 万以上唯一页面且内容每天变化的中大型站，以及大量 URL 被 Search Console 归类为 Discovered - currently not indexed 的站点。这几个数字是官方给的粗略分类，不是精确门槛。

如果你的站页面不多，发布当天就被抓了，那就不用花时间读这份指南，也不用做日志分析。抓取预算这个问题，只在对「该抓的没抓」有感知的站上才成立。

Crawl Budget讲的是 Google 怎么分配抓取资源，跟日志里看到的现象能对上。

日志分析怎么做：从拿到日志到出结论的 6 步

拿到日志之后，第一件事不是数 Googlebot 的请求数。顺序错了，后面全是假数据。六步走完，该看的指标和该回查的方向都有了。Google 的文档里把抓取相关的验证和处理规则写得很细，下面六步按这些规则走。

第 1 步：先确认请求真来自 Google

日志里 user-agent 写着 Googlebot 的请求，不一定是 Googlebot。user-agent 可以随便伪造，这是日志分析里的一层假数据。验证的办法有两个：对来源 IP 做反向 DNS 查询，或者把来源 IP 跟 Googlebot 的 IP 段比对。Google 的文档里说这是验证请求是否真来自 Googlebot 的最好办法。

还有个具体的检查动作：在日志里搜自称 APIs-Google 的 IP，做反向 DNS 查询，结果应该落在 googlebot.com 或 google.com 域下。先用脚本把 user-agent 含 Googlebot 的行筛出来，再逐条做反向 DNS。这一步不做，后面按状态码、按路径做的所有统计都可能是假的。

Googlebot的 user-agent 和 IP 段在官方文档里有完整列表，验证的时候对着查。

第 2 步：按状态码分组，看哪些 URL 在拖后腿

把筛出来的 Googlebot 请求按状态码分组，统计 2xx、3xx、4xx、5xx 各占多少，429 单独看。状态码不是给日志看的，是给 Google 的处理流程看的。4xx 里除了 429，Google 不会使用 URL 的内容，已经索引的会被移除，抓取频率也会逐步下降。5xx 和 429 会让 Google 临时放慢抓取，降低的幅度跟返回错误的 URL 数量成比例。

分组之后要看的是集中度。5xx 集中在某几个路径上，把日志时间和服务器日志对齐，看是不是同一台机器或者同一个接口在出问题。4xx 集中在某个目录，看这个目录是不是批量改过 URL 没做重定向。

第 3 步：看文件大小有没有撞上限

Googlebot 为 Google 搜索抓取时，受支持文件类型只抓前 2MB，PDF 只抓前 64MB，到了上限就停止抓取，只把已经下载的部分送去索引考虑。日志里如果看到响应体大小接近这个数，要查这个页面是不是被截断了。

优先查大 HTML 页面，还有内嵌大量 base64 图片的页面。这类页面很容易在体积上超限，超了之后 Google 拿到的就是不完整的内容。

第 4 步：看 robots.txt 的抓取状态

在日志里找 Googlebot 请求 /robots.txt 的记录和返回码。返回 2xx，Google 按服务器提供的内容处理。返回 3xx，Google 至少跟 5 次重定向，然后当 404 处理。返回 4xx（429 除外），Google 当作不存在有效的 robots.txt，也就是说假定没有抓取限制。返回 5xx，前 12 小时停止抓取站点，之后 30 天用最后可用的版本。

改完 robots.txt 但日志里 Googlebot 的行为没变，先看缓存。Google 一般把 robots.txt 缓存最长 24 小时，没法刷新缓存的时候可能更久。改完当天看不到变化是正常的，别因为没变化就反复改。

第 5 步：看 sitemap 被抓了多少、抓的是不是想要的

统计日志里 Googlebot 对 sitemap 文件的请求，跟 sitemap 里的 URL 总量对比。sitemap 是给 Googlebot 的建议，不是绝对要求，不保证所有条目都会被抓。单个 sitemap 上限是 50MB（未压缩）或 50,000 个 URL，超了要拆。

要回查的有几个点。sitemap 里有没有混进不想被索引的 URL，这会浪费抓取预算。lastmod 是不是只反映了重要的更新，版权日期更新不算。priority 和 changefreq 这两个值 Google 是忽略的，写不写对抓取没影响。

第 6 步：把结论落成一张改动清单

日志分析的产出不是一张报表，是一张改动清单。按三列写：浪费预算的 URL 类别、该抓没抓的 URL 清单、状态码异常的路径。每一行对应一个具体动作，比如给购物车页加屏蔽、把 sitemap 里已删除的 URL 摘掉、修某个接口的 5xx。

改完过一段时间再拉一次日志，对比同一批 URL 的抓取频次有没有变化。先改影响面最大的一类，不一次全改，这样能分清哪个改动起了作用。抓取本身可以花几天到几周，改完当天不要下结论。

日志文件大的时候，手工筛不现实，要用脚本处理。处理日志的脚本和验证 IP 的工具，SEO常用工具里有整理。

日志分析要用的数字和限制

日志分析里会反复用到几个数字，都是 Google 文档里写死的。下面这张表把它们放在一起，看日志的时候对着查。

这些数字管的是 Googlebot 抓取时的行为边界，是硬限制。日志里看到接近边界的记录，要当成信号去查，不要当成正常波动。

日志分析常见误区：这 5 个做法官方明确不推荐

日志分析做完，下一步通常是动手改。但有几种改法 Google 在文档里明确说不推荐，改了不但没用，还可能把问题弄得更复杂。

先说最要命的一条，用 noindex 把不重要的页面挡在索引外，省抓取时间。Google 说这样没用，它仍然会请求页面，看到 noindex 标签或响应头之后才丢弃，请求已经发生了，抓取时间就浪费了。

还有个事，用 robots.txt 把一批页面屏蔽掉，把抓取预算腾给其他页面。Google 说除非它已经达到你站点的抓取容量上限，否则不会把新腾出来的预算转移给其他页面。

频繁增删 robots.txt 里的页面或目录，或者轮换 sitemap，来重新分配抓取预算，这两种做法 Google 也明确不推荐，robots.txt 只应该用于长期不想出现在 Google 的页面或资源。

用 401 和 403 状态码限制 Googlebot 的抓取速率，同样没用。Google 说除了 429 之外的 4xx 状态码对抓取速率没有影响，返回这两个码不会让 Google 抓得慢一点。

最后一条，把 robots.txt 当成把页面藏起来的手段。Google 说 disallow 只阻止抓取，它仍然可能索引被 disallow 的 URL，并在搜索结果里显示无摘要。如果这个 URL 被其他站点链接，索引的可能性更高。

误区排查完还是找不到原因，说明问题可能不在抓取这一层，SEO诊断可以接着往下查。

日志里发现异常怎么排查：按可用性、漏抓、过度抓取三层查

日志里看到异常，不要一上来就改代码。按三层顺序查：Googlebot 是不是遇到了可用性问题，该抓的页面为什么没被抓，是不是抓得太多了。三层从下往上，先排除最基础的。

第一层：Googlebot 是不是遇到了可用性问题

用 Search Console 的 Crawl Stats 报告看 Googlebot 的抓取历史，报告会显示 Google 什么时候在你的站上遇到了可用性问题。如果有可用性错误或警告，在 Host availability 图里找 Googlebot 请求超过红色限制线的位置，点进去看哪些 URL 失败了，再跟站点上的问题对上。

还可以用 URL Inspection 工具测几个 URL。如果返回 Hostload exceeded 警告，说明 Googlebot 无法抓取它发现的那么多 URL。这个信号指向的是服务器容量，不是内容质量。

第二层：该抓的页面为什么没被抓

按四个原因回查：Google 不知道这个页面、内容被屏蔽了、站点达到了最大服务容量、抓取预算用完了。新的页面至少需要几天才会被注意到，多数站点三天或更久，所以刚发布没几天就查为什么没被抓，没有意义。

如果是 Google 不知道，看内链和 sitemap 有没有把这个 URL 暴露出去。如果是内容被屏蔽，看 robots.txt 和 noindex。如果是服务容量，看 Crawl Stats 里的可用性图。如果是预算用完了，看日志里 Googlebot 的抓取是不是都花在了别的页面上。

第三层：是不是抓太多了

抓太多在日志里的表现是：同一类 URL 被反复抓，soft 404 页面持续被抓，公共资源没有用同一个 URL 引用导致重复请求。还有一种情况是分面导航和会话标识生成了大量 URL，Google 一个一个抓过去。

处理过度抓取，优先级是先消掉 soft 404 和重复 URL，再看公共资源是不是统一了 URL。Google 文档里说，公共资源在多个页面复用时应该用同一个 URL 引用，这样 Google 缓存一次就能复用，不用重复请求。

这三层查完，剩下的问题就不在抓取层面了，技术SEO自查可以从站内结构、渲染、索引几个方向接着排。

AI 能帮日志分析哪几步，人要核什么

AI 在日志分析里能干的事，集中在整理和归类上，判断和验证不能交出去。下面三步是 AI 能接的，后面三条提示词可以直接照抄。

第一步，把日志按 user-agent 和状态码分组统计。日志文件动辄几百 MB，手工筛不现实，把字段说明和样本交给 AI，让它输出分组统计表，比写脚本快。

第二步，把筛出来的异常 URL 按目录归类，标出 4xx、5xx、429 占比最高的目录，以及响应体大小接近上限的 URL。这一步 AI 做的是归类和排序，判断哪个目录该先改，还是要人看。

第三步，把整理好的异常清单写成改动清单，按浪费抓取预算、该抓没抓、状态码异常三类归档，每类给一个可以本周执行的动作。

有三件事不能交给 AI。反向 DNS 验证的结果要人看，AI 没法替你判断一个 IP 是不是真的属于 Google。状态码和索引的关系要回官方文档核，AI 给的结论可能是过时的。改动清单的优先级要人定，哪个先改、哪个不改，取决于你的站现在最在意什么。

下面三条提示词可以直接照抄，改动时按自己的日志字段调整。

第一条：这是一段 nginx access log，字段是 IP、时间、方法、路径、状态码、响应体大小、user-agent。请按 user-agent 是否含 Googlebot 分组，统计每组的状态码分布和响应体大小分布，输出表格。

第二条：以下是筛选出的 Googlebot 请求路径列表和状态码。请把路径按目录归类，标出 4xx、5xx、429 占比最高的目录，以及响应体大小接近上限的 URL。

第三条：以下是我整理的异常 URL 清单。请按「浪费抓取预算 / 该抓没抓 / 状态码异常」三类归档，每类给出一个可以本周执行的改动动作，不要给需要改代码超过一行的建议。

日志分析只是技术 SEO 自查的一环，猎者出海的AI Agent 的 SEO/GEO 优化员工能按技术 SEO、站内、内链几条线把自查清单跑一遍，方向、判断和验收还是你自己来。

常见问题

Log File Analysis 是什么？

用服务器日志看 Googlebot 抓了哪些 URL、多久抓一次、返回了什么状态码。它能补上 Search Console 给不了的那层细节，具体到每个 URL 的抓取记录。

Search Console 能看某个 URL 有没有被 Googlebot 抓过吗？

不能。Search Console 不提供可按 URL 或路径筛选的抓取历史，要看具体 URL 的抓取记录，只能查服务器日志。

日志里的 Googlebot 请求一定是真的吗？

不一定。user-agent 可以伪造，验证的办法是对来源 IP 做反向 DNS 查询，或者跟 Googlebot 的 IP 段比对。不做验证，后面的统计都可能是假的。

日志里 404 多是不是要马上处理？

不一定。404 是 Google 不要再抓这个 URL 的强信号，如果是正常下线的页面，404 是正确状态。要处理的是本该存在却返回 404 的页面，还有 soft 404。

小站需要做日志分析吗？

如果页面发布当天就被抓，不需要。日志分析的价值在抓取预算上，小站没有预算问题，花这个时间不如去改内容和内链。

日志分析要多久才能看到效果？

没有固定的时间。抓取本身可以花几天到几周，改完日志里的抓取频次变化要过一段时间才能看出来。改完当天不要下结论。

日志分析这件事，工具和步骤都不复杂，难的是把日志里的请求和站上的页面一一对上，再判断哪个该改。先做一遍，比反复看文档有用。