平台的抓取统计通常有延迟、聚合和抽样，看到的是结果，而不是过程。服务器日志是原始记录，能回答“哪个 IP 在什么时间请求了哪个 URL、返回了什么状态码、响应花了多久”。把日志读顺，抓取相关的问题往往能缩小到具体几类。

先确认请求方身份，再谈数据

User-Agent 是自称，不能单独作为判断依据。稳妥的做法是三层交叉：日志里的 UA 字符串、请求来源 IP，以及对该 IP 做反向解析得到的主机名是否属于官方网段。

• 只按 UA 过滤，会把伪装流量算进蜘蛛，也可能漏掉官方新启用的 UA。
• 反向解析要双向验证：解析出的主机名再正向解析回原 IP，才算通过。
• 云主机、爬虫代理、监控探针的 IP 经常带着相似 UA，建议单独打标签，不要混进蜘蛛统计。
• 日志保留周期至少覆盖一个完整发布周期，否则无法对比改版前后的差异。

日志里“像蜘蛛”和“是蜘蛛”是两件事，前者只能作为线索。

状态码分布能看出入口的健康度

把通过验证的蜘蛛请求按状态码分组，看比例而不是绝对数量。常见的几个信号：

• 3xx 占比偏高：说明入口链接指到了跳转地址，抓取路径多走一步；链路较长时容易在中间断掉。
• 404 集中出现：多数情况是内链指向了已删除或拼错的 URL，属于可修问题；零散 404 更可能来自站外老链接，优先级可以低一些。
• 5xx 偶发：先对齐时间点，看是否与发布、备份、缓存刷新重叠，再判断是容量问题还是代码问题。
• 304 较多：代表内容未变、蜘蛛按条件请求回访，不等于没有抓取，不必当成异常。

抓取落点分布反映预算去向

统计蜘蛛请求落在哪些 URL 类型上：栏目页、详情页、标签页、筛选参数页、站内搜索页、日历归档页。如果参数页占比很高，而详情页长期没有被访问，说明站内链接把蜘蛛引向了低价值页面。

• 对没有独立价值的参数组合，考虑 robots 规则、canonical 归并，或者干脆不输出这类链接。
• 希望被发现的详情页，检查是否存在从栏目页直达的静态链接，而不是藏在多级筛选之后。
• 站内搜索、排序、打印、分享类链接建议默认不生成可抓取 URL。

节奏与时间窗：抓取是否过于集中

按小时聚合，能看到抓取是否集中在很短的窗口、是否反复回访少数几个 URL。入口单一的站点，日志常表现为“少数页面高频、多数页面完全不出现”。这种情况下，优先补内链和聚合入口，比反复提交更有效。

同时记录响应耗时分布。耗时中位数上升时，蜘蛛通常不会长时间等待，会降低并发或放弃部分 URL，表现为抓取总量下降、深层页面更少被访问。这与状态码无关，需要单独看。

几个容易被误读的地方

1. 把 CDN 回源日志当成蜘蛛直连记录，导致重复计数。
2. 用总请求量代替已验证的蜘蛛请求量，得出“抓取暴涨”的结论。
3. 把 304 当成“没抓”，把 200 当成“已收录”。
4. 只看单日数据就下判断，忽略周内波动和发布节奏。

一份可复核的日志清单

• 验证方式、验证通过的 IP 段、统计时间范围。
• 状态码分布，以及每类状态码的 URL 样例。
• 抓取落点按 URL 类型分组的占比。
• 响应耗时中位数与 P95。
• 与上次核对的差异点，以及准备调整的入口或链接。

日志只能说明蜘蛛来过、请求了什么、拿到了什么结果，它并不直接决定内容是否被收录。把日志当成排查入口问题的工具，按上述顺序核对，比凭印象调整站点结构更容易得到可验证的结论。