頁面從 A 跳到 B 再跳到 C，用戶端可能只感觉“慢了一点”，但對搜尋引擎来说，這等于一次抓取被拆成了三次請求。跳轉鏈本身不违規，也不直接等于不收錄，可当站点里大量 URL 都存在两跳以上时，抓取资源就會被消耗在中間环节，新頁面被發現、被處理的节奏自然會被拖慢。
每次跳轉都是一次獨立請求
爬虫遇到 301 或 302 时，需要重新請求 Location 指向的地址，直到拿到最终返回 200 的頁面。两跳就是三次請求。中間地址如果還带參數、大小寫或尾斜杠變化，處理结果可能被延後甚至丢弃。更麻烦的是，鏈路中間那些地址本身也可能被抓取、被索引，最後形成一堆指向同一内容的不同 URL。
先量清楚跳轉鏈到底有几跳
不要凭印象判断，建议按下面几步抽样統計：
- 抽真實入口 URL，包括首頁導航、Sitemap 里的地址、外鏈落地頁、日誌中出現频次最高的地址，而不是只测首頁。
- 用支持跟随跳轉的抓取工具或命令行查看完整鏈路，逐跳记錄狀態碼和 Location。
- 按鏈長分组，統計一跳、两跳、三跳及以上的 URL 各有多少。
- 把鏈路最長、同时被抓取最频繁的那批 URL 排到處理队列最前面。
多跳通常是從哪来的
- HTTP 跳 HTTPS、裸域跳 www 各寫了一條規則，叠加起来就變成两跳。
- 舊栏目 301 到新栏目，新栏目又 301 到最终目錄，歷史規則一直没有清理。
- CDN、负载均衡或反向代理层又額外設定了一次跳轉。
- 尾斜杠、大小寫、參數清理由不同层分別處理，一次請求被多次改寫。
- 頁面内 JS 跳轉和服務器端跳轉混用，鏈路上很难判断终点在哪。
- 移動端與 PC 端互相跳轉，没有一方作為固定终点。
收敛顺序：從流量大的入口開始压
建议按這個顺序動手，避免一邊改一邊制造新的跳轉：
- 先合並同源跳轉，把 HTTP 到 HTTPS、裸域到 www 合成一條直接指向最终地址的規則。
- 把歷史栏目跳轉的目标改成最终地址，而不是指向另一個會跳轉的地址。
- 检查代理和 CDN 层是否重复配置了跳轉，同一次請求只保留一层處理。
- 尾斜杠與大小寫策略在規則层一次性定下来，不要靠跳轉去纠正。
- 站内連結、Sitemap、canonical 全部改成最终地址，停止自己制造跳轉。
- 舊規則保留一段時間，等日誌里確認中間地址已不再被抓取，再考虑下线。
收敛之後该看什么
重点看三個變化：最终地址的抓取频次有没有上升、中間 URL 的抓取量有没有下降、新頁面從被發現到被抓取的間隔有没有缩短。索引量本身每天都會波動，不要拿一两天的高低下结论。
跳轉鏈是抓取效率問题，不是收錄開關。把鏈路压短是减少损耗，並不能保證某個頁面一定進索引。
几個容易忽略的邊界
- 临时性跳轉不要長期挂 302，狀態碼要和實际意图一致。
- 鏈上任意一跳出現 404 或 5xx，整條鏈就断了，最终頁面等于没被訪問到。
- 跳轉目标如果被 robots.txt 屏蔽，抓取跑過去也拿不到内容。
- 跳轉目标带 noindex，抓取到了也不會留在索引里，等于白跑一趟。
- 跨域跳轉的信号传递比同站跳轉更难判断，能避免就避免。
總结起来就是三步：先量清楚每條入口的跳轉鏈長度，再按入口價值從高到低合並規則，最後用日誌驗證中間地址是否真的退场。鏈路越短，抓取和發現的损耗就越少。