做站的過程中，重定向几乎是绕不開的操作：換域名、改 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。
- 检查站内是否還有指向舊地址的連結没有被替換。
- 检查站点地图里寫的是不是最终地址。
- 观察一段時間，看舊地址是否逐渐淡出、新地址是否開始被正常訪問。
重定向本身不是坏事，它是把舊地址的积累传递下去的正常手段。真正麻烦的是鏈子被拉長、被中途打断，或者每一跳都在传递互相矛盾的信号。把這些收干净，剩下的就是等蜘蛛按它自己的节奏走完這段路。
不用為了“看起来整齐”去制造跳轉。能一跳解决的事，不要拆成三跳。