站内跳轉是运营里最不顯眼、却最容易堆出問题的一环。改版、換域名、調整栏目结构、合並頁面，每一步都可能留下一條 301；模板里再埋几個 JS 跳轉，几年下来一個 URL 要经過四五跳才落到最终頁面。對用戶来说只是慢一点，對蜘蛛来说，這是一條要反复走、而且容易走丢的路径。
跳轉不是不能有，但每一跳都有代價
蜘蛛识別 3xx 狀態是常規能力，正常的 301、302 一般不會直接導致頁面抓不到。問题出在鏈路長度和稳定性上：每一步跳轉都是一次額外請求，會占用服務器响應時間，也消耗蜘蛛在這條路径上的耐心。当鏈路超過两三跳，或者中間某一跳返回 404、超时、需要 JS 执行，蜘蛛很可能中途停下，终点 URL 也就没有被發現和抓取。
更麻烦的是，跳轉鏈上的中間 URL 往往相互指向同一個终点。蜘蛛會分別去請求它們，等于用同一份抓取配額做了几遍無用功。
几種常见的跳轉鏈，問题点各不相同
1. 层叠 301：A→B→C→D
多见于多次改版。第一次改版 A 跳到 B，第二次 B 跳到 C，第三次 C 跳到 D，舊規則全留着，鏈路就越拉越長。更稳妥的做法是把規則收敛成 A→D、B→D、C→D，每一跳都直達终点。
2. JS 跳轉與 meta refresh
這類跳轉依赖脚本执行或浏览器行為，處理優先級和确定性都低于服務端 301。能換成服務端跳轉的尽量換；必须在 JS 里做的，至少保證跳轉目标是一個静態可訪問的 URL。
3. 跳轉到首頁或列表頁
有些站点把下线頁面统一跳到首頁，看似省事，實际效果是蜘蛛每次追到一個失效地址都會被送到首頁，既浪費路径，也模糊了 URL 之間的關系。下线内容更适合返回 410 或 404，而不是统一兜住。
4. 跳轉时丢參數或加參數
跳轉規則如果顺手拼上跟踪參數、會话 ID，很容易生成一批新的重复 URL，把本来一條路径的抓取拆成好几條。
跳轉鏈對 URL 發現的影响，大致在這几层
- 發現成本：每一跳都是一次請求，配額有限时，鏈條越長越不划算。
- 發現可靠性：中間出現错誤狀態、超时、需要渲染，發現過程就断了。
- 信号传递：信号沿跳轉传递會有损耗，鏈越長损耗越明顯。
- 重复 URL：中間地址可能被当成獨立 URL 處理，簇變大，收敛變难。
自查與收敛的常規做法
- 抓一份服務端訪問日誌，筛出返回 3xx 的請求，按来源 URL 與目标 URL 統計出現频次。
- 把跳轉規則画成图，找出長度超過两跳的鏈路，以及绕回自身的循环。
- 精简規則：能直達的直達，能删的舊規則删掉，別让歷史規則無限叠加。
- 確認终点 URL 可正常訪問、狀態碼為 200，内容與跳轉前的语义基本一致。
- 把终点地址更新到站内連結、Sitemap 和 canonical 上，减少蜘蛛再走舊路径的机會。
- 改完之後隔一段時間复查日誌，看舊跳轉的請求量有没有逐步下降。
一個简單的判断标准：如果一條跳轉鏈你自己在浏览器里要走三跳以上，蜘蛛那邊大概率也不會舒服。
几個容易被忽略的细节
- HTTPS 與 HTTP、www 與非 www 的跳轉尽量一次性到位，不要先跳协议再跳域名。
- 移動端模板里的跳轉規則容易和 PC 端叠加，产生額外鏈路，改版时两邊都要看。
- CDN 层的跳轉規則和源站的跳轉規則可能同时生效，排查时要一起確認。
- 短鏈、活動連結、QR Code专用連結尽量不長期留在站内，它們會持續制造中間 URL。
跳轉本身不是問题，問题是鏈路没人清理、没人收敛。把跳轉鏈当作站内结构的一部分定期维護，URL 發現這件事會省下不少不必要的消耗。