读日志只需盯住四样东西：谁在抓、抓了哪个地址、返回什么状态码、抓了多少次。把这四列按爬虫名分组统计，就能看出抓取预算被浪费在哪。顺序是先去噪，再看状态码分布，最后定位低价值目录，而不是先怀疑内容质量。
核心要点速览
- 日志是少数不受第三方口径影响的抓取事实来源，它记录了每一次真实请求的地址、状态码与时间。
- 诊断第一步是去噪：把静态资源、监控探针与安全扫描从日志里剔除，只留页面请求。
- 状态码分布比总量更有信息量，404 与 5xx 的占比往往直接解释抓取量为何上不去。
- 重复抓取同一批参数地址是抓取预算被浪费的最常见形式，通常由站内链接与筛选参数造成。
- 日志只能回答「谷歌来过没有」，要判断收录与展示，还需要与收录报告和站点地图交叉核对。
很多外贸站的技术同学遇到收录慢、新页面不出现时，第一反应是改内容、加外链。但在动手之前，有一个更靠前的问题需要先回答：搜索引擎到底有没有来抓过这些页面？
这个问题只有服务器日志能回答。第三方工具给的是估算与抽样，日志给的是每一次请求的原始记录。两者的差别，在排查「抓了但没收录」这类问题时尤其关键。
日志的麻烦在于它又长又吵：图片、样式、脚本、监控探针、安全扫描都混在里面。直接打开文件往往看不出结论，必须先按固定维度做一次分组统计。
下面按四个维度拆开讲：该看哪些字段、状态码怎么读、怎么找出被浪费的抓取、以及日志结论如何与其它报告对齐。
一、日志里真正有用的四个字段
| 字段 | 看什么 | 常见结论 |
|---|---|---|
| IP / 反向解析 | 归属哪个搜索引擎 | 先按来源分组，才能把谷歌与其它访客分开 |
| User-Agent | 爬虫类型与版本 | 区分桌面、移动与图片爬虫，口径不同 |
| 请求地址 | 抓了哪些路径 | 目录级聚合能看出抓取集中在哪一层 |
| 状态码 | 服务器返回什么 | 404 与 5xx 占比过高会压低整体抓取 |
| 响应时间 | 服务器处理耗时 | 过慢会压缩抓取频次，属技术层问题 |
这五列凑齐，日志才具备分析价值。缺少响应时间时，可以先用状态码与地址两列做出基本判断，再回头补耗时统计。
二、按顺序做三次分组统计
日志分析不需要复杂工具，一张表格加命令行文本处理就能起步。关键是分组维度要固定，否则每次得出的结论无法互相比较。
第一遍：按爬虫来源分组
先确认验证方式，再把日志按来源拆成谷歌、必应、其它三份。谷歌官方建议通过反向 DNS 或官方公布的 IP 段来确认请求确实来自自家爬虫，而不是冒充的访客。[1]
这一步能回答一个基础问题：搜索爬虫的抓取量在总量中占多少。如果占比很低，那么收录慢的原因可能根本不在页面质量，而在抓取本身就没有发生。行业里常用的日志分析工具，例如 Screaming Frog 的日志文件分析，也是按同样的思路把原始请求转成可读的抓取报告。[3]
按天统计抓取次数还能看出趋势。周末与工作日的差异、改版前后的跳变、上线新目录后的爬取反应，都是在这一层被发现的。
第二遍：按状态码分组
把每个目录的状态码分布列出来，重点看 404、301、5xx 三类。404 集中出现，说明站内还有指向已删除页面的链接；5xx 出现，说明服务器在抓取压力下不稳定。
301 链条过长也会消耗抓取。一个地址经过两跳到最终页，等于同样一次抓取只完成了一半的工作量，剩余额度就被链条吃掉了。
这一步做完，通常会浮现出少数几个异常突出的目录。它们就是下一遍统计的对象。[4]
第三遍：按目录聚合抓取量
把地址按路径前缀聚合成目录，再看抓取次数的分布。健康的站点，抓取应该集中在产品页与内容页；如果统计结果显示大量抓取落在筛选参数、分页参数或搜索参数上，那就是预算跑偏了。
这一层的价值在于它可执行：结论直接对应到 robots.txt 规则、站内链接结构与参数处理方式，改动范围明确，验证方式也明确。
三、一套可重复的诊断顺序
- 先确认日志是否被采样或轮转截断部分服务器只记录部分请求，或日志按天轮转后被压缩。先确认覆盖的时间范围完整，再谈结论。
- 去噪并锁定搜索爬虫剔除图片、样式、脚本、监控探针与扫描器，只保留页面级请求，并按来源分组。
- 统计状态码分布按目录分别统计 200、301、404、5xx 占比，找出异常集中的目录。
- 定位被浪费的抓取把参数型地址、重复路径与跳转链单独列出，评估它们占用了多少抓取次数。
- 与其它报告交叉核对日志说抓过、收录报告说未收录，说明问题在质量或重复；日志说没抓，问题在可发现性与预算。像 光算GPC爬虫池 这类抓取资源，也是在这一步之后才判断是否需要引入的。
小结：日志的价值不在于数据量，而在于它能证伪一些猜测。抓取正常但收录差，说明要改内容与结构；抓取本身就少，说明要先解决可发现性与抓取预算。把这两个方向分开，后面的动作才不会白做。[2]
四、日志结论怎么与其它报告对齐
日志只能回答抓取层的问题，它不告诉你页面是否被索引、是否有展示。要让结论落地，还需要与站点地图提交状态、页面索引报告交叉核对。
一个常见的误区是拿日志里的抓取次数当作收录数量的代理指标。抓取是收录的前提，但不等于收录：页面被抓取之后仍可能因为质量、重复或规范网址判断而被排除。
先对齐时间窗口
日志、收录报告与站点地图的处理时间通常不同步。索引数据有延迟，站点地图的读取也有自己的节奏，直接比对同一天的三个数字往往得出错误结论。
稳妥的做法是以周为单位对齐：把同一周的日志抓取量、站点地图提交量与新收录页面数放在一起看趋势，而不是看某一天的绝对值。
再看可发现性这一环
如果日志显示搜索爬虫访问了站点地图、站内链接结构也正常，说明可发现性这一环没有明显问题，优化重点应放在页面本身。
反过来，如果站点地图被读取的次数很低，或者重要页面只能通过深层链接到达，那么日志分析的结论就应该落在结构与提交方式上。
五、常见异常与对应处理
日志里反复出现的异常其实就那么几类，处理方式也相对固定。把它们整理成清单，下次遇到时可以直接对照。
抓取量持续下降
先排除服务器故障与封锁规则。确认不是技术原因后，再检查是否有大范围的内容变更或结构化调整，这两类动作通常会让抓取节奏短暂变化。
如果下降与服务器响应时间上升同时出现，优先处理性能问题，因为抓取频次与站点可用性直接相关。
新页面长期不被抓取
检查这些页面是否能通过站内链接到达。只存在于站点地图中的地址往往被排在后面处理，先补上从已有页面出发的内链路径，通常比反复提交站点地图更有效。
同时确认 robots.txt 没有误封目录，并在页面索引报告里做一次网址检查，看返回的是哪一种状态。
参考来源
- Google：robots.txt 规范介绍（英文） —— Google 官方对 robots.txt 的说明，解释如何用它控制爬虫抓取范围及其局限，可用于引用抓取控制的官方定义。
- IndexNow 官方协议站（英文） —— IndexNow 协议官方网站，说明如何通过该协议即时通知搜索引擎内容更新，是讨论快速收录时可直接引用的协议出处。
- Screaming Frog 官方博客（英文） —— 爬虫工具 Screaming Frog 的官方博客，聚焦技术 SEO、站点抓取与索引诊断，适合引用技术排查方法。
- Google Search Console 帮助：网址检查工具（简体中文） —— Search Console 官方中文帮助文档，说明如何用网址检查工具查看单个网址的抓取与索引状态，适合在讲收录排查时引用。
常见问题
服务器日志要保留多久才够做诊断？
一般建议至少保留一个完整季度，因为抓取波动与改版影响往往需要足够长的时间窗口才能看清。如果存储紧张，可以只保留页面级请求的记录，并在压缩前完成按目录的聚合统计，把明细与汇总一起留存。
没有服务器权限，还能做抓取诊断吗？
可以部分进行。页面索引报告里的已抓取数据、站点地图的读取记录都能反映抓取情况，只是粒度和时间范围不如日志。想看到完整请求明细，通常需要向主机商申请访问日志或让运维导出对应时间段的记录。
日志里出现大量 404，一定是严重问题吗？
不一定。少量 404 属于正常现象，尤其是内容迭代较快的站点。需要关注的是 404 是否集中在仍被站内链接指向的地址上，以及是否反复被爬虫请求。把站内失效链接清理掉，这类抓取浪费就会明显减少。
抓取频次高就代表收录会变好吗？
两者相关但不等价。抓取是收录的前提，页面被频繁抓取说明可发现性没问题，但是否收录还取决于内容质量、重复程度与规范网址判断。抓取正常而收录不佳时，优化重点应转向页面本身而不是继续增加抓取量。
用第三方工具看抓取数据，和读日志有什么区别？
第三方工具通常基于抽样或自有爬虫的模拟，能快速给出趋势，但看不到服务器真实返回的每一次请求。日志是原始记录，适合用来验证工具给出的结论。稳妥的做法是先用工具看趋势，再用日志确认关键节点的事实。