站点改版、栏目调整、域名切换，都会产生重定向。单个跳转本身没问题，麻烦的是跳转叠跳转：A 跳到 B，B 又跳到 C，用户和蜘蛛每走一步都要多等一次请求。这条链越长，抓取预算被消耗得越多，页面的最终地址也越容易被误判。
什么样的跳转算“链路过长”
通常建议尽量控制在一跳以内，超过两三次就该检查了。下面几种情况最容易堆积层级：
- 旧域名整体 301 到新域名，新域名内部又有一层栏目改版跳转；
- HTTPS 升级时保留了 HTTP 到 HTTPS 的跳转，同时旧的 http 页面又指向带 www 的地址；
- 尾部斜杠、大小写、带不带 index.html 各写一条规则，彼此互相指向；
- 历史上反复改版，每次都在上一条规则后面追加，没人清理。
自查的具体做法
第一步：抽一批入口地址实测
挑首页、栏目页、详情页、旧文章地址各若干条，用命令行工具查看响应头里的 Location，或者用浏览器开发者工具的网络面板看请求序列。重点不是看有没有跳转，而是看跳了几次、每一次跳到哪里。
第二步：用抓取工具批量跑
把站点地图里的 URL 导出来，批量请求并导出跳转链报表。几百条地址跑一遍，通常能发现一批共性问题，比如某条规则写得过于宽泛，把整段路径都套了进去。
第三步：比对服务器日志
访问日志里 301 和 302 的响应会记录来源与目标。观察一段时间，能看出蜘蛛是否在反复请求同一个旧地址、是否总在跳转链中间停下。
修复时的几个原则
- 直接指向终点。把中间环节删掉，让旧地址一次跳到最终地址，而不是逐级传递。
- 内部链接不经过跳转。站内导航、正文链接、站点地图里都应写最终地址，跳转只留给外部引用和历史遗留入口。
- 该用 301 就别用 302。永久性变更用 301，临时活动、测试之类的场景才用 302，别让临时跳转长期挂着。
- 排查循环。A 跳 B、B 跳 A 会直接让抓取失败，这类规则要在测试环境先验证。
- 规则合并。能用一条规则覆盖的情况，就不要写十条零散条目。
上线之后的维护习惯
- 每次改版或栏目调整后，把新增的重定向规则登记在文档里，写明生效时间和原因；
- 定期（比如每季度）复查一次规则表，删掉已经确认没有流量的旧条目；
- 站点地图和内部链接发布前做一次校验，避免新页面一上线就带着跳转；
- 关注日志中跳转响应占比的变化，突然升高通常意味着出现了新问题。
重定向是过渡手段，不是长期方案。规则表越干净，蜘蛛和访客要走的路就越短。