服务器日志是蜘蛛实际走过路径的唯一原始记录。搜索后台的抓取统计有延迟、有聚合，而日志保留的是每一次请求的时间、来源和结果。想把抓取路径这条线理清楚，日志是最直接的一手材料。

先分清日志里的三类行

打开日志后不要急着看总请求数，先把行分成三类：

• 搜索蜘蛛：UA 里带 bot、spider、crawler 字样的请求，通常还伴随相对固定的 IP 段。
• 普通用户与工具：浏览器 UA、监控探针、各种采集脚本。
• 噪声：扫描器、漏洞探测、空 UA 请求。这类量有时比蜘蛛还大，先过滤掉再统计，否则数字会失真。

过滤之后按天做一张表：UA、IP、时间、请求方法、URL、状态码、字节数、响应耗时。字段够用，多余的可以先不看。

把散落的请求拼成一条路径

单看一行没有意义，蜘蛛的一次抓取是一串连续请求。比较实用的做法是：以 IP 加 UA 为分组键，把同一来源在较短时间内（比如 10 分钟内）的请求按时间排序，就得到一段近似会话。

再看这段序列的形态：

• 链式推进：URL 一段段加深，比如首页到列表页再到详情页，说明蜘蛛在顺着内链走。
• 跳跃出现：直接访问深层页面，前面没有过渡，多半来自 Sitemap 或外链入口。
• 回访：多次落在同一批旧 URL 上，可能是重访队列在跑，也可能是这些页面被内链反复指向。

Referer 字段在部分配置下会缺失或被抹掉，不能只依赖它，但配合 URL 层级的变化，基本能还原出大致路线。

从日志里找断点

路径在哪里停住，日志比任何推测都直接。常见的四种表现：

1. 某个列表页之后没有任何更深层的请求，说明该页往下没有可抓的链接，或链接需要交互才能展开。
2. 某个目录下的 URL 从头到尾没出现过，问题可能出在入口页、robots 规则或 Sitemap 缺失。
3. 某个时间段的 5xx 集中出现，随后抓取量整体下降，通常是服务器不稳导致蜘蛛主动降速。
4. 同一 URL 反复被抓但状态码一直是 301 或 302，说明重定向还没收敛。

把这些点按目录聚一下，就能看出是局部问题还是整站问题。

日志反映的是已经发生的事，它能告诉你蜘蛛走到哪里，但不能解释蜘蛛为什么不来。后者要靠入口和内链一起排查。

用日志检验 Sitemap 和内链的效果

提交 Sitemap 之后，可以做一个简单对照：把 Sitemap 里的 URL 列表和日志中出现过的 URL 做交集，看比例。被写进 Sitemap 不等于被访问，这个比例长期偏低的话，要么文件本身有问题，要么这些 URL 缺乏内链支撑。

内链同样可以这么验证：给某个重要页面新增一条入口后，观察日志里该 URL 的首次出现时间有没有提前、回访间隔有没有缩短。这比凭感觉判断结构改动是否有效要靠谱得多。

一份可以定期跑的检查清单

• 日志保留周期是否覆盖至少一个完整的抓取周期，一般 30 天起。
• 过滤规则是否把扫描器混进了蜘蛛统计。
• 是否有反向 DNS 校验，避免把伪造 UA 的请求当成蜘蛛。
• 状态码分布：4xx 与 5xx 的占比，集中在哪些目录。
• 抓取深度分布：绝大部分请求集中在第几层。
• 新旧 URL 的抓取比例，是否长期只抓旧页面。
• Sitemap 覆盖率，以及内链入口新增后的效果对比。

几个容易踩的坑

第一，只看总请求数。总量上涨但全部落在低价值页面上，对站点运营没有帮助。第二，日志经过 CDN 或负载均衡时，真实 IP 可能被替换，需要确认记录的是哪一层地址。第三，采样日志会漏掉长尾路径，做路径分析时尽量用完整日志。第四，把一次异常抖动当成趋势，判断前至少看两个完整周期。

日志不是用来堆报表的，它的价值在于把蜘蛛到过哪里这件事，从猜测变成可以核对的事实。路径问题定位清楚之后，再回到内链、Sitemap 和服务器这三件事上做调整，顺序会清楚很多。