换域名、加 www、切 HTTPS、调整目录结构，这些操作都会在站里留下一批重定向。单条 301 是常规做法，问题在于不少站点经过几轮改版后，跳转被一层层叠起来：旧地址跳中间地址，中间地址再跳当前地址。平时看不出异常，等到收录迟迟不涨、日志里某些 URL 反复被抓却始终不进索引，才回头找原因。
蜘蛛跟重定向时，实际发生了什么
重定向本身不是错误，它是一句「这个地址搬家了」。蜘蛛遇到 301 或 302 时，会按响应头里的 Location 再发一次请求，直到拿到一个最终返回 200 的页面，或者中途放弃。
关键在于，每一跳都是一次独立的请求。链条短的时候，这点开销可以忽略；链条拉到三跳以上，抓取预算就消耗在中间环节上，而这些中间地址本身没有内容，蜘蛛跑一趟拿不到任何可索引的东西。如果链条里还夹着 302、meta refresh、JS 跳转，或者中间某一跳返回 404、超时，蜘蛛很可能停在半路，终点页面自然也就不会进入索引流程。
所以判断影响时，不要只看终点页面的质量，还要看蜘蛛到达终点之前绕了多少路。
几种常见的问题链
301 与 302 混着用
临时跳转和永久跳转混在一起，蜘蛛对二者的处理态度不同。302 表达的是「暂时搬走，原地址还可能回来」，多条 302 串起来时信号会变得含糊，旧地址和当前地址都有机会被抓，收录状态也容易摇摆。确定不再回退的跳转，统一用 301。
所有旧地址一律跳首页
这是改版后最常见的偷懒做法：把大量详情页、栏目页统统 301 到首页。对用户和蜘蛛来说，这等于告诉它「这个内容没了」。原来的页面不会因此转移到新页面，首页也不会因为承接了这些跳转就多出收录。如果内容还在，就应该跳到最接近的新地址；如果内容确实下线，返回 410 比硬跳首页更干净。
终点本身是 404 或 5xx
链条中间的地址配好了跳转，终点却已经删除或服务异常，蜘蛛顺着链走到底撞上一个错误页。这种链路表面上是「已处理」，实际上整条路径都是无效的，日志里会看到同一批 URL 被反复抓、反复失败。
循环跳转与自我跳转
A 跳 B、B 跳 A，或者某个 URL 301 到自己。前者会让蜘蛛在有限次数后放弃，后者属于配置失误。这类问题通常出现在批量规则里，改版次数越多越容易残留。
怎么把链条查出来
- 抽一批重要 URL，用 curl -IL 看完整跳转链，记录每一跳的状态码和 Location。
- 在服务器日志里按 URL 分组，看同一个地址是否被连续抓取多次、后一次带的是不是跳转后的路径。
- 把站点地图里的地址和最终落地的地址做一次对照，找出需要多跳才能到达的条目。
- 关注跳转终点是否返回 200、是否有 canonical 指向别处，避免跳转和规范化信号互相矛盾。
收敛顺序：先定终点，再压平链路
- 确定每个旧地址的唯一终点。 内容还在的，指向最接近的新地址；内容下线的，用 410 明确表达，不要都丢给首页。
- 把多级跳转压平成一步。 旧地址直接 301 到最终地址，去掉中间的过渡层，让蜘蛛一次请求就到位。
- 统一跳转类型。 不再回退的用 301，避免 301、302、JS 跳转混用造成信号模糊。
- 同步内链和站点地图。 站内链接、导航、sitemap 都直接写终点地址，不要让蜘蛛从站内再走一遍旧链。
- 改完后持续观察。 看日志里中间地址的抓取是否减少、终点地址的抓取是否稳定。收敛效果以日志为准，而不是以配置文件为准。
重定向链属于基础设施层面的问题，它不会直接决定一个页面能不能被收录，但会决定蜘蛛能不能顺利、低成本地走到页面面前。链路越短、终点越明确，后续的内容质量和内链优化才有发挥的余地。
排查顺序建议从终点往回倒推：先确认终点是否正常返回，再数中间有几跳，最后检查跳转类型和内链是否一致。