用户点一个链接，浏览器先跳到 A，再跳到 B，最后才落到 C。这种体验不算罕见，也很容易被忽略。对蜘蛛来说，每一次跳转都是一次额外的请求，链条越长，损耗越大。跳转本身不是错误，但它会把一次抓取变成三次，也会让权重和用户耐心在中间被磨掉。
跳转链是怎么攒出来的
很少有人主动去设计一条三层跳转。多数情况是站点在持续演进中一层层叠上去的：换域名时加了整站跳转，后来某个栏目改版又加了一条规则，再后来又为了统一协议加了一条。单看每一步都合理，合起来就成了一条长链。
- 协议跳转叠加 www 与非 www 的跳转，变成两跳起步。
- 旧域名的整站规则没有排除已迁移的地址，形成二次跳转。
- 栏目改名只做了旧目录到新目录的跳转，但站内导航仍指向旧地址。
- 内容下线后先跳到栏目页，栏目页后来又改了地址，链条再加一环。
- 短链或推广链接在服务端又加了一次中转。
自查的基本方法
不需要复杂工具，关键是把「最终地址」和「经过了几步」这两个信息拿到手。
从一个入口开始逐跳记录
- 挑出站内主要入口：首页、导航里的栏目页、页脚，以及外链最多的几条内链。
- 对每个地址，记录返回状态码和 Location 指向，一次记一跳。
- 把每一跳串起来，数一数到最终正常页面用了几次 3xx。
- 重点看超过两步的链条，以及跳转后的落点与当前页面是否语义一致。
从日志里找批量问题
单页排查只能发现个例。访问日志里状态码为 301、302、308 的请求占比，以及这些请求的路径分布，能告诉你问题是局部的还是全站的。如果某个旧目录每天都有大量跳转请求，说明站内或站外还有不少链接指着它。
处理原则：能一步到位就不要两步
- 尽量直指终点。旧地址如果确定要指向新地址，就直接指向最终页面，中间不要再垫一层。
- 避免链式规则。服务器重定向尽量做到一次匹配，别让多条规则互相接力。
- 同步更新源头。把站内仍指向旧地址的链接改掉，能从根上减少跳转请求。
- 跳转类型要选对。永久迁移用 301，临时调整用 302，不要长期用 302 承担迁移任务。
- 保留必要例外。承接大量外链的老地址，跳转是有意义的，不必为了「干净」直接删掉。
判断一条链要不要拆，不只看它有几跳，还要看它承接了多少外部链接和用户习惯。链条短但落点错误，同样是问题。
容易忽略的几种情况
一是结尾斜杠。同一个页面带斜杠和不带斜杠各返回一次跳转，累积起来数量不小，最好在服务器层统一。二是大小写。有些系统对路径大小写敏感，链接里混用会多出一次跳转。三是尾随参数。旧链接带的跟踪参数被原样保留，最终地址也拖着参数，看起来像两个页面。四是移动端跳转，如果做的是独立移动域，设备判断出错会把用户和蜘蛛来回甩。
把它放进日常巡检
跳转链不是修一次就完事的东西。每次改版、换域名、调整栏目结构之后，都值得重新跑一遍核心入口。把「关键路径的跳转步数」当作一个固定观察项，比等到日志里 3xx 请求堆积再回头找原因要从容得多。