改版、換域名、合並栏目，這些動作在运营节奏里很常见。真正容易出問题的往往不是新頁面本身，而是那些已经存在了几年的老連結。它們還挂在用戶的收藏夹、外部引用和搜尋引擎的索引里，如果跳轉没處理好，蜘蛛每次来訪都要在一串重定向里多走几步。
重定向鏈是怎么被放大的
單次跳轉本身没什么成本，但索引里的老 URL 數量常常遠超预期。一個栏目頁可能被多個入口收錄，每個入口都指向同一條鏈，抓取预算就在這些重复動作里被消耗。重定向鏈越長，蜘蛛愿意繼續跟下去的概率越低，尤其是鏈條末端還不稳定的情况。
更隐蔽的問题是循环跳轉：A 跳到 B，B 又回到 A。蜘蛛通常會放弃，但每次抓取都會重新试一遍，日誌里會反复出現同一批地址。
一次合格的重定向應该是什么样
跳一次就到位
舊地址直接用 301 指向最终的新地址，不要先跳到中間頁、再跳第二次。鏈條超過两跳就该整理，超過三步基本值得單獨排期處理。
狀態碼要選對
- 永久迁移：用 301，搜尋引擎會逐步把索引和權重迁到新地址。
- 临时調整，比如活動頁短期換位置：用 302，不要長期挂着。
- 頁面確認不再提供：返回 404 或 410，比跳到一個内容無關的首頁更清楚。
把舊連結统一跳首頁是最常见的偷懒做法。對用戶和蜘蛛来说，它都等于在说“這個内容没了”，很难起到迁移的作用。
目标地址只能有一個
確認跳轉终点就是该頁面的規范地址，不要再经過带參數、带斜杠或不带斜杠的版本，也不要再叠加一层 CDN 层面的跳轉。
自查清單
- 導出近几個月的服務器日誌，筛出狀態碼為 3xx 的請求，按 URL 聚合，看哪些地址被反复訪問。
- 随机抽取一批老 URL，用命令行工具或抓取工具查看跳轉鏈條，记錄跳了几次、落到哪里。
- 检查跳轉终点是否返回 200，且頁面的 canonical 指向自身。
- 確認内部連結、導航、面包屑、Sitemap 里已经全部換成新地址，不再依赖跳轉。
- 核對 hreflang、分頁、移動版等特殊场景的跳轉是否指向了正确的對應頁面。
- 检查是否有頁面跳到了 noindex 頁面或被 robots.txt 屏蔽的地址，那等于把入口關上了。
迁移时的操作顺序
- 先确定新舊 URL 的一對一映射表，尽量避免多對一造成的语义丢失。
- 在服務器或 CDN 层配置跳轉規則，優先處理訪問量最大的那批地址。
- 更新站内所有指向舊地址的連結，让蜘蛛走新路而不是老路。
- 提交新的 Sitemap，同时保留一段時間舊地址的跳轉，別急着撤掉。
- 迁移後持續观察日誌和索引狀態，直到 3xx 請求量明顯下降。
几個常见的坑
- 跳轉規則寫成通配後誤伤：把 /old/ 開头的整段都跳走，结果把不该動的栏目也带上了。
- 跳轉目标又被重定向到登入頁或地区選擇頁，蜘蛛拿不到真正的内容。
- 鏈式跳轉跨了多套系統：Nginx 跳 CDN，CDN 再跳應用层，排查时很难一次性看全。
- 只在浏览器里点過一遍就認為没問题，浏览器會自動跟完整條鏈，看不出中間有几跳。
重定向不是“能打開就行”，而是要让蜘蛛用最少的請求走到最该去的頁面。鏈條越短，越不容易在後續维護和調整中被誤改。
建议把重定向当作一份長期维護的清單，而不是一次性的迁移任務。每次栏目調整、每次頁面下线，都顺手记一筆，半年後再看日誌，會發現 3xx 請求始终维持在一個很小的量級上。