站内链接指向的地址如果已经变了，访客和搜索引擎蜘蛛并不会直接到达目标，而是先被服务器“指”到另一个地址。一跳两跳还好，怕的是跳成一串，甚至绕回原地。这类问题平时不显眼，等到抓取频率下降、访问速度变慢时才被注意到，排查起来却要翻日志、翻模板、翻历史配置。
跳转是怎么一步步变成链的
大多数跳转链不是一次决定的，而是多次改动叠加出来的。比如站点从 http 换成 https，旧地址 301 到 https 版本；后来又换了域名，旧域名再 301 到新域名；再后来栏目调整，页面从 /a/ 挪到 /b/。三次改动单独看都合理，叠加起来就是三跳。如果新内容把链接写成最早的那个地址，访客和蜘蛛就要重新走一遍这条链路。
还有一种情况来自服务器层面的默认行为：末尾斜杠自动补全、大小写自动纠正、www 与非 www 互跳。这些规则往往写在 Nginx 或 Apache 配置里，写规则的人换了，后来接手的人不知道，于是又叠上一层。
容易被忽略的几类问题
301 和 302 混用
301 表示永久迁移，302 是临时跳转。页面已经彻底换地址却用 302，蜘蛛会持续回访旧地址，抓取预算被反复消耗在一条没有终点的路上。反过来，临时活动页用了 301，等恢复时又要改回来，容易留下历史记录混乱。
重定向环
A 跳 B、B 跳 A，或者 A 到 B、B 到 C、C 又回到 A。这种配置错误通常出现在域名切换期间，CDN 回源规则和源站规则互相打架的时候。表现是浏览器报“重定向次数过多”，蜘蛛则直接放弃这一条路径。
内链仍指向旧地址
页面地址已经迁移，但导航、面包屑、正文里的链接、甚至站点地图里写的还是旧地址。每一处都在制造一跳，数量多了就是持续不断的额外开销。
参数与斜杠引起的多余跳转
带参数的首页地址跳到不带参数的首页，末尾少一个斜杠被补一次，这些看起来都很轻，但量大了会明显拖慢整站响应，也会让日志里的状态码分布变得难看。
动手自查的几种方式
- 用命令行看跳转过程。对重点 URL 发起带跟随跳转并显示响应头的请求，观察最终落点是不是你想要的地址，中间经过了几跳，状态码分别是多少。
- 看服务器日志里的状态码分布。按状态码分组统计，重点看 301、302 的数量和来源路径。排在前面的跳转源，往往就是数量最大的那批问题。
- 抽样检查站内链接。从首页、栏目页、文章页各抽一些链接，看 href 写的是当前地址还是历史地址，尤其是经历过多次改版的栏目。
- 核对配置文件。把服务器、CDN、框架路由里的跳转规则集中列出来，看有没有互相冲突、互相覆盖或者完全重复的条目。
修复的优先级
先处理重定向环和大量 302，这两类影响面最大；再把跳转链压缩到一跳，能直接指向最终地址的就直接写最终地址；最后清理站内链接和站点地图里的旧地址。修复之后仍然建议保留旧地址的跳转，不要直接删掉，因为外部链接和用户书签不会跟着你一起更新。
跳转本身不是问题，问题是没人知道现在一共跳了几跳。
隔一段时间把跳转规则重新过一遍，比等到出问题时再翻配置要轻松得多。
如果你的站点经历过换域名、换协议、换目录结构这几件事中的任意一件，就值得专门花半小时把跳转规则理一遍。这类工作不产生新内容，但能减少访客等待，也能让蜘蛛把时间花在真正需要抓的页面上。