為什么重定向鏈值得單獨检查
一條 301 跳轉本身没有错，它本来就是迁移时的正常工具。問题出在“叠加”：舊地址跳到新地址，新地址又触發了 www 規范化，接着再补一次 HTTPS 跳轉，用戶和蜘蛛就要走三步才拿到内容。每一次跳轉都意味着一次完整的請求响應往返，服務器要處理、浏览器要等待、抓取程序要重新判断目标。抓取资源有限时，這些多出来的步骤並不會換来額外内容，只是把同一次訪問拆成了好几筆。
對用戶来说，多跳意味着更長的首屏等待，移動網絡下尤其明顯；對站点来说，跳轉規則越堆越多，排查問题的成本也在上升。
鏈條通常是怎么長出来的
- 域名迁移叠規范化：舊域名先跳到新域名，新域名再跳到带 www 或 HTTPS 的版本，两段規則各管一段，合起来就是一條長鏈。
- 栏目改版多次調整：目錄名改過一次，slug 規則又改過一次，中間没有合並規則，舊地址就一路跳到底。
- 协议升級不彻底：http 跳到 http-www，再跳到 https，而不是直接跳到最终地址。
- 细节規則分散：末尾斜杠、大小寫、預設文件名各自寫了一條跳轉，互相衔接。
- 分层配置重复：CDN 或反向代理层加了一條，源站配置里又加了一條。
- 临时跳轉忘记清理：活動頁、短鏈、A/B 測試用的跳轉上线後一直挂着。
自查方法
最直接的方式是看真實响應。先不带跟随參數看單跳，再带跟随參數看全程：
curl -sI http://example.com/old-path | grep -iE 'HTTP|location'
curl -sIL http://example.com/old-path | grep -iE 'HTTP|location'
前者能看到第一步的狀態碼和 Location，後者能看到整條鏈上的狀態碼序列。重点看三件事：跳了几次、每一跳指向哪里、最後一跳是不是 200。
單個 URL 看明白之後，可以扩大到全站：用站内爬虫導出所有 3xx 响應，按“来源地址”和“目标地址”聚合成表；在服務器訪問日誌里過滤 301、302 狀態碼，統計出現次數最多的跳轉路径；再對照站点的入口連結，確認導航和地图里没有指向前置跳轉的舊地址。把這三份資料放在一起，多余的环节通常一眼就能看出来。
修复时的几條原則
- 目标直達：把中間环节合並，让舊地址一次跳到最终地址，而不是跳给另一個會再跳的地址。
- 一類規則一處處理：协议、主机名、斜杠、大小寫统一放在入口层判断，不要散落在各栏目配置里。
- 控制深度：尽量保持一跳，個別歷史原因复杂的场景也不要超過两跳。
- 規則要能删：下线的栏目、废弃的活動頁，對應的跳轉该清理就清理，規則表只增不减迟早會乱。
- 目标必须是 200：跳轉到另一個 3xx、或者跳到 404 頁面，等于把問题從一段搬到另一段。
不同狀態碼怎么選
301 永久重定向适合内容永久搬家、目錄结构調整，搜尋引擎會逐步把索引里的地址替換成新地址。需要注意的是這属于信号传递，並不等于立刻完成更新。
302、307 临时重定向适合活動頁、维護期、临时分流。長期挂着临时跳轉，會让人和抓取程序都难以判断哪個才是正式地址，舊地址可能被反复訪問。
還有一点常被忽略：不要為了“看起来更安全”在 301 和 302 之間来回切換，也不要用多個跳轉去模拟一次迁移。規則稳定、指向明确，比跳轉類型本身更重要。
改完之後怎么驗證
- 抽查十個左右的高频入口 URL，確認是一跳到位且落点返回 200。
- 過几天再看訪問日誌，观察 3xx 請求占比是否下降。
- 確認落地頁自身没有再次触發跳轉，比如又被 www 規則或語言規則接管。
- 把跳轉規則和變更日期记錄下来，下次改版之前先翻一遍，避免重复叠加。
小结
重定向是迁移和調整留下的副产品，没人主動维護就會一层层堆积。定期花十几分钟抽查一批入口 URL，看看狀態碼序列和落点，往往比出問题之後再從头排查省事得多。