入口页本身不是终点，它更像一块路牌。蜘蛛来到这里之后，下一步能不能顺利到达目标页，取决于你用什么方式把它送过去。跳转方式属于那种平时没人注意、出问题时又很难排查的环节，值得单独拿出来讲清楚。
四种常见做法
301 永久跳转
服务器直接返回 301，并给出 Location 头。蜘蛛在 HTTP 层就能拿到目标地址，不需要渲染页面，也不用等脚本执行。优点是路径短、确定性高，适合入口页与目标页长期绑定的情况。代价是灵活性低，一旦要换方向，等于重新建立一条链路。
302 与 307 临时跳转
临时跳转适合测试期或短期投放。搜索引擎对 302 的处理相对保守，传递的信号比 301 弱，也更可能反复确认。307 在请求方法语义上更严格，放到抓取场景里，与 302 的差别并不大，不必为了这个细节纠结。
JS 跳转
用脚本修改地址，蜘蛛必须先执行 JS 才能看到目标。这会把它推进渲染队列，时间不确定，部分抓取行为可能根本不执行脚本。如果你无法确认对方是否渲染，这条路就只能算补充，不能当主路径。
meta refresh
写在 head 中的刷新声明，零秒版本对多数蜘蛛是可读的，但优先级低于服务器跳转，也容易被理解为页面自身内容不够，只能靠跳走。带延迟的刷新更麻烦，蜘蛛不一定愿意等。
不跳转，直接放链接
在入口页正文里放一个普通链接，让蜘蛛自己决定跟不跟。这是最笨的方式，也是最透明的方式——锚文本、上下文、周围内容它都能看到。很多场景下，它比花哨的跳转更有效。
蜘蛛实际怎么处理
- 服务器返回的 3xx 状态码优先级最高，蜘蛛在 HTTP 层就完成识别。
- JS 跳转依赖渲染，可能进入二次抓取，到达时间不确定。
- meta refresh 需要解析 head 区域，通常能识别，但不如 3xx 直接。
- 普通链接最容易被理解，因为它本身就是页面内容的一部分。
几处容易踩的坑
- 跳转链太长：入口页到 A，A 再到 B，B 才是目标页。每多一跳，丢一次的概率就多一分。
- 同一批入口页里 301 与 302 混用，出问题时不方便定位。
- 目标页自身不可访问，跳过去也拿不到东西，先确认目标页正常返回。
- 跳转地址带会话参数，同一目标页生成多个 URL，反而分散了抓取。
- 把跳转写进脚本的加载回调里，页面又做了懒加载，蜘蛛可能先看到一个空壳。
落地建议
- 入口页与目标页关系长期稳定时，优先用服务器端 301。
- 测试阶段用 302，确认链路没问题再固化。
- 不要为了统计或绕行叠加多层跳转，链路越简单越好。
- JS 与 meta refresh 只作为补充手段，不要作为主路径。
- 每批入口页上线后抽查响应头，确认状态码和 Location 与预期一致。
- 记录每条入口页的跳转去向，方便后续止损和替换。
跳转的本质，是让蜘蛛用最小的成本知道下一页在哪。越靠近 HTTP 层越稳，越靠近渲染层越慢。
把跳转当成基础设施，而不是当成技巧。这样在批量维护、替换和排查时，你会省下很多力气。