站点运营一段时间后，很少有一次都不动链接结构的情况：换域名、上 HTTPS、栏目改名、把 .html 后缀改成目录形式，每一次调整都会留下几条 301。单条跳转本身不是问题，问题是跳转叠着跳转——访问 A 跳到 B，B 又跳到 C，用户和搜索蜘蛛每来一次就要多走一两步。
跳转链为什么值得单独查一遍
跳转链不会让页面直接被拒之门外，但它实实在在地增加了每一次请求的成本：多一次往返、多一次 DNS 或连接建立、多一段时间等待。当站内大量地址都存在两跳以上时，蜘蛛在同样时间内能走完的页面就变少了，新内容被发现的速度也会受影响。此外，跳转链还会让日志变得难以阅读，你很难判断某个地址究竟是被访问了，还是只是被人顺路点了一下。
几种常见的连环跳形态
- 协议与域名分两步走：HTTP 先跳到 HTTPS，HTTPS 再跳到带 www 的版本，一次请求走三跳。
- 栏目改名叠加单篇调整：旧栏目先指到新栏目，后来单篇文章地址又变了，于是变成旧栏目 → 新栏目 → 最终页。
- 末尾斜杠来回指：/a 指向 /a/，而 /a/ 的规则又指回 /a，形成循环，浏览器报错，蜘蛛也拿不到内容。
- 列表页规则被套用到参数地址：分页或筛选参数继承了栏目级的跳转规则，生成一批很长的中间地址。
- 插件与旧规则表残留：CMS 插件自动生成的重定向，与人工添加的规则同时生效，谁先命中取决于配置顺序。
怎么查：三条路径配合使用
- 单条验证用命令行：对可疑地址执行一次只看响应头的请求，逐跳观察状态码和 Location，重点确认是否超过两跳、是否 301 与 302 混用、终点是不是 200。
- 全站扫描用爬虫工具：跑一遍站内抓取，打开重定向报告，导出跳转层数达到两层及以上的地址清单，按出现次数排序。
- 看服务器日志：检索返回 301、302 的访问记录，被反复请求的跳转地址往往就是蜘蛛在持续消费的那条链，优先级应该排在前面。
修正时优先处理这几件事
- 合并规则：把 HTTP → HTTPS、裸域 → www、旧路径 → 新路径合成一次性直连，让请求一步落到返回 200 的目标地址。
- 限制跳转层数：以一跳为常态、两跳为上限，超过两跳的地址逐条改写，不要指望蜘蛛自己摸清路线。
- 统一末尾斜杠策略：全站只保留一种形式，另一种直接指过去，不要再反向指回来。
- 清理失效目标：跳转终点本身已经 404 的，要么改指到最相关的现存页面，要么干脆让原地址正常返回失效状态。
- 核对规则表：把迁移期用的临时规则、插件生成的规则导出来看一遍，删掉已经没有任何指向意义的条目。
- 内链写最终地址：站内链接和 sitemap 里直接写终点 URL，不要图省事继续沿用会跳转的旧地址。
跳转链本身不是错误，它只是被反复叠加之后变成了额外成本。能压到一跳的，就别留两跳；已经没人访问的旧规则，就让它安静退场。
把它变成周期性动作
重定向规则最容易在几次小改动之后悄悄膨胀，所以不适合只在出问题时才看。比较省事的做法是：每次结构调整、域名或协议变更之后跑一次全站扫描；每隔一个季度再把重定向报告和服务器日志对照着看一遍，确认跳转层数没有回升、没有新的循环出现。把这一步固定下来，链接结构就不会随着时间越缠越乱。