站内出現跳轉很常见，https 改造、域名切換、目錄重构都离不開 3xx。但跳轉不是零成本的：蜘蛛每跟一次跳轉，都要重新發起請求、重新讀响應头，必要时還會重做 DNS 與 TLS。鏈路一長，抓取效率就悄悄往下掉。
蜘蛛遇到 3xx 时到底做了什么
蜘蛛請求一個 URL 後，如果收到 301 或 302，它會讀取 Location 头，把目标地址放進自己的抓取队列，然後按节奏再去請求一次。這個過程不是“瞬間跳過去”，而是一次新的抓取任務。對單條 URL 来说，多一跳就是多一次請求；對整站来说，成千上萬個連結都多一跳，消耗就叠加起来了。
一跳的代價，比想象中多
- 多一次 HTTP 請求，抓取预算按請求計算，不是按最终頁面計算
- 目标主机不同时，要重新做 DNS 解析；HTTPS 還要重新握手
- 服務器日誌里多出一條 3xx 记錄，統計时容易被誤算成“已抓取”
- 鏈路中某一跳超时或返回 5xx，蜘蛛可能直接放弃，终点頁始终拿不到
常见的几種“越跳越長”
协议與主机名连环跳
http://example.com 跳到 https://example.com，再跳到 https://www.example.com，這是三跳，只有最後一跳才算有效抓取。站点若能一次 301 直接指向最终地址，就省掉中間一段。
尾斜杠與大小寫反复跳
/list 與 /List、/list/ 之間互相跳，往往来自服務器配置和代碼拼接規則不统一。内鏈里混着几種寫法，蜘蛛就會把這些變体都走一遍。
參數回跳到干净地址
带跟踪參數的地址先跳回不带參數的地址，表面上是统一了 URL，實际是让蜘蛛多抓一次。内鏈直接寫干净地址會更省事。
JS 跳轉與 meta refresh
這類跳轉蜘蛛不一定跟，或者跟得比 3xx 慢得多。能用服務端 301 讲清楚的事情，尽量不要留给前端脚本。
怎么查自己站上的跳轉鏈
- 在服務器日誌里筛 3xx 狀態碼，看哪些路径出現频率高、Location 指向哪里
- 抽几個核心 URL 手動跟一遍，數一數经過几跳才返回 200
- 检查内鏈與導航，確認它們指向的是终点 URL，而不是跳轉入口
- Sitemap 里寫的應该是终点地址，不是需要跳轉的舊地址
- 確認鏈路里没有环，A 跳 B、B 又跳回 A 是最糟的情况
跳轉什么时候必须保留
舊地址已经對外發布過、有外鏈指向，這種跳轉要留着，而且尽量用 301 做永久指向，不要中途改来改去。真正该收敛的是“新連結也在走跳轉”這種情况——新生成的 URL 本身就應该是一個能直接返回 200 的终点，不需要经過任何中轉。
跳轉是给舊地址收尾用的，不是给新地址開头用的。
顺手检查的几個细节
把跳轉鏈压短，其實是在替蜘蛛省掉一部分無效往返。除了跳轉本身，也可以顺便看一眼服務器：跳轉响應如果经常慢于正常頁面，或者高峰期有超时，蜘蛛跟到一半登出的概率會變高。抓取路径上的問题往往不是單点，跳轉、响應時間、内鏈寫法经常一起出現，一起處理效率更高。
小结
把跳轉鏈控制在一跳以内，是抓取路径上比較容易做、收益也比較稳的調整。它不需要改模板、不需要動内容，只要让内鏈和 Sitemap 直接指向终点，就能把蜘蛛花在中轉上的那部分時間省回来。