做站的过程中，重定向几乎是绕不开的操作：换域名、改 URL、合并栏目、http 升级 https，都会留下一串跳转。多数时候没人管它，因为它表面上看不出问题——浏览器打开正常，用户照常访问。但对蜘蛛来说，每一次跳转都是一次额外的请求，链条越长，走到最终页面的成本越高。
蜘蛛遇到重定向时发生了什么
当蜘蛛请求一个返回 301 或 302 的地址时，它拿到的不是内容，而是一个目标地址。它会再发一次请求去取那个目标。如果目标地址本身又是重定向，就再来一遍。这个过程会占用抓取额度，也会拉长整体的响应时间。
蜘蛛通常会跟随若干跳，但不是一个无限容忍的过程。链条过长，或者中间某一跳超时、报错，它就可能在半路停下。结果就是：那个真正有内容的页面，一直没有被访问到，自然也就谈不上后续的收录。
常见的几种问题形态
- 同一件事跳了两次以上。比如 http://example.com 跳到 https://example.com，再跳到 https://www.example.com，中间还夹着一层路径改写。三跳能把事情办完，但没必要。
- 301 里套 302。永久跳转后面接一个临时跳转，蜘蛛对“临时”的理解是不确定，可能继续保留旧地址的状态。
- 跳转目标本身也返回 3xx 或 4xx。链条断在最后一步，前面几跳等于白走。
- 跳转目标带着参数或大小写变体。绕一圈又回到另一个重复版本，等于换了个地址回到原地。
- 内链仍然指向旧地址。蜘蛛顺着内链反复走同一条绕路，链路永不断干净。
301 与 302 的取舍
判断标准其实很简单：这个变化是不是长期的。如果旧地址以后不再使用，用 301；如果只是临时维护、临时切换，用 302。把 302 当成 301 长期挂着，等于告诉蜘蛛“先别急着换”，旧 URL 可能继续留在索引里，新 URL 迟迟接不上。
还有一种情况是跳转和 canonical 打架：页面本身做了 302，页上的 canonical 又指向另一个地址。信号冲突时，蜘蛛的处理方式往往和你预期的并不一致。
把链条压缩到一跳
比较省事的做法是：任何一个旧地址，直接跳向最终 URL，中间不做中转。域名迁移这种批量操作，尤其要检查是否存在“旧域名 → 中间域名 → 新域名”的串联。
- 最终 URL 只保留一个版本，其他变体一律 301 指向它。
- 站内链接、导航、面包屑、站点地图，全部写最终 URL。
- 跳转目标不要经过参数版本、大小写变体、带不带斜杠的中间态。
- 确认跳转目标返回 200，且内容与用户看到的一致。
自查的顺序
- 抽查几个典型的旧地址，看跳转链有几跳，每一跳返回什么状态码。
- 确认链条终点返回 200，而不是另一个 3xx 或 4xx。
- 检查站内是否还有指向旧地址的链接没有被替换。
- 检查站点地图里写的是不是最终地址。
- 观察一段时间，看旧地址是否逐渐淡出、新地址是否开始被正常访问。
重定向本身不是坏事，它是把旧地址的积累传递下去的正常手段。真正麻烦的是链子被拉长、被中途打断，或者每一跳都在传递互相矛盾的信号。把这些收干净，剩下的就是等蜘蛛按它自己的节奏走完这段路。
不用为了“看起来整齐”去制造跳转。能一跳解决的事，不要拆成三跳。