重定向本身没问题，链式跳转才费劲
把一个页面 301 到新地址，是正常的站点维护动作。蜘蛛对单次重定向的处理很熟练：拿到 301，记下 Location 里的新地址，再请求一次。问题出现在跳转不止一次的时候。每多一跳，就多一次请求、多一段等待、多一条日志记录，而最终拿到的还是同一份内容。
短链和长链的差别，在少量页面上几乎看不出来；一旦站点里有几千个旧 URL 都挂着两三层跳转，这些额外请求就实实在在占掉了抓取时间。
蜘蛛处理重定向的常规流程
- 请求原地址，收到 3xx 状态码，读取响应头里的目标地址。
- 对目标地址发起一次全新请求，原来的连接和响应内容作废。
- 如果目标地址还是 3xx，重复上一步，直到拿到 200 或错误码。
- 最终把收录与权重信号记在终点 URL 上，起点 URL 逐渐从索引中退场。
中间每一跳都是真实请求，并不是“顺手带过去”。所以链路越长，单个页面的抓取成本越高。
哪些常见操作会把链拉长
- 协议与域名切换：http 跳 https，再跳带 www 的版本，两个动作串起来就是两跳。
- 尾斜杠处理：目录地址先跳到带斜杠版本，再跳到具体文件。
- 栏目迁移叠加：老栏目跳到过渡栏目，过渡栏目再跳到新栏目，最后才到详情页。
- CDN 或负载均衡层配置：边缘节点做一次地址规整，源站再做一次，链路上多了一环，而日志里未必看得全。
- 短链服务：站外短链先跳回站内，再跳一次到落地页。
这些做法单独看都合理，叠加起来就偏长了。
容易被忽略的两类跳转
meta refresh 与 JS 跳转
用 meta refresh 或脚本做的跳转，返回的是 200 状态码，蜘蛛需要先解析页面才能发现目标地址。相比 301，它多了一步解析，信号传递也没那么直接。能用服务端 301 解决的地方，尽量不要放到 HTML 层。
循环与半循环
A 跳 B、B 又跳回 A，会直接掐断这条抓取路径。还有一种更隐蔽的情况：不同版本的地址互相跳，例如带参数的地址跳到不带参数的地址，而不带参数的地址又因为重写规则被送回带参数的版本。抓取工具跑一遍就能看出来，人工翻链接却常常漏掉。
把链路压到一跳以内
- 先盘点所有返回 3xx 的 URL，在服务器日志或抓取工具的响应码分布里筛一遍。
- 把多头跳转改成“起点直连终点”，中间层不再参与转发。
- 统一协议和域名写法，内链、Sitemap、外链里发出的地址本身就用最终形态，减少无效跳转。
- 迁移结束后把过渡层地址一并更新，别让它长期挂着。
- 改完再跑一次抓取，确认响应码以 200 和少量 3xx 为主，没有成片的链路。
怎么核对效果
最省事的办法是看日志里同一路径的请求次数：如果每个旧地址进来后都跟着两三次连锁请求，说明链路还在。另一个角度是统计终点页面的整体耗时，跳转多的地址，蜘蛛从发出请求到拿到内容的总时间明显更长。
重定向是纠错工具，不是常态化的路由方案。能一次到位，就不要分两步走。
把跳转控制在必要范围内，抓取时间才会花在真正需要更新的页面上。