蜘蛛池里的入口页，很多时候并不直接放目标 URL，而是通过一跳或几跳把蜘蛛送到目标页。跳转本身没有对错，但跳转的实现方式和层数会直接影响蜘蛛能不能顺利发现目标 URL，以及这个过程要花掉多少抓取预算。
三种常见跳转方式的机制差异
- HTML 链接跳转（a 标签）：最透明的一种。蜘蛛解析源码时就能读到目标 URL，把它放进待抓队列，不需要额外执行脚本，也不需要等第二次响应。
- 服务端 3xx 跳转：蜘蛛请求入口页，服务器返回 301 或 302，蜘蛛再请求目标地址。目标 URL 会被记录下来，入口页本身则更像一个过渡角色。
- JavaScript 跳转：源码里只有脚本，目标 URL 要么藏在变量里，要么在渲染之后才生成。取决于抓取端是否渲染，蜘蛛可能看到，也可能看不到。
- meta refresh：写了延时或零延时的重定向。能否被跟随，各引擎的处理并不完全一致，而且容易和 canonical 打架。
如果同一批入口页里混用了这几种方式，日志会变得很难读——你看到的抓取量变化，可能只是换了跳转方式，而不是蜘蛛变懒了。
跳转层数：每一跳都在消耗预算
一个常见的误解是“多跳几层没关系，反正最后能到”。实际上每多一跳，蜘蛛就要多发起一次请求，多占一次连接和一次请求配额。
更现实的问题是漏抓概率。假设每跳被成功跟随的概率是九成，三跳之后大概只剩七成左右的目标页被真正触达；如果是脚本跳转，成功率还要再打折。层数越多，你越难判断“没被抓”是入口页的问题、跳转的问题，还是目标页的问题。
一个可用的经验区间
- 一跳（入口页 → 目标页）：最常见，链路清晰，排查容易。
- 两跳（入口页 → 中间页 → 目标页）：中间页要有实质内容，否则等于白建一层。
- 三跳及以上：除非中间层有独立的索引价值，否则建议合并。
容易踩坑的几种组合
- 入口页用 302 跳到中间页，中间页再用脚本跳目标页。两种不确定性叠加，日志里往往只剩入口页的访问记录。
- meta refresh 的延时写得太长，比如 10 秒以上，蜘蛛可能直接放弃等待。
- 跳转目标和入口页的 canonical 互相指向，等于给蜘蛛两个矛盾的信号。
- 入口页返回 200，但正文只有“正在跳转”，其余动作都靠脚本——这样的页面对蜘蛛几乎是空的。
- 跳转链上任意一环返回 4xx 或 5xx，整条链对蜘蛛就断了，而且短期内不会高频重试。
实操建议
- 优先用服务端 301，把跳转逻辑放在服务器而不是浏览器端。响应头和 Location 是蜘蛛最容易解析的信号。
- 如果必须用脚本跳转，同时在 HTML 里保留一个 a 标签或在 noscript 中留一条链接，给不能执行脚本的抓取留条退路。
- 把层数控制在一到两跳内，中间页要有内容，不要只是过道。
- 保持跳转目标唯一，同一个入口页不要根据 UA 或 Referer 返回不同目标，那会让排查变成猜谜。
- 跳转目标尽量避免带一次性参数，参数越多，同一个目标 URL 被反复当成新 URL 的概率越高。
- 定期抽查：随机取十几个入口页，用抓取日志或第三方工具走一遍，看每一跳的返回码和最终落点是否与预期一致。
观测与调整
观察时重点看三件事：入口页的抓取次数、跳转目标的被抓取比例、以及从入口页到目标页之间隔了多久。如果入口页天天被访问，目标页却始终没有记录，那问题多半出在跳转实现上，而不是在“蜘蛛不够用”。反过来，如果目标页被抓了但入口页几乎没有记录，说明蜘蛛是绕过入口页直接来的，入口页本身的角色需要重新评估。
跳转链是蜘蛛池里最容易被忽略、又最容易出问题的一环。它不复杂，但它决定了蜘蛛走的是直路还是迷宫。把方式统一、层数压缩、落点固定，剩下的波动才好归因。