做蜘蛛池或需要批量發現 URL 时，常见一種做法：入口頁連結一個短鏈或中轉地址，再由這個地址 301 或 302 跳到真正的目标 URL。這时問题就来了——搜尋蜘蛛會不會跟着跳轉走到最终頁面？中間跳几层它會放弃？跳轉後的地址還算不算被發現？這一篇把 HTTP 跳轉和 URL 發現之間的關系拆開说。
搜尋蜘蛛通常會跟進 HTTP 跳轉
搜尋蜘蛛請求一個 URL 後，如果服務端返回 301 或 302，並带上 Location 响應头，它一般會按 Location 再發一次請求，直到拿到 200 的頁面，或遇到终止條件（超时、错誤、循环、被規則拦下）。也就是说，入口頁里連結的中轉地址本身會被抓，跳轉後的目标通常也會被繼續請求，两者都可能進入抓取队列。
但要清楚一点：跟不跟、跟到第几层，不由你指定，而是搜尋引擎自己的抓取規則和当时的抓取预算决定的。跳轉不是加速開關，它只是把一次請求變成两次。
301 和 302 传递的信号並不一样
301 表示永久跳轉，通常被理解為這個地址以後再也不用，内容已搬到新地址。搜尋引擎倾向于把两個 URL 当作同一份内容的两個位置處理，相關信号可能归到最终地址上。302 是临时跳轉，處理上更保守，原地址仍可能保留在索引中，最终地址是否被單獨当作可收錄 URL，反而不确定。
如果你的目的只是让目标 URL 被搜尋蜘蛛發現，那么中轉地址返回什么狀態碼，會影响它被對待的方式：
- 希望稳定指向新地址、不让中轉地址長期占位，用 301；
- 只是临时分流、統計或做 A/B，用 302，但別把它当長期方案；
- 跳轉到一個與入口頁主题完全無關的頁面，容易被判為異常。
跳轉鏈太長會發生什么
一跳到底通常没問题，但如果 A 跳到 B、B 跳到 C、C 再到 D，風險會累积：
- 每一跳都是一次請求，持續消耗抓取配額，尤其是入口頁和最终站同属一個抓取预算时。
- 鏈路中任何一环出現超时、5xx 或循环跳轉，蜘蛛就會停下，最终地址根本没被請求。
- 层級過深时，部分抓取策略會主動截断，只记錄前几跳。
實践中把跳轉控制在 1 跳、最多 2 跳，能明顯减少不确定性。
別把發現和抓取混為一谈
要区分两件事：發現和抓取。入口頁里出現的中轉地址被解析到，只是發現了它；搜尋蜘蛛是否真的請求它、再沿 Location 請求最终地址，取决于抓取優先級和配額。一個低優先級的中轉地址，可能躺在队列里很久也没被請求。
另外還有一层差別：如果入口頁連結的是最终地址，最终 URL 就是被直接發現的；如果連結的是中轉地址，最终地址是经由跳轉間接發現的，鏈路上多了一個可能失敗的环节。中轉地址一旦失效、被删、被拦，後面的目标 URL 也跟着断了。
几個容易踩的坑
- 用 JavaScript 或 meta refresh 做跳轉：跟進依赖渲染，比 HTTP 狀態碼跳轉更不确定。
- 跳轉目标被 robots.txt 屏蔽：蜘蛛跟過去也會被拦下，不产生實际抓取。
- 跳轉鏈带随机參數：每一跳都可能生成新 URL，容易被当成大量新地址反复抓取。
- 中轉地址返回 200 的中間頁而不是真跳轉：蜘蛛只會停在中間頁，不會繼續到目标。
- HTTP 與 HTTPS 混跳、带與不带 www 混跳：能跳，但會给連結判断和抓取增加額外环节。
用跳轉做 URL 分發不是错，但它把發現鏈路拉長了。确定要長期被發現的地址，尽量直接放在入口頁的可点击連結里，跳轉留给确實需要統計或临时分流的场景。
可以落地的检查清單
- 用命令行工具或抓取工具看中轉地址返回的狀態碼和 Location，確認是 301/302，而不是 200 的中間頁。
- 確認跳轉鏈只有 1 到 2 跳，且每一跳都能正常返回。
- 確認最终地址返回 200，且没有被 robots.txt 或 noindex 层面的規則挡住（前提是你确實希望它被抓取）。
- 在入口頁同时保留最终地址的直接連結，减少對跳轉鏈的依赖。
- 看服務器日誌，確認最终地址是否真的被請求過，而不是只請求了中轉地址。
總的来说：搜尋蜘蛛一般會跟進 HTTP 跳轉，但跟進過程不受你控制，跳轉越多、越绕，最终地址被抓到的机會越不确定。把跳轉当成分發手段之一，而不是唯一的發現路径，會更稳妥。