站点搬过一次家、换过一次域名、改过一次栏目名，很容易攒下一条跳转链：老地址跳新地址，新地址跳带 www 的版本，带 www 的版本再跳 https。用户在浏览器里几乎察觉不到，但蜘蛛每跟一跳，都要重新发起一次请求、重新解析一次响应头，才能继续往下走。抓取路径的长度，就是这么一点点被拉长的。
一跳和三跳，对蜘蛛不是同一件事
跳转本身不是错误，蜘蛛处理 301 很熟练。问题出在链的长度上：每多一跳，就多一次请求—响应的往返，多占一份抓取资源；同时，链尾那个真正有内容的地址，被发现的时机会往后拖。如果这条链还同时出现在内链和 Sitemap 里，蜘蛛可能反复沿着不同入口走到中间某一跳，重复付这笔成本。
先分清几种跳转
- 301 与 308：表示永久迁移，蜘蛛会把抓取和链接信号往目标地址上归拢。
- 302 与 307：表示临时，蜘蛛通常会保留原地址的抓取，不会急着替换。把永久迁移写成 302，是常见的误配。
- meta refresh 和 JS 跳转：这类跳转藏在页面内容里，蜘蛛要进入渲染环节才会发现，成本比响应头里的跳转高得多，能不依赖就不依赖。
判断标准很简单：如果这个地址以后不会再变回来，就应该用永久跳转，并且尽量让它一步到最终地址。
跳转链是怎么堆出来的
- 协议与主机名调整：http 到 https、非 www 到 www，各自加了一条规则，叠加成两跳。
- 目录结构改名：旧栏目先跳到新栏目，新栏目后来又统一挪到下二级，链就变长了。
- 结尾斜杠不统一：带斜杠和不带斜杠之间互相跳，配合上面的规则又多一跳。
- 应用层跳转：服务器规则跳一次，程序里再判断一次，同一次访问被拆成两段。
自查：把链完整拉出来看
- 用 curl -I 最终地址 看单个地址返回的状态码和 Location 指向。
- 用 curl -I -L 跟随跳转，观察从起点到终点一共经过几次 3xx，终点是不是 200。
- 从服务器日志里筛出所有 3xx 的访问，按出现频次排序，高频的跳转优先处理。
- 重点检查两种情况：链尾不是 200（落到 404 或 noindex 页），以及存在 A 跳 B、B 又跳回 A 的循环。
抽样时不用覆盖全站，把首页、主力栏目页、几个典型详情页和旧地址各测一条，基本就能看出规则有没有叠加。
把多跳收敛成一跳
- 把跳转规则放在服务器或 CDN 这一层统一处理，直接映射到最终地址，避免应用层再跳一次。
- 跳转目标写成最终形态：协议、主机名、路径、结尾斜杠一次到位，别让下一跳再修一遍。
- 内链和 Sitemap 里直接使用最终地址，不要保留旧地址作为入口，否则等于持续提醒蜘蛛去走这条链。
- 改版或迁移前先列出映射表，确认没有一条链需要经过两次以上跳转。
跳转和抓取节奏的关系
一条稳定的一跳，对抓取节奏的影响很小。真正拖后腿的是长链：蜘蛛走到中途就消耗掉一次抓取机会，链尾页面的回访间隔随之变得不稳定，新内容的发现也会变慢。把跳转当成一次实实在在的请求成本来看待，很多规则冲突在部署前就能发现。
日常做法可以很朴素：改完跳转规则后跑一遍抽样自查，确认从旧地址到新地址只经过一次 3xx，终点是 200；换域名、上 https、调整目录这类操作，尽量在做之前就规划好最终地址，减少事后追加规则的机会。