为什么重定向链值得单独检查
一条 301 跳转本身没有错，它本来就是迁移时的正常工具。问题出在“叠加”：旧地址跳到新地址，新地址又触发了 www 规范化，接着再补一次 HTTPS 跳转，用户和蜘蛛就要走三步才拿到内容。每一次跳转都意味着一次完整的请求响应往返，服务器要处理、浏览器要等待、抓取程序要重新判断目标。抓取资源有限时，这些多出来的步骤并不会换来额外内容，只是把同一次访问拆成了好几笔。
对用户来说，多跳意味着更长的首屏等待，移动网络下尤其明显；对站点来说，跳转规则越堆越多，排查问题的成本也在上升。
链条通常是怎么长出来的
- 域名迁移叠规范化：旧域名先跳到新域名，新域名再跳到带 www 或 HTTPS 的版本，两段规则各管一段，合起来就是一条长链。
- 栏目改版多次调整：目录名改过一次，slug 规则又改过一次，中间没有合并规则，旧地址就一路跳到底。
- 协议升级不彻底：http 跳到 http-www，再跳到 https，而不是直接跳到最终地址。
- 细节规则分散：末尾斜杠、大小写、默认文件名各自写了一条跳转，互相衔接。
- 分层配置重复：CDN 或反向代理层加了一条，源站配置里又加了一条。
- 临时跳转忘记清理：活动页、短链、A/B 测试用的跳转上线后一直挂着。
自查方法
最直接的方式是看真实响应。先不带跟随参数看单跳，再带跟随参数看全程：
curl -sI http://example.com/old-path | grep -iE 'HTTP|location'
curl -sIL http://example.com/old-path | grep -iE 'HTTP|location'
前者能看到第一步的状态码和 Location，后者能看到整条链上的状态码序列。重点看三件事：跳了几次、每一跳指向哪里、最后一跳是不是 200。
单个 URL 看明白之后，可以扩大到全站：用站内爬虫导出所有 3xx 响应，按“来源地址”和“目标地址”聚合成表；在服务器访问日志里过滤 301、302 状态码，统计出现次数最多的跳转路径；再对照站点的入口链接，确认导航和地图里没有指向前置跳转的旧地址。把这三份数据放在一起，多余的环节通常一眼就能看出来。
修复时的几条原则
- 目标直达：把中间环节合并，让旧地址一次跳到最终地址，而不是跳给另一个会再跳的地址。
- 一类规则一处处理：协议、主机名、斜杠、大小写统一放在入口层判断，不要散落在各栏目配置里。
- 控制深度：尽量保持一跳，个别历史原因复杂的场景也不要超过两跳。
- 规则要能删：下线的栏目、废弃的活动页，对应的跳转该清理就清理，规则表只增不减迟早会乱。
- 目标必须是 200：跳转到另一个 3xx、或者跳到 404 页面，等于把问题从一段搬到另一段。
不同状态码怎么选
301 永久重定向适合内容永久搬家、目录结构调整，搜索引擎会逐步把索引里的地址替换成新地址。需要注意的是这属于信号传递，并不等于立刻完成更新。
302、307 临时重定向适合活动页、维护期、临时分流。长期挂着临时跳转，会让人和抓取程序都难以判断哪个才是正式地址，旧地址可能被反复访问。
还有一点常被忽略：不要为了“看起来更安全”在 301 和 302 之间来回切换，也不要用多个跳转去模拟一次迁移。规则稳定、指向明确，比跳转类型本身更重要。
改完之后怎么验证
- 抽查十个左右的高频入口 URL，确认是一跳到位且落点返回 200。
- 过几天再看访问日志，观察 3xx 请求占比是否下降。
- 确认落地页自身没有再次触发跳转，比如又被 www 规则或语言规则接管。
- 把跳转规则和变更日期记录下来，下次改版之前先翻一遍，避免重复叠加。
小结
重定向是迁移和调整留下的副产品，没人主动维护就会一层层堆积。定期花十几分钟抽查一批入口 URL，看看状态码序列和落点，往往比出问题之后再从头排查省事得多。