网站改版、换域名、调整栏目结构之后，旧地址一般会通过 301 指向新地址。问题在于，这类跳转往往不是一次做完的：第一次改版把 A 指向 B，第二次改版又把 B 指向 C，几年下来，一个老链接可能要走三四跳才落到能打开的页面上。平时点着看不出大毛病，但在抓取和速度层面，这些链路会一点点积累成本。
重定向链是怎么堆起来的
多数多层跳转不是有人故意设计，而是几次改动叠加的结果：
- 域名层面：http 跳 https、裸域跳 www，再叠加一次目录调整，一次访问就产生三次跳转。
- 栏目调整：旧栏目整体指向新栏目，新栏目后来又换了地址，旧地址没有同步更新，于是变成两跳。
- 插件与配置：CMS 或 CDN 自动补尾斜杠、自动加语言前缀，与人工写的跳转规则撞在一起。
- 临时跳转：为上线测试写的 302 一直没撤，时间久了被当成长期规则使用。
需要重点排查的几种形态
- 多层跳转：A → B → C → D。每多一跳就多一次请求，抓取工具和浏览器都要多等一轮。
- 循环跳转：A → B → A，或者自己跳自己，访问者会直接看到报错页。
- 跳到 404：旧地址确实做了跳转，但目标页早已删除，等于把问题往后推了一站。
- 全量跳首页：整个旧栏目的地址统统指向首页，用户找不到原内容，搜索引擎也难以判断新旧对应关系。
- 大小写与尾斜杠差异：/Page 和 /page、/a 和 /a/ 之间互相跳，形成没有必要的往返。
- 内链仍指向旧地址：站内导航、正文链接、Sitemap 里还是老 URL，等于自己给自己制造跳转。
把跳转链盘出来的做法
- 先收集地址来源：历史版本的 Sitemap、抓取日志里出现过的旧地址、后台的失效链接报告、老页面的导出清单。
- 用命令行看链路：curl -IL 加目标地址，可以打印完整的响应头序列，状态码和 Location 一目了然；去掉 -L 则只看第一跳。
- 在浏览器开发者工具的 Network 面板里打开一个旧链接，看请求列表中出现几次文档类型请求，几次就是几跳。
- 用爬虫工具批量跑站内链接，导出重定向类型的地址列表，按跳转次数排序，优先处理三跳以上的。
- 抽样打开跳转后的落地页，确认内容主题与旧地址是否相关，别只看状态码是 200 就放过。
修复时的几条原则
- 一跳到位：能直接指到最终地址的，就不要中间再垫一层，把 A 的规则改成指向 D。
- 能改链接就别靠跳转：站内导航、正文、Sitemap 里的地址直接写成最终 URL，跳转留给站外和无法修改的历史链接。
- 永久迁移用 301：确认不再回头的地址用 301，临时调整才用 302，并且记得撤掉。
- 别做全站兜底跳首页：规则尽量精确匹配，宁可让确实失效的地址返回 404，也不要让所有旧地址都堆到首页。
- 改动后回归验证：修完用同一批地址再跑一遍，确认没有新增循环和断链。
重定向是给旧地址留的一个出口，不是可以长期通行的主干道。链路越短，抓取和访问的损耗越小。
容易被忽略的细节
- CDN 和源站各配了一条跳转规则，看似一条，实际叠加成两条。
- 跳转过程中丢掉查询参数，落地页内容与用户预期不一致。
- 移动端单独域名或单独目录有自己的一套规则，桌面端修好了，手机端还在绕。
- 测试环境的规则被同步到正式环境，出现指向内部地址的跳转。
重定向链不是什么高深的问题，但它和抓取预算、打开速度、页面主题判断都有关。建议把这项工作放进改版流程的收尾清单，每次结构调整后跑一遍；日常结合抓取日志看看 301 的访问量有没有异常抬头，比等到访问者反馈打不开再回头查要轻松得多。