站点做過改版、換過域名、切過 HTTPS，或者調整過栏目结构之後，同一個頁面往往要经過好几跳才能到達终点。跳轉本身不是問题，問题在于跳轉鏈越接越長、指向越来越乱时，搜尋引擎和用戶看到的“最终版本”可能和运营以為的不一样。收錄核對里，這類問题经常表現為：搜到的 URL 是中間某一跳，点進去又跳一次；或者老 URL 和新 URL 都被收錄，内容却是同一份。
跳轉鏈為什么會干扰收錄
抓取一個 URL 时，遇到 301 或 302 會顺着 Location 繼續請求，直到拿到 200 的頁面。鏈條越長，中間任何一环出問题——超时、狀態碼異常、目标頁被 robots 屏蔽——都可能让這次抓取停在半路。抓取没走完，後續的收錄环节自然無從谈起；即使走完了，最终记錄在索引里的也可能是鏈條中段的某個 URL。
另一個容易忽略的点是：多跳跳轉會让每次抓取多花几次請求。對抓取预算有限的站点来说，這属于無谓的消耗。
第一步：把完整跳轉鏈拉出来
不要只看第一跳。用 curl 的 -L 參數、浏览器開發者工具的 Network 面板，或者任意一個跳轉鏈检查工具，把從入口 URL 到最终的每一步都列出来。重点看三件事：
- 一共几跳。两三跳以内通常可以接受，五跳以上就该考虑收敛了。
- 每一跳的狀態碼。301、302、307、308 语义不同，混用时要確認是否符合预期。
- 是否出現循环。A 跳 B、B 又跳回 A，抓取會直接失敗。
建议把结果记成一行文本：入口 → 中間 → 中間 → 终点，旁邊标注狀態碼。後續核對都基于這一行展開。
第二步：核對最终落地頁是不是你以為的那個
很多跳轉問题的根源不在鏈條長度，而在终点错了。常见的情况包括：老栏目整体 301 到了首頁，用戶和爬虫点進去發現内容對不上；产品下线後跳到某個不相關的分類頁；HTTP 版本跳 HTTPS，但 HTTPS 那一侧又配了別的跳轉規則，最後落到带 www 或不带 www 的另一個版本。
核對时把落地頁和原始 URL 的主题對一遍。如果两者主题差距很大，這個跳轉在收錄层面大概率會被当作一次無關迁移，原来頁面积累的信号很难顺利传递過去。
第三步：区分必要跳轉和歷史遗留跳轉
不是所有跳轉都要清掉。有些是目前架构必需的，比如 HTTP 到 HTTPS、非 www 到 www、大小寫規范化。這些跳轉應当保留，而且最好只有一跳。
真正要處理的是歷史遗留：早年的域名跳轉、已经废弃的舊栏目、被合並的重复頁面，一层层叠加後，入口到终点可能要绕四五跳。判断方法很简單——問一句“如果去掉這跳，會不會影响現在的正常訪問”。不會，就属于可以收敛的對象。
几種容易出問题的跳轉形態
- 鏈式跳轉：舊域名 → 老域名 → 目前域名，中間每一层都没清理。
- 跳轉终点也是跳轉：目标是某個已下线頁面，它自己又 301 去別處。
- 跳轉參數丢失：带參數的舊 URL 跳轉时參數被截断，導致部分落地頁收到错誤參數。
- 跳轉目标不可抓取：终点頁被 robots.txt 屏蔽或返回 404，鏈條走到這里就断了。
- 混合协议與主机名：https 與非 https、带 www 與不带 www 之間来回跳。
收敛顺序：從末端往源头改
- 先确定每個頁面的唯一權威 URL，作為所有跳轉的终点。
- 把多跳鏈改成直接一跳到位，跳轉規則寫在离入口最近的位置。
- 检查终点頁本身是否能正常返回 200、是否可抓取、是否和内容一致。
- 改完後重新拉一次跳轉鏈，確認從入口到终点只剩必要的那一跳。
- 观察一段時間，看索引里是否還残留中間 URL 的版本，再决定是否需要單獨處理。
改跳轉規則属于對线上生效的改動，建议先在少量 URL 上驗證，確認没有誤伤正常訪問後再批量铺開。測試域名、预览环境上的跳轉配置不要和线上混在一起，否則排查时容易看错對象。
跳轉鏈的問题往往不是“跳了”，而是“跳得太多次、最後一跳還跳错了”。核對收錄时，先花十分钟把鏈拉直，比反复刷新索引狀態更有效。