搜索抓取

抓取测试的常见误判:浏览器能打开,不代表蜘蛛走得通

很多人用浏览器打开页面正常,就默认蜘蛛也能抓。其实抓取测试要分入口放行、响应头、源码里的链接、日志验证几层,不同 UA、IP、是否执行脚本都会给出不同结果。本文梳理几类常见误判,以及一套可以复用的测试流程。

搜索抓取

抓取测试的常见误判:浏览器能打开,不代表蜘蛛走得通

做抓取测试时最常见的动作,是把 URL 贴到浏览器里打开,看到页面正常渲染,就认为蜘蛛也能抓。这个判断只在少数情况下成立。浏览器带着本地缓存、Cookie、登录态,可能还挂着代理;而蜘蛛拿到的是一份全新的、没有这些上下文的请求。两者看到的结果不同,能走的路径自然也不同。

浏览器和蜘蛛的差异在哪几处

  • 身份不同:浏览器请求的 UA 是你自己,蜘蛛是它自己的 UA。服务器、CDN、防火墙都可能按 UA 分流,返回不同页面,甚至直接拦截。
  • 来源 IP 不同:地域限流、IP 信誉库、机房网段拦截,都会让同一条 URL 在两边得到不同结果。
  • 状态不同:Cookie、登录态、会话参数决定了页面返回什么内容。蜘蛛没有这些,拿到的是“未登录版本”。
  • 脚本执行不同:浏览器会执行 JS,蜘蛛是否执行、执行到什么程度,取决于引擎。源码里没有的链接,渲染后可能有;反过来也存在。

一套可以复用的抓取测试流程

第一层:入口有没有放行

先确认 robots.txt 没有挡住目标目录,再确认 CDN 与防火墙没有把搜索引擎的 UA 或 IP 段拦下来。这一步最容易被忽略,因为它在浏览器里永远看不出问题——你自己的 UA 本来就在白名单里。

第二层:状态码与响应头

用不带 Cookie 的方式请求一次,检查返回码是否为 200,是否有多余的重定向跳转,响应头里有没有 noindex、canonical 指向别处,或者按 UA 变化的 Vary 设置。重定向链每多一跳,抓取路径就多一次消耗。

第三层:内容里有没有可以继续走的链接

看返回的 HTML 源码,而不是渲染后的画面。列表页的分页、详情页的上下篇、面包屑,这些链接是否真的写在了源码里。如果链接只存在于脚本执行之后,就要确认执行 JS 的抓取方式能不能拿到它们。

第四层:回到日志确认

测试工具返回的结果只是推断,日志才是事实。观察目标 URL 在服务器日志里是否出现真实蜘蛛的记录,访问频率和返回码是否与预期一致。工具放行不等于蜘蛛会来。

几类典型的误判

  1. 用在线工具测完就当结论。工具的 UA、IP、渲染能力和真实蜘蛛不同,能通过不代表真实抓取能通过,反之亦然。
  2. 只测首页和栏目页。深层 URL 常常是参数最多、最容易被规则挡住的一批,抽样要覆盖到它们。
  3. 测试环境和线上环境不一致。测试时放行的规则,上线后可能被另一条策略覆盖。
  4. 忽略缓存层。缓存按 UA 或设备分流时,蜘蛛拿到的可能是缓存里的旧版本页面,里面的链接早已失效。
  5. 把渲染结果当成源码。一些工具默认执行脚本并展示渲染后的 DOM,看上去链接齐全,实际源码里空无一物。

把测试变成例行动作

新目录上线、改版、调整 robots 或防火墙规则之后,都值得把目标 URL 跑一遍上面的流程。把通过测试的 URL 存成一份清单,隔一段时间再抽样复查,配合日志做对照,能比较早地发现放行规则被改动,或者某类模板突然返回空内容这类问题。

抓取测试解决的是“这条路通不通”,不是“蜘蛛一定会走”。通路只是前提,走多深、走多快,还要看站点整体的结构和信号。

另外,测试结论最好记录下时间、UA、返回码和当时的规则配置。环境变化很快,一份没有上下文的“测试通过”记录,过两周基本没法复用。