重定向本身没問题，鏈式跳轉才費劲
把一個頁面 301 到新地址，是正常的站点维護動作。蜘蛛對單次重定向的處理很熟练：拿到 301，记下 Location 里的新地址，再請求一次。問题出現在跳轉不止一次的时候。每多一跳，就多一次請求、多一段等待、多一條日誌记錄，而最终拿到的還是同一份内容。
短鏈和長鏈的差別，在少量頁面上几乎看不出来；一旦站点里有几千個舊 URL 都挂着两三层跳轉，這些額外請求就實實在在占掉了抓取時間。
蜘蛛處理重定向的常規流程
- 請求原地址，收到 3xx 狀態碼，讀取响應头里的目标地址。
- 對目标地址發起一次全新請求，原来的连接和响應内容作废。
- 如果目标地址還是 3xx，重复上一步，直到拿到 200 或错誤碼。
- 最终把收錄與權重信号记在终点 URL 上，起点 URL 逐渐從索引中退场。
中間每一跳都是真實請求，並不是“顺手带過去”。所以鏈路越長，單個頁面的抓取成本越高。
哪些常见操作會把鏈拉長
- 协议與域名切換：http 跳 https，再跳带 www 的版本，两個動作串起来就是两跳。
- 尾斜杠處理：目錄地址先跳到带斜杠版本，再跳到具体文件。
- 栏目迁移叠加：老栏目跳到過渡栏目，過渡栏目再跳到新栏目，最後才到詳情頁。
- CDN 或负载均衡层配置：邊缘节点做一次地址規整，源站再做一次，鏈路上多了一环，而日誌里未必看得全。
- 短鏈服務：站外短鏈先跳回站内，再跳一次到落地頁。
這些做法單獨看都合理，叠加起来就偏長了。
容易被忽略的两類跳轉
meta refresh 與 JS 跳轉
用 meta refresh 或脚本做的跳轉，返回的是 200 狀態碼，蜘蛛需要先解析頁面才能發現目标地址。相比 301，它多了一步解析，信号传递也没那么直接。能用服務端 301 解决的地方，尽量不要放到 HTML 层。
循环與半循环
A 跳 B、B 又跳回 A，會直接掐断這條抓取路径。還有一種更隐蔽的情况：不同版本的地址互相跳，例如带參數的地址跳到不带參數的地址，而不带參數的地址又因為重寫規則被送回带參數的版本。抓取工具跑一遍就能看出来，人工翻連結却常常漏掉。
把鏈路压到一跳以内
- 先盘点所有返回 3xx 的 URL，在服務器日誌或抓取工具的响應碼分布里筛一遍。
- 把多头跳轉改成“起点直连终点”，中間层不再參與轉發。
- 统一协议和域名寫法，内鏈、Sitemap、外鏈里發出的地址本身就用最终形態，减少無效跳轉。
- 迁移結束後把過渡层地址一並更新，別让它長期挂着。
- 改完再跑一次抓取，確認响應碼以 200 和少量 3xx 為主，没有成片的鏈路。
怎么核對效果
最省事的办法是看日誌里同一路径的請求次數：如果每個舊地址進来後都跟着两三次连鎖請求，說明鏈路還在。另一個角度是統計终点頁面的整体耗时，跳轉多的地址，蜘蛛從發出請求到拿到内容的總時間明顯更長。
重定向是纠错工具，不是常態化的路由方案。能一次到位，就不要分两步走。
把跳轉控制在必要范围内，抓取時間才會花在真正需要更新的頁面上。