想搞清楚搜索蜘蛛到底爬了哪些页面、漏了哪些 URL，服务器日志是最直接的一手资料。第三方工具能给出趋势，但具体到一条路径、一个目录，只有日志能回答。下面这套读法适用于大多数 Nginx、Apache 或 CDN 回源日志。

先确认日志里的“蜘蛛”是不是真的

User-Agent 可以随意伪造，只按关键词过滤，很容易把采集脚本当成搜索蜘蛛。更稳妥的做法是组合判断：IP 反查确认归属，再叠加行为特征，比如是否请求过 robots.txt、请求频率是否稳定、是否几乎不携带 Cookie、是否只抓 HTML 和少量静态资源。

• 真蜘蛛一般会先读 robots.txt，再按自己的顺序抓页面；
• 请求节奏相对平稳，很少出现每秒数千次的突发；
• 对同一 URL 的重复请求有间隔，而不是连续轰炸。

一行日志里值得看的字段

字段不用全看，抓住六七个就够：

• URL（含参数）：判断抓取覆盖面，也能发现参数被日志系统截断的情况；
• 状态码：200 是正常抓取，301/302 说明走了跳转，404/410 说明地址失效，429/503 说明被限流或服务器不稳；
• 响应体大小：长期偏小往往是空模板、软 404 的信号；
• 响应时间：和抓取频次放在一起看，能看出抓取节奏有没有被拖慢；
• 时间：用来还原请求顺序；
• User-Agent：只作参考，不作为唯一依据。

从日志还原抓取路径

Referer 不是每台蜘蛛都会带，别把路径还原完全押在它上面。更实际的做法，是把同一 IP 在一段时间内的请求按时间排序，观察请求的前后关系：它先进的是列表页还是详情页？是否从首页一层层往下走？

再和另外两份材料交叉验证：一是你提交过的 Sitemap，二是站内的链接结构图。三者对得上，说明路径是通的；对不上，问题通常出在内链或渲染环节。

路径还原是概率判断，不是精确追踪。同一个 IP 也可能对应多个抓取任务，结论要留有余地。

URL 发现：把日志里的地址分成三类

1. 被反复抓取的 URL：通常是首页、栏目页和更新频繁的详情页，说明它们在内链和 Sitemap 里的位置比较靠前；
2. 只被抓过一次就消失的 URL：可能是内容更新少、状态码异常，或者被判定为低价值；
3. 从未出现过的 URL：最值得排查，常见原因是被 robots.txt 拦截、只存在于 JS 渲染后的内容里、没有任何内链指向、被 noindex 或规范标签指向了别的地址。

第三类不用一次全查，先挑业务上重要的目录看，效率更高。

Sitemap 和内链到底有没有起作用

提交 Sitemap 后，日志里通常会出现两条线索：蜘蛛对 Sitemap 文件本身的请求，以及随后对新 URL 的抓取。两者之间往往有间隔，不必因为当天没动静就反复改文件。

内链调整的效果更容易观察：改完链接位置或锚文本后，看目标 URL 的抓取频次和首次出现时间有没有变化。如果几天内毫无变化，再回头检查是不是被 JS 加载、被屏蔽，或者链接指向了跳转地址。

三种容易读错的日志

• CDN 边缘日志：缓存命中不会产生回源记录，源站日志看起来“蜘蛛没来”，实际是边缘节点响应了；
• 采样或压缩日志：被抽样的日志不能用来统计精确抓取量，只能看大致分布；
• 参数被截断：日志系统为了省空间会砍掉查询串，看到“同一 URL 被反复抓”时先确认不是记录问题。

一份可以照着做的排查流程

1. 按 IP 段过滤出真实蜘蛛请求，导出最近 7 天数据；
2. 按 URL 目录分组，统计各目录的抓取次数与状态码分布；
3. 挑出“零抓取”的重要目录，逐一检查 robots、内链、渲染方式和规范标签；
4. 对比 Sitemap 中的 URL 与日志中出现的 URL，找出长时间未被抓取的部分；
5. 查看抓取高峰时段是否与服务器压力、备份任务重叠；
6. 记录改动时间和内容，两周后再对比一次日志，看变化是否稳定。

日志不会直接告诉你该怎么改，但它能把“猜”变成“看”。坚持按目录、按状态码定期过一遍，抓取问题通常会比想象中更容易定位。