批量查收录：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /31438ceb7553.html
📄
批量查收录：日志中应该核对哪些字段
用日志批量核对收录情况时，最该先看的不是访问量，而是能区分“搜索引擎来过”“抓到了什么”“是否被拒绝”的字段。建议固定核对六类：时间、客户端标识、请求方法、URL与状态码、响应大小、User-Agent与来源。下面按可执行清单逐项说明。
时间字段：确认抓取发生在哪个窗口
要查的是日志行首的时间戳，以及它所在的时区。做法是先把日志时间与服务器时区对齐，再按天或按小时切分。结果说明的是：这段时间内搜索引擎是否来过、频率是否稳定。如果时间戳跨时区混用，后续所有统计都会偏移，批量核对会直接失真。适用条件是服务器日志、CDN日志或搜索引擎抓取统计并存时，必须先统一到同一时区再比较。
客户端标识与User-Agent：区分真实抓取和普通访问
要查的是User-Agent字段，以及日志中是否记录了反向解析后的主机名。做法是用关键词筛选常见搜索引擎爬虫标识，再对照官方公布的IP段或反向DNS验证。结果说明的是：这条记录是搜索引擎抓取，还是普通用户、监控脚本或第三方工具。注意，User-Agent可以被伪造，所以它只能作为初筛，不能单独作为收录依据。适用条件是批量导出日志后，先按UA分组，再对可疑记录做反向验证。
请求方法与URL：确认抓的是哪个地址
要查的是请求方法（通常是GET或HEAD）和完整请求URL，包括协议、主机名、路径和查询串。做法是按URL去重，统计每个地址被请求的次数和首次出现时间。结果说明的是：搜索引擎关注的是哪个版本、是否带参数、是否存在重复路径。如果同一内容出现多个URL变体，需要进一步判断规范链接和重定向是否生效。适用条件是站点有分页、筛选参数或多域名时，这一项必须单独核对。
状态码：判断抓取是否成功
要查的是响应状态码，重点看200、301、302、404、410和5xx。做法是按状态码分组，再与目标URL清单比对。结果说明的是：200表示正常返回，301/302表示发生了跳转，404/410表示地址不可用，5xx表示服务器端出错。需要区分“可能原因”和“已经定位的原因”：出现大量404可能是链接失效，也可能是日志里混入了旧地址，不能只凭状态码断定收录失败。
响应大小与来源：辅助判断内容是否被完整获取
要查的是响应字节数和Referer字段（如果日志有记录）。做法是把响应大小与页面正常返回时的大小对比，并观察来源分布。结果说明的是：响应过小可能意味着返回了错误页、空页或被拦截页；来源字段可以帮助判断抓取入口是站内链接、站点地图还是外部链接。适用条件是页面体积波动大或启用了压缩时，应结合内容长度和实际返回内容一起看。
批量核对的操作顺序与交付建议
- 先统一时间与时区，导出目标时间段的日志。
- 按User-Agent初筛搜索引擎抓取记录。
- 按URL去重，生成“URL—状态码—首次抓取时间”对照表。
- 标记异常状态码和异常响应大小，逐条确认原因。
- 把确认结果写成清单交付，注明哪些是已定位问题，哪些只是待验证现象。
多人协作时，建议在交付物里固定三列：核对字段、判断依据、结论。这样下一轮复查可以直接复用，减少返工。下一步可以先拿一天日志跑一遍上述字段，确认时区和UA筛选规则是否稳定，再扩大批量范围。
