结论先放在前面
如果入口頁上的連結不是直接指向目标 URL，而是先经過一個中轉地址，比如 /go?url=xxx、/jump/123，或者一個专门做跳轉的域名，搜尋蜘蛛通常還是會跟過去，但中間多出来的每一步都是一次可能失敗的机會。跳轉鏈上只要有一环被 robots.txt 挡住、返回 4xx 或 5xx、或者响應太慢，後面的目标 URL 就發現不了。所以中轉不是不能用，而是要把不可控的环节压到最少。
常见的三種中轉形態
- 服務端跳轉：入口頁的連結直接指向一個會返回 301 或 302 的地址，浏览器地址栏會變化。這是最容易被搜尋蜘蛛正确跟随的一種，因為狀態碼和 Location 头都是明确信号。
- 參數式中轉頁：連結形如 /go?target=xxx，中轉頁先返回 200，再用服務端跳轉或 meta refresh 跳到目标。搜尋蜘蛛必须先抓中轉頁，再决定跟不跟。
- 前端跳轉：用 JavaScript 的 location.href 或 meta refresh 完成跳轉。這類做法的跟随确定性最低，尤其是需要等异步脚本执行完再跳的寫法。
搜尋蜘蛛跟不跟，主要看三個條件
1. 中轉頁本身能不能被抓
這是最容易被忽略的一條。中轉頁如果被 robots.txt 屏蔽、需要登入、或者直接返回 403，搜尋蜘蛛根本讀不到 Location 头，後面的目标 URL 就断了。不少站点為了让中轉路径不出現在搜尋结果里，顺手在 robots 里加了一條 Disallow，结果把整條發現鏈路掐掉了。
2. 狀態碼用得對不對
永久性迁移用 301，临时性跳轉用 302，两者搜尋蜘蛛都會跟，只是後續處理逻辑不同。至于返回 200 再靠 meta refresh 或者正文里寫一句請点击這里，跟随的确定性會明顯下降。
3. 跳轉层數
一层可以接受，两层要谨慎，三层以上基本是在消耗抓取预算。每多一层，就多一次排队和超时的風險，而搜尋蜘蛛的抓取額度是有限的，中轉頁占掉的名額，就是目标 URL 少掉的名額。
用日誌確認跳轉有没有被跟到
不要凭感觉判断，去看服務端日誌里的請求顺序。一條正常的鏈路，日誌中應该能看到连續的记錄：入口頁、中轉頁、目标 URL。如果只看到前两條，說明問题出在中轉頁到目标頁這一段，重点查中轉頁的狀態碼、Location 头的寫法，以及目标 URL 是否被拦截。如果连中轉頁的請求都没有，那問题在前面，要回到入口頁本身找原因。
排查顺序建议從後往前推：先確認目标 URL 可訪問，再確認中轉頁可訪問且未被屏蔽，最後才看入口頁有没有把連結正确輸出。
几個容易踩的细节
- Location 头尽量寫完整的绝對地址，相對地址虽然也能解析，但在多层跳轉时容易拼错。
- 跳轉鏈不要形成环，A 跳 B、B 又跳回 A，搜尋蜘蛛會直接放弃。
- 中轉參數里不要叠加跟踪參數，否則同一個目标可能被当成多個地址反复抓取。
- 跨域跳轉本身没問题，但要確認目标域名没有被防火墙按 UA 拦截。
實操建议
- 能用直接連結就用直接連結，中轉只放在确實需要統計或做保護的地方。
- 中轉頁统一返回 301 或 302，避免用前端跳轉代替服務端跳轉。
- 检查 robots.txt，確認中轉路径和目标路径都在允许范围内。
- 把跳轉层數控制在两层以内，並定期用日誌核對鏈路是否畅通。
- 發現目标 URL 迟迟没動静时，先手動請求一遍整條鏈路，看每一步返回的狀態碼。
跳轉本身並不會让 URL 被收錄，它只是把發現這一步做得更顺或者更曲折。相比纠结用哪種跳轉方式，先把鏈路里每個环节都保持在可抓取、可訪問、响應正常的狀態，收益更直接。