做站时间长了，重定向几乎是绕不开的东西：换域名、换目录、合并栏目、下架产品、从 HTTP 升到 HTTPS，都会留下一批 301。问题不在跳转本身，而在于没人回头清理，规则一层叠一层，最后变成一条谁都不想走的路。蜘蛛走到这里要多花几个来回，用户看到的是迟迟不出现的页面，而日志里状态码一多，排查别的问题也更费劲。
跳转链是怎么长出来的
大多数跳转链不是一次设计出来的，而是几次改动叠加的结果。第一次改版把 /a/ 指到 /b/，第二次又把 /b/ 指到 /c/，两边的规则都还留在配置里，于是访问 /a/ 就变成了两跳。常见的形态大致有这几种：
- HTTP 跳 HTTPS 一次、非 www 跳 www 一次，再加上尾斜杠，三次跳转才落到终点。
- 旧栏目整体重定向到一个中间页，中间页又重定向到新的列表页。
- 页面早就删了，旧规则却仍然指向一个已经 404 的地址，用户点进来只看到错误页。
- 当初为了活动加的 302 临时跳转，活动结束后没人改回 301 或直接落地。
- 规则互相咬合形成循环，A 指 B、B 指 A，浏览器直接报错。
- 跳转目标带着查询参数，工具跑一轮下来，地址数量比真实页面多出好几倍。
判断标准其实很简单：从入口地址到最终落地页，中间任何多余的一跳，都值得问一句为什么还在。
用命令行把链路走一遍
不需要多复杂的工具，curl 就能把跳转过程摊开来看：
- 用 curl -I 请求地址，看返回的 Location，再手动请求这个 Location，重复几次直到状态码变成 200。
- 想省事一点，用 curl -sIL -o /dev/null -w '%{num_redirects}' 看跳转次数，数字大于 1 就要留意。
- 加上 -w '%{url_effective}' 看最终落到哪个地址，确认它和你想给的终点一致。
- 把站点的主要入口地址列一张表，逐个跑一遍，记录跳转次数和最终地址。
- 翻一段时间的访问日志，统计 301、302 出现的次数，找出被反复命中的跳转规则。
- 顺手核对 sitemap 和内链写的是不是最终地址，如果写的还是起点，等于每天都在主动制造跳转。
如果站点规模大，用爬虫工具跑一遍全站，按跳转次数排序，通常前几十个地址就能覆盖大部分问题。
修的时候按这个顺序来
修跳转链不是把所有规则都删掉，而是保证每个入口只跳一次，并且跳到对的终点。可以按下面的顺序处理：
- 先把协议和主机名统一，HTTP、非 www、尾斜杠这些基础规则整理到一起，避免在别的跳转上再叠一层。
- 把指向中间页的规则改成直接指向最终页，中间地址如果还有人访问，也让它直接跳终点。
- 更新站内链接和 sitemap，让它们从一开始就写终点地址，而不是让蜘蛛自己跳过去。
- 确定不再提供的内容，用 404 或 410 明确表达，不要统一甩到首页，那样只会让用户和蜘蛛在一个无关页面上打转。
- 对确实需要保留的临时跳转设一个复查时间，到期就处理，别让它一直挂着。
- 改完规则后按同样的方法再跑一遍，确认跳转次数降到 1 以内，且没有循环。
改动跳转规则前，先导出当前配置或至少记下改了什么。规则写错的时候，可能不只是某个页面进不去，而是整站入口都被绕进死循环。
上线前后各看一眼
后续再动站点结构时，把这几件事固定成习惯：上线前拿主要入口地址跑一遍跳转检查；上线后隔一两天再看日志里 301、302 的分布有没有异常升高；维护一份跳转清单，记录每条规则的目的和创建时间；每次改版前先搜一遍现有的重定向规则，避免重复添加。
跳转链不是立刻要命的问题，但它会慢慢吃掉抓取和耐心。把它当成一次普通的整理，花一两个小时把链路理顺，后面每次改动都会轻松一些。