蜘蛛池里的入口頁，很多时候並不直接放目标 URL，而是通過一跳或几跳把蜘蛛送到目标頁。跳轉本身没有對错，但跳轉的實現方式和层數會直接影响蜘蛛能不能顺利發現目标 URL，以及這個過程要花掉多少抓取预算。
三種常见跳轉方式的机制差异
- HTML 連結跳轉（a 标簽）：最透明的一種。蜘蛛解析源碼时就能讀到目标 URL，把它放進待抓队列，不需要額外执行脚本，也不需要等第二次响應。
- 服務端 3xx 跳轉：蜘蛛請求入口頁，服務器返回 301 或 302，蜘蛛再請求目标地址。目标 URL 會被记錄下来，入口頁本身則更像一個過渡角色。
- JavaScript 跳轉：源碼里只有脚本，目标 URL 要么藏在變量里，要么在渲染之後才生成。取决于抓取端是否渲染，蜘蛛可能看到，也可能看不到。
- meta refresh：寫了延时或零延时的重定向。能否被跟随，各引擎的處理並不完全一致，而且容易和 canonical 打架。
如果同一批入口頁里混用了這几種方式，日誌會變得很难讀——你看到的抓取量變化，可能只是換了跳轉方式，而不是蜘蛛變懒了。
跳轉层數：每一跳都在消耗预算
一個常见的誤解是“多跳几层没關系，反正最後能到”。實际上每多一跳，蜘蛛就要多發起一次請求，多占一次连接和一次請求配額。
更現實的問题是漏抓概率。假设每跳被成功跟随的概率是九成，三跳之後大概只剩七成左右的目标頁被真正触達；如果是脚本跳轉，成功率還要再打折。层數越多，你越难判断“没被抓”是入口頁的問题、跳轉的問题，還是目标頁的問题。
一個可用的经驗区間
- 一跳（入口頁 → 目标頁）：最常见，鏈路清晰，排查容易。
- 两跳（入口頁 → 中間頁 → 目标頁）：中間頁要有實质内容，否則等于白建一层。
- 三跳及以上：除非中間层有獨立的索引價值，否則建议合並。
容易踩坑的几種组合
- 入口頁用 302 跳到中間頁，中間頁再用脚本跳目标頁。两種不确定性叠加，日誌里往往只剩入口頁的訪問记錄。
- meta refresh 的延时寫得太長，比如 10 秒以上，蜘蛛可能直接放弃等待。
- 跳轉目标和入口頁的 canonical 互相指向，等于给蜘蛛两個矛盾的信号。
- 入口頁返回 200，但正文只有“正在跳轉”，其余動作都靠脚本——這样的頁面對蜘蛛几乎是空的。
- 跳轉鏈上任意一环返回 4xx 或 5xx，整條鏈對蜘蛛就断了，而且短期内不會高频重试。
實操建议
- 優先用服務端 301，把跳轉逻辑放在服務器而不是浏览器端。响應头和 Location 是蜘蛛最容易解析的信号。
- 如果必须用脚本跳轉，同时在 HTML 里保留一個 a 标簽或在 noscript 中留一條連結，给不能执行脚本的抓取留條退路。
- 把层數控制在一到两跳内，中間頁要有内容，不要只是過道。
- 保持跳轉目标唯一，同一個入口頁不要根據 UA 或 Referer 返回不同目标，那會让排查變成猜谜。
- 跳轉目标尽量避免带一次性參數，參數越多，同一個目标 URL 被反复当成新 URL 的概率越高。
- 定期抽查：随机取十几個入口頁，用抓取日誌或第三方工具走一遍，看每一跳的返回碼和最终落点是否與预期一致。
观测與調整
观察时重点看三件事：入口頁的抓取次數、跳轉目标的被抓取比例、以及從入口頁到目标頁之間隔了多久。如果入口頁天天被訪問，目标頁却始终没有记錄，那問题多半出在跳轉實現上，而不是在“蜘蛛不够用”。反過来，如果目标頁被抓了但入口頁几乎没有记錄，說明蜘蛛是绕過入口頁直接来的，入口頁本身的角色需要重新评估。
跳轉鏈是蜘蛛池里最容易被忽略、又最容易出問题的一环。它不复杂，但它决定了蜘蛛走的是直路還是迷宫。把方式统一、层數压缩、落点固定，剩下的波動才好归因。