站点搬過一次家、換過一次域名、改過一次栏目名，很容易攒下一條跳轉鏈：老地址跳新地址，新地址跳带 www 的版本，带 www 的版本再跳 https。用戶在浏览器里几乎察觉不到，但蜘蛛每跟一跳，都要重新發起一次請求、重新解析一次响應头，才能繼續往下走。抓取路径的長度，就是這么一点点被拉長的。
一跳和三跳，對蜘蛛不是同一件事
跳轉本身不是错誤，蜘蛛處理 301 很熟练。問题出在鏈的長度上：每多一跳，就多一次請求—响應的往返，多占一份抓取资源；同时，鏈尾那個真正有内容的地址，被發現的时机會往後拖。如果這條鏈還同时出現在内鏈和 Sitemap 里，蜘蛛可能反复沿着不同入口走到中間某一跳，重复付這筆成本。
先分清几種跳轉
- 301 與 308：表示永久迁移，蜘蛛會把抓取和連結信号往目标地址上归拢。
- 302 與 307：表示临时，蜘蛛通常會保留原地址的抓取，不會急着替換。把永久迁移寫成 302，是常见的誤配。
- meta refresh 和 JS 跳轉：這類跳轉藏在頁面内容里，蜘蛛要進入渲染环节才會發現，成本比响應头里的跳轉高得多，能不依赖就不依赖。
判断标准很简單：如果這個地址以後不會再變回来，就應该用永久跳轉，並且尽量让它一步到最终地址。
跳轉鏈是怎么堆出来的
- 协议與主机名調整：http 到 https、非 www 到 www，各自加了一條規則，叠加成两跳。
- 目錄结构改名：舊栏目先跳到新栏目，新栏目後来又统一挪到下二級，鏈就變長了。
- 结尾斜杠不统一：带斜杠和不带斜杠之間互相跳，配合上面的規則又多一跳。
- 應用层跳轉：服務器規則跳一次，程序里再判断一次，同一次訪問被拆成两段。
自查：把鏈完整拉出来看
- 用 curl -I 最终地址 看單個地址返回的狀態碼和 Location 指向。
- 用 curl -I -L 跟随跳轉，观察從起点到终点一共经過几次 3xx，终点是不是 200。
- 從服務器日誌里筛出所有 3xx 的訪問，按出現频次排序，高频的跳轉優先處理。
- 重点检查两種情况：鏈尾不是 200（落到 404 或 noindex 頁），以及存在 A 跳 B、B 又跳回 A 的循环。
抽样时不用覆盖全站，把首頁、主力栏目頁、几個典型詳情頁和舊地址各测一條，基本就能看出規則有没有叠加。
把多跳收敛成一跳
- 把跳轉規則放在服務器或 CDN 這一层统一處理，直接映射到最终地址，避免應用层再跳一次。
- 跳轉目标寫成最终形態：协议、主机名、路径、结尾斜杠一次到位，別让下一跳再修一遍。
- 内鏈和 Sitemap 里直接使用最终地址，不要保留舊地址作為入口，否則等于持續提醒蜘蛛去走這條鏈。
- 改版或迁移前先列出映射表，確認没有一條鏈需要经過两次以上跳轉。
跳轉和抓取节奏的關系
一條稳定的一跳，對抓取节奏的影响很小。真正拖後腿的是長鏈：蜘蛛走到中途就消耗掉一次抓取机會，鏈尾頁面的回訪間隔随之變得不稳定，新内容的發現也會變慢。把跳轉当成一次實實在在的請求成本来看待，很多規則冲突在部署前就能發現。
日常做法可以很朴素：改完跳轉規則後跑一遍抽样自查，確認從舊地址到新地址只经過一次 3xx，终点是 200；換域名、上 https、調整目錄這類操作，尽量在做之前就規划好最终地址，减少事後追加規則的机會。