抓取是否顺畅、蜘蛛走了哪些路径，很多时候答案不在后台报告里，而在服务器的原始日志中。报告会做聚合与抽样，日志则是逐条请求，能看清某一分钟谁来过、看了什么、拿到什么结果。排查 URL 发现或抓取断层的问题时，先把日志读顺，往往比反复提交 URL 更实际。
先确认请求里哪些是蜘蛛的
日志里混着真实用户、监控探针、CDN 回源和蜘蛛。最常见做法是用 User-Agent 做初筛，但 UA 可以伪造，建议再结合来源 IP 段的反向解析做交叉验证。初筛时把 UA 字段单独抽出来，建一份固定清单，之后每天用同一套规则过滤，结果才有可比性。
值得单独留存的几个字段
- 请求时间与时区，用来对齐抓取节奏；
- 请求方法与完整 URL，带上查询参数，否则看不到筛选路径；
- 状态码，区分正常返回、跳转与错误；
- 响应时间，判断哪些页面拖慢了整体节奏；
- User-Agent 与来源 IP，确认访问者身份；
- Referer，判断蜘蛛是从哪条内链走到这一页的。
把原始请求整理成三条视图
日志是流水，直接翻容易眼花。建议固定做三种聚合，形成习惯后每次只看增量。
按 URL 分组看重抓节奏
同一个 URL 在一段时间内被访问的次数、间隔、状态码是否稳定，能反映它值不值得被频繁回访。如果一个页面长期没人抓，先看它有没有被发现过，再看它的内链入口是否还在。
按 Referer 分组看内链线索
把 Referer 归类，可以看出蜘蛛主要沿着哪些页面往里走。如果某个栏目页几乎没有 Referer 指向它的子页面，多半意味着这个栏目页的出链有问题，或者链接由脚本渲染，蜘蛛在 HTML 里看不到。
按小时看抓取分布
抓取请求在一天内的分布能反映站点响应状况。如果某几个小时请求明显减少，先排查那段时间是否有发布、备份或批量任务。服务器压力和抓取节奏常常互相牵连，把两件事放在一起看更容易找到原因。
日志里比较常见的三类问题
- URL 已被发现但没有后续抓取，日志里只有 Sitemap 拉取记录，没有对应的页面请求；
- 抓取反复落在参数版本上，说明规范链接或链接收敛没有做到位；
- 某段路径请求量正常但状态码频繁跳转，链路里可能夹着一层不必要的中间地址。
日志要和覆盖率报告对照着看
日志反映的是“来过”，覆盖率报告反映的是“收没收”。两者对不上时，通常有三种情况：抓到了但没被采用、被采用但没进索引、或者根本没抓到。定位到具体 URL 之后，再回日志里查它当天的请求记录，比凭感觉猜测更快。
读日志的目标不是把每次抓取都记下来，而是找到反复出现的模式，再把模式对应到一处可以改的地方。
把结论落到具体改动
- 补入口：给孤岛页面加上可点击的普通链接，而不是只在脚本里拼出来；
- 收敛路径：同一内容保留一个主地址，其余用跳转或规范标签处理；
- 稳定响应：把慢查询、超大页面、频繁超时的资源排在修复清单前面；
- 更新 Sitemap：只放需要被发现、且能返回正常状态的地址。
日志本身是消耗品，存一段时间就够，但读日志的方法可以沉淀成固定的几个视图。每次网站结构、模板或服务器配置有变动，都用同一套视图复核一遍，抓取路径上的问题通常会在数字明显变化之前就露出迹象。