改版、换域名、调整栏目路径之后，重定向往往是临时补丁。时间一长，补丁叠补丁，就会出现 A 跳到 B、B 跳到 C、C 才是最终页面的情况。对用户来说只是多等一会儿，对搜索引擎抓取来说，每一次跳转都要重新发起请求，链路过长会稀释传递效果，也容易在日志里制造大量非 200 状态。
重定向链是怎么堆起来的
常见来源有几类，多数不是故意设计，而是分阶段调整后没有回头合并。
- 旧域名先 301 到新域名，新域名又因为路径调整再 301 到新路径；
- HTTP 跳到 HTTPS，HTTPS 再跳带 www 或去 www，最后才到内容页；
- 栏目改名后，旧栏目跳到新栏目，新栏目又跳到大类目；
- 为了统计点击，中间加了一层跳转页；
- 早期用 302 临时跳转，后来忘记改成 301，链接一直停留在中间地址。
自查时重点看什么
不需要复杂工具，选一批有代表性的 URL，覆盖首页、栏目页、详情页、旧活动页，逐个检查跳转过程。可以用浏览器开发者工具查看网络请求，或用 curl 查看响应头。
检查以下项目：
- 跳转次数：从旧地址到最终 200 页面，超过一次 301 就值得优化；
- 状态码：长期跳转用 301，临时活动用 302 或 307，但活动结束要清理；
- 最终地址：是否返回 200，是否和站内链接、sitemap 中的地址一致；
- 循环和断链：有没有 A 跳 B、B 又跳 A，或者跳到已经不存在的页面；
- 协议与主机名：http、https、www、非 www 是否在一开始就统一，不要留到最后一步；
- 大小写与结尾斜杠：同一路径的不同写法是否都收敛到同一个最终 URL。
处理原则：一步到位，内部链接同步更新
最理想的状态是，旧 URL 一次 301 直接指向最终 URL，中间不经过任何中转。做法不复杂：把重定向规则按最终目标重写，删掉中间跳转；同时把站内链接、导航、面包屑、sitemap 中的地址统一替换为最终地址。重定向只负责承接外部旧链接和用户书签，不应该成为站内主要链接方式。
如果存在多级域名或协议跳转，优先在服务器或 CDN 层把 http 到 https、裸域到 www 的规则合并，确保第一次跳转就同时完成协议和主机名统一。
验证与日常维护
改完规则后，重新抽查一批旧 URL，确认链路缩短、最终 200。之后可以定期看服务器日志中 301、302 的请求量：如果某些旧地址长期占据较高比例，说明要么外部链接还在用，要么站内还有漏改的入口。把高频旧地址列出来，优先修正。
重定向是搬迁时的桥，不是长期居住的房子。桥越多，走起来越慢，也越容易在某一段断掉。
最后提醒一点：每次改版或栏目调整前，先列出受影响 URL 清单，规划好最终地址，再写重定向。不要等上线后才靠日志反推，那样很容易留下层层跳转和无人维护的中间页。