Baiduspider抓取日志中应该核对哪些字段：先看这五类记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6a0ddc078a02.html
📄
Baiduspider抓取日志中应该核对哪些字段：先看这五类记录
核对Baiduspider抓取日志时，最值得优先看的是：请求时间、客户端IP、User-Agent、请求方法与URL、HTTP状态码、响应大小、Referer，以及服务端记录的处理耗时。这几项能回答三个核心问题：来的到底是不是Baiduspider、它请求了哪些地址、服务器给了它什么结果。第一次接触时，不必先研究复杂报表，先把这几列筛出来，按状态码和URL分类统计，就能定位大部分抓取异常。
先确认身份：IP与User-Agent要一起看
User-Agent里出现Baiduspider字样，只能说明请求方这样声明，不能直接当作已确认身份。更稳妥的做法是把客户端IP与User-Agent放在一起核对：如果同一IP段长期以Baiduspider身份请求，且行为符合正常抓取特征，可信度更高；如果大量陌生IP都声称自己是Baiduspider，就需要进一步验证。
- User-Agent：记录完整字符串，不要只截取“Baiduspider”几个字，后面的版本与平台信息也有区分价值。
- 客户端IP：用于判断请求来源是否集中、是否存在异常分散。
- 请求时间：精确到秒，便于观察抓取频率和突发峰值。
判断结果：如果IP与User-Agent长期稳定对应，可以按正常抓取处理；如果同一User-Agent来自大量不相关IP，应先怀疑伪装抓取，再决定是否限流。
再看请求内容：URL、方法与Referer
这一步解决“它抓了什么”。日志里的请求行通常包含方法、路径和协议版本，应拆开记录。
- 请求方法：GET通常是正常抓取；大量HEAD或POST需要结合业务判断是否异常。
- 完整URL：包含路径和查询参数，便于发现参数组合爆炸或重复抓取。
- Referer：可帮助判断抓取入口，但缺失Referer并不代表异常。
可执行步骤：把日志按URL路径聚合，统计每个路径被请求的次数。如果某个带参数的列表页被反复抓取，先检查页面是否因参数不同产生大量近似内容，再决定是否用规范链接或抓取规则处理。适用条件是站点有大量动态参数；如果站点以静态页面为主，这一步的优先级可以降低。
重点看结果：状态码与响应大小
状态码是判断抓取是否顺利的核心字段。常见情况如下：
200：正常返回，继续看响应大小是否合理。301或302：跳转，需核对跳转目标是否正确、是否形成跳转链。404：页面不存在，需区分是正常下线还是误删。403或429：被拒绝或限流，可能影响抓取覆盖。500及以上：服务端错误，应优先排查程序或数据库问题。
响应大小同样重要：状态码为200但响应体极小，可能是返回了空页面或错误提示页。把状态码与响应大小交叉统计，比只看单一字段更可靠。判断结果：如果大量200请求的响应大小异常接近且偏小，应抽查实际返回内容。
排查抓取限制：robots.txt与站点地图要分开看
日志中出现对robots.txt的请求，只说明抓取方在读取规则，不代表页面一定被允许抓取。需要把robots.txt规则、日志中的实际请求和页面状态码对照起来看。
- robots.txt请求：核对返回状态码是否为200，内容是否可正常解析。
- 被限制的URL：如果日志中仍出现这些URL的请求，说明限制可能未生效或存在其他入口。
- 站点地图：日志中抓取站点地图，不等于其中的URL都会被收录，仍需看后续对具体页面的抓取记录。
注意：robots.txt的抓取限制不等于可靠的索引移除。如果页面已经被抓取并建立索引，仅靠robots.txt通常不能保证其从搜索结果中消失，需要结合页面本身的访问控制或移除请求处理。
按决策顺序执行：从异常集中处入手
第一次核对时，可以按以下顺序操作：
- 导出最近一段时间的日志，保留时间、IP、User-Agent、方法、URL、状态码、响应大小、耗时字段。
- 先筛出User-Agent含Baiduspider的记录，统计总请求量。
- 按状态码分组，找出4xx和5xx占比最高的URL路径。
- 对异常路径抽查原始日志，确认是抓取方问题还是服务端问题。
- 把确认的异常URL与robots.txt、站点地图、页面跳转规则逐项对照。
代价与选择：全量日志分析更完整，但存储和查询成本高；只保留抽样日志成本低，但可能漏掉低频异常。如果站点规模不大，先保留完整字段并按天归档即可；如果请求量很大，可先按状态码和URL路径做聚合，再保留异常样本的完整记录。
下一步，建议先固定一份日志字段清单，用一天的数据跑一遍上述分组统计。得到状态码分布后，再决定是调整抓取规则、修复服务端错误，还是继续观察抓取频率变化。
