改版、换域名、去掉 www、把 HTTP 跳 HTTPS，这些操作单看都没问题，问题往往出在跳转叠加：A 跳到 B，B 又跳到 C，C 才到最终页面。对访客来说只是慢了一点，对蜘蛛来说却可能意味着把抓取时间花在中间环节上，甚至中途放弃。
跳转链是怎么攒出来的
多数情况不是有人故意加了好几层，而是每次改动只处理了眼前这一跳，旧规则没清理，链条就越来越长。
- 换域名时老的 301 规则留在配置里，新域名内部又有自己的一套跳转规则；
- 页面改版把 /old/ 指向 /new/，后来 /new/ 又改成 /newer/，但第一条规则忘了删；
- 统一末尾斜杠、统一大小写、加 www 各写了一条规则，串起来就是三跳；
- 内容合并时把多个页面都指向同一个中间页，再由中间页指向最终页。
自查的实际办法
用命令行逐条走一遍
取一批站内链接和常见入口地址，用 curl -I -L 观察每一跳的状态码和 Location 头，看看是否存在超过一跳的 301 或 302，链条里是否夹着 meta refresh、JS 跳转这类需要解析才能继续的方式。
从服务器日志里找线索
看一下日志中 301、302 状态码的占比，以及同一路径反复出现的情况。如果某个旧地址长期被访问、每次都触发跳转，说明站内或站外还有链接指着它，光靠服务器规则解决不了，得把指向它的链接一起改掉。
抽查重点页面
- 首页和主要栏目入口；
- 曾经改过栏目名的分类页；
- 有外部链接的旧文章地址；
- 站点地图和分页列表里输出的链接。
修复的顺序
- 先确定每个页面的最终地址并固定下来，不要反复改；
- 把多层链条合并成一次跳转，旧地址直接指向最终地址；
- 删除链条中间那些过渡页上的跳转规则；
- 更新站内链接和站点地图，让它们直接输出最终地址，减少不必要的绕行；
- 永久迁移用 301，临时活动结束后及时撤掉 302 规则，别长期留着。
一点提醒：跳转不是越多越保险，链条越长，越容易在某一跳断掉。能直接指向最终地址的，就别绕道。
修复之后要验证什么
重新走一遍 curl，确认每条只剩一跳；再看日志里 301、302 的数量是否下降；抽样核对最终页面的 canonical 与站点地图地址是否和最终 URL 一致。如果最终地址本身还带着大小写不一致或多余参数，等于又埋了一个新的分叉点。
和蜘蛛的关系
蜘蛛对跳转是能处理的，但每一跳都要重新发起请求、重新等待响应。站内链接如果大量经过跳转，相当于自己给自己设置了减速带，抓取节奏自然会慢下来。把跳转收干净是基础工作，不保证收录，也不保证排名，但至少不会让蜘蛛把时间浪费在中间页上。