蜘蛛池里的入口页大多不是终点，真正的目标是让蜘蛛顺着入口页走到目标站。这时候就有一个很具体的工程问题：入口页用什么方式把蜘蛛“送”过去？301、302、meta 刷新、JavaScript 跳转，看起来都是跳转，但蜘蛛处理它们的方式并不一样，选错会让目标页白白丢掉一次被发现的机会。
先分清两类跳转
从实现层面看，跳转可以分成服务端和客户端两大类。服务端跳转在 HTTP 响应头里就完成了，蜘蛛拿到响应头就知道该去哪；客户端跳转要先下载并执行页面里的代码，蜘蛛才知道下一步。这个差别直接决定了抓取链路的长度和不确定性。
服务端跳转：301、302、307
- 301 永久跳转：语义是“这个地址以后一直指向新地址”。蜘蛛通常会记住新地址，并在后续抓取中直接访问新地址，适合入口页彻底弃用、把抓取都交给目标页的场景。
- 302/307 临时跳转：语义是“暂时指过去”。蜘蛛一般会跟过去看一眼，但不会把原地址替换掉，后续可能还会反复回到原地址确认，适合活动页或临时导流。
- 跳转链条：A→B→C 这种多级跳转，每多一层就多一次请求，蜘蛛在半路放弃的概率会上升。能一步到位就别绕。
客户端跳转：meta refresh 与 JavaScript
- meta refresh：写在 HTML 的 head 里，设置为 0 秒即跳。多数主流蜘蛛能识别并跟随，但它属于 HTML 层，仍然需要先完整拿到页面。
- JavaScript 跳转：通过 location.href 等方式执行。能执行 JS 的蜘蛛会跟，不能执行的就停在入口页，对不确定抓取能力的蜘蛛来说风险最高。
- 用户点击跳转：放一个“点击进入”的链接，蜘蛛虽然会顺着 a 标签爬，但这类链接在页面上往往被弱化，实际被发现的比例不稳定。
蜘蛛面对不同跳转的常见表现
- 遇到服务端 3xx：直接看 Location 头，链路最短，也最容易被记进抓取队列。
- 遇到 meta refresh：先抓完入口页，再解析 head，再发起第二次请求，多一次往返。
- 遇到 JS 跳转：取决于渲染能力，同一个地址在不同蜘蛛那里结果可能完全不同。
- 遇到跳转到 404 或超时：这次抓取基本白跑，还可能拖低该入口页后续的抓取优先级。
按场景怎么选
- 入口页只是过渡、目标页才是长期内容：优先 301，语义清晰，链路干净。
- 入口页需要保留、只是临时导流：用 302，避免蜘蛛把入口页从索引里换掉。
- 入口页要展示一段说明文字，同时引导蜘蛛继续走：可以让服务端跳转与页面正文并存，但注意别让页面内容与目标页完全重复。
- 目标地址需要根据来源动态判断：能服务端处理就别推给 JS，少一次渲染的不确定性。
- 跳转目标按批次固定，别让同一个入口页今天跳 A、明天跳 B，蜘蛛容易判断为不稳定。
几个容易踩的坑
- 用 JS 跳转却指望所有蜘蛛都能跟过去，等于把结果押在不确定因素上。
- 301 跳到一个同样会跳转的中间页，形成链条，白耗抓取预算。
- 跳转目标带一串随机参数，每次抓取地址都不同，等于制造了大量重复 URL。
- 入口页跳向一个返回 5xx 的目标，蜘蛛会把这笔账记在入口页身上。
跳转只是把蜘蛛带到门口，门后有没有可抓的内容、返回什么状态码，才是决定这次抓取有没有价值的部分。
落地时的几条建议
把跳转方式当成接口约定来管理：入口页模板统一使用同一种跳转方式，目标地址集中配置，改的时候改一处而不是到处改。上线后观察日志里的抓取路径，看蜘蛛是停在了入口页还是走到了目标页，这比凭感觉判断可靠得多。同时给跳转目标做状态码和响应时间的例行检查，跳转本身没问题、目标页打不开，前面的功夫一样会白费。