爬虫日志分析，日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /902155a99f13.html
📄
爬虫日志分析，日志中应该核对哪些字段
做爬虫日志分析，日志中至少要核对六类字段：请求时间、请求方法、请求 URL、HTTP 状态码、User-Agent、响应字节数。缺少其中任何一类，都会让后续判断变成猜谜。如果日志还带有 Referer、来源 IP、响应时间，可以进一步区分正常抓取、异常请求和资源浪费。下面从“要交付什么结论”倒推，说明每个字段用来回答什么问题，以及两种常见处理方案的适用条件。
先明确交付结果，再决定核对哪些字段
爬虫日志分析的交付结果通常只有三种：某类爬虫抓了哪些页面、哪些页面被反复抓取或抓取失败、哪些目录被浪费在无价值 URL 上。倒推回来，必需资料就是能标识“谁、什么时候、请求了什么、结果如何”的字段。责任划分上，日志采集由运维或后端负责，字段解析和归类由 SEO 或数据分析负责，验收标准是同一批日志能被稳定还原成上述三类结论。
可执行的检查项：
- 时间字段能否对应到具体时区，否则跨天统计会错位。
- URL 字段是否包含查询参数，否则分页、筛选参数造成的重复抓取会被漏掉。
- 状态码是否为独立字段，而不是混在 URL 或备注里。
- User-Agent 是否为完整原始值，而不是被中间件截断或统一改写。
六个核心字段各自回答什么问题
请求时间用于判断抓取频率和时段分布。如果同一 URL 在短时间内被同一 User-Agent 请求多次，可能是抓取预算被浪费，也可能是站点返回了不稳定状态导致重试，需要结合状态码区分。
请求方法主要看 GET 与 HEAD。HEAD 请求通常只取响应头，不代表页面被完整抓取；如果日志里 HEAD 占比很高，不能直接当作内容抓取量。
请求 URL是分析的主体。核对时要去掉协议和域名前缀，保留路径与参数，才能看清哪些目录被抓得最多。带参数的 URL 要单独标记，避免把同一内容的多个参数版本算成多个页面。
HTTP 状态码决定这条记录是否算有效抓取。200 表示正常返回，301 和 302 表示跳转，404 表示目标不存在，403 和 429 往往与访问限制或频率控制有关，5xx 则偏向服务端问题。状态码分布是判断抓取健康度的第一指标。
User-Agent用来识别爬虫身份。核对时要看完整字符串，而不是只看是否包含某个词。不同搜索引擎的爬虫 UA 不同，需要分别核查，不能因为一个 UA 通过就认为所有爬虫都正常。
响应字节数用于发现“状态码正常但内容为空”的情况。一个 200 响应如果字节数极小，可能是错误页、占位页或软 404，单看状态码会误判。
两种处理方案的比较与适用条件
方案一：只核对状态码、URL 和 User-Agent。适合日志量大、只想快速看抓取总量和错误分布的阶段。优点是解析快、存储压力小；缺点是发现不了软 404、参数重复和空响应。
方案二：核对全部六类字段，并保留 Referer、响应时间。适合需要定位具体问题、评估抓取预算分配的阶段。优点是结论可追溯；缺点是日志存储和解析成本更高，需要先确认日志保留周期。
判断依据：如果目标是回答“抓取量涨了还是跌了”，方案一够用；如果目标是回答“为什么某些页面没被有效抓取”，必须用方案二。两者不是替代关系，而是先粗后细的关系。
一个假设例子说明如何判断
假设某目录一周内有 5000 条请求记录，其中 4800 条状态码为 200，但响应字节数都低于 1KB，同时 URL 带有不同排序参数。单看状态码会得出“抓取正常”的结论；补上字节数和 URL 参数后，可以判断这是参数重复加空内容，属于抓取浪费。此时应先处理参数规范，而不是继续增加内容。
如果同一批记录里出现大量 429，则要区分是爬虫频率过高，还是站点主动限流。前者需要调整抓取节奏，后者需要检查服务端配置。两种原因对应不同处理，不能只凭一个现象下结论。
验收时怎么确认字段核对到位
验收标准可以设为：随机抽取 100 条日志，能独立还原出请求方、目标 URL、返回状态和响应大小；对状态码异常和字节数异常分别给出归类；对重复 URL 能说明是参数造成还是真实重复。达不到这三条，说明字段核对还不完整。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。日志分析只能反映抓取行为，不能直接推断索引结果，两者要分开看。
下一步：先取一段真实日志，按上述六个字段做一次字段完整性检查，缺哪个字段就先去补采集，再开始分析。
