把 HTTP 跳到 HTTPS、把带 www 的地址跳到不带 www、把旧域名跳到新域名，这些操作本身都没有问题。问题往往出在它们叠加在同一条 URL 上——蜘蛛从外链或历史记录出发，要连跳三四次才能真正拿到页面内容。
一次跳转就是一次额外的请求
蜘蛛收到 301 或 302 时，需要重新发起一次请求才能得到目标页。跳数越多，单个 URL 占用的抓取资源越多，抓取节奏也越慢。对于抓取频次本来就有限的站点，这部分损耗并不小，尤其是那些被大量内链或外链指向的旧地址。
常见的跳转叠加场景
- HTTP 跳 HTTPS
- 带 www 跳不带 www（或反向）
- 旧域名跳新域名
- 缺少尾斜杠跳带尾斜杠
- 移动端 m 站跳主站
- 大写路径跳小写路径
- 带追踪参数跳纯净地址
单独看每一条都很合理，但叠加起来就是一条长链：http://www.example.com/old-path 先跳 HTTPS，再跳无 www，再去掉尾斜杠差异，最后才落到最终地址。中间每一步都会产生一次响应，也都会被蜘蛛逐次请求。
循环跳转与跳回原处
循环重定向表现为 A 跳 B、B 又跳回 A，蜘蛛在若干次尝试后会放弃这条路径。更隐蔽的情况是配置冲突：CDN 层把 HTTPS 跳回 HTTP，源站层又把 HTTP 跳向 HTTPS，两边规则单独检查都没写错，合起来却成了死循环。日志里同一个 IP 反复请求同一批 URL、状态码在 301 与 200 之间来回摆动，通常就是这类问题。
301 与 302 的使用差别
永久迁移用 301，临时调整用 302。长期用 302 做域名迁移，会让蜘蛛持续访问旧地址去确认跳转关系，延缓新地址的抓取节奏。反过来，把临时维护页配置成 301，也可能让蜘蛛把临时状态当成最终状态来处理。
让入口直接指向终点
减少跳转最直接的办法，是让所有指向站内的入口都写最终地址：
- 内链统一使用 HTTPS 与选定的域名形式
- Sitemap 中只放最终 URL，不放会跳转的旧地址
- 面包屑、主导航、页脚链接指向规范地址
- 站内搜索结果、RSS 输出的链接同样使用最终地址
外链无法控制，但站内入口是可以控制的。站内链路干净，蜘蛛顺着内链爬行时就不会反复触发跳转。
核对与收敛的顺序
- 从服务器日志中筛出状态码为 3xx 的请求，按 Location 目标分组统计
- 对跳转次数超过一次的 URL，画出完整的跳转链路
- 检查是否存在循环跳转或跳回原地址的情况
- 优先修正被大量内链指向的旧地址
- 修正后观察日志中同一批 URL 的跳转次数是否下降
处理顺序上，先解决循环和长链，再处理单次跳转；先处理高频入口，再处理长尾地址。
容易被忽略的几处
一是二级域名或区域站的跳转链路，往往比主站更长；二是图片、CSS、JS 等资源的跳转，虽然不直接决定页面是否被收录，但会拖慢渲染与抓取速度；三是移动端适配跳转，如果 m 站与主站互相跳转，表现上和循环跳转非常接近。
重定向本身不是问题，链路长期无人打理才是。把站内入口统一到最终地址，剩下的跳转留给必要的历史兼容即可。