為什么重定向鏈值得單獨拿出来说
蜘蛛池的入口頁往往经過多次迁移：域名換過、协议從 HTTP 升級到 HTTPS、主域從裸域改成 www、路径做過調整。每一次調整都會留下一條 301。單看一條没問题，串起来就成了一條鏈。搜尋引擎蜘蛛顺着鏈走，需要額外發起請求、解析响應头，每一步都在消耗抓取预算，而预算是有限的。
蜘蛛對跳轉的處理逻辑
主流搜尋引擎在公開文档里都提到過跳轉次數的上限。以 Google 為例，官方說明是單條抓取路径上最多跟随若干跳（常见表述為 5 跳），超過之後可能停止跟随，把目标地址当作無法抓取處理。Bing 的公開說明更保守一些。這個數字不是硬性标准，會随實現調整，但方向是一致的：鏈路越長，越容易被放弃。
另外几類跳轉基本不被当作等價重定向跟随：
- meta refresh 與 JS 定时跳轉：多數情况下蜘蛛不會按 301 的语义處理，權重传递方式也不一样。
- 跳轉到 robots.txt 禁止的路径：跟随到一半直接被拦下。
- 跳轉到返回 4xx 或 5xx 的地址：鏈路断掉，鏈路本身也不再被認為有效。
常见的隐形長鏈
鏈路變長往往不是一次配置造成的，而是几次小改動叠加：
- HTTP 跳 HTTPS（第 1 跳）
- 裸域跳 www（第 2 跳）
- 舊栏目路径跳新栏目路径（第 3 跳）
- 大小寫或尾部斜杠归一（第 4 跳）
- 最後落到實际頁面
入口頁數量一多，這類鏈路會大面积複製。更麻烦的是循环：A 跳 B、B 跳 A，或者跳轉目标又跳回原地址，蜘蛛几次請求後就會判定為循环，並降低對该目錄的抓取活跃度。
几跳算安全
實际运维里的经驗值：一跳到位。如果受歷史原因限制無法一步完成，先把鏈路压到两跳以内，再在後續维護中逐步合並。判断方法很简單，用命令行看响應鏈：
curl -ILs -o /dev/null -w '%{num_redirects} %{url_effective}' https://example.com/old-path
或者直接看訪問日誌里的 301、302 记錄，按来源路径聚合。如果同一蜘蛛 UA 在不同路径上连續留下多條 301，基本就是鏈路問题。
302 與 301 的取舍
301 會被長期缓存，改回原地址後蜘蛛可能仍按缓存走，所以临时調整不建议用 301。302 不缓存，适合短期活動或灰度切換，但每次抓取都要多一次請求；307、308 保留請求方法，语义更嚴格，對普通頁面抓取来说與 301、302 差別不大。真正的取舍点是：這個目标地址會長期存在吗。會，就用 301；不會，就用 302，別让它沉淀成鏈路的一部分。
减少鏈路的具体做法
- 在服務器层把协议、主域、尾部斜杠、大小寫归一放在同一次响應里完成，只發一次 301。
- 站内連結、sitemap、canonical 一律指向最终地址，不要再指向中間地址。
- 頁面跳轉统一用服務端 301，不用 meta refresh 和 JS 跳轉。
- 換路径前先確認新地址能正常返回 200，再配置跳轉，避免跳向 4xx。
- 定期清理長期未使用的跳轉規則，尤其是排期活動留下的临时規則。
入口頁层面的检查节奏
蜘蛛池入口頁數量通常不小，不需要每天全量检查。可以按批次轮換：每次抽一部分入口，检查跳轉层數、终址狀態碼、终址是否與预期一致。發現鏈路變長的先记錄下来，再统一修改，避免零散改動引入新的循环。
最後提醒一点：跳轉修好之後，蜘蛛重新抓取並更新索引需要時間，不同搜尋引擎的节奏也不一样。把鏈路控制在最短狀態是可控的部分，至于什么时候生效，不在你能决定的范围内。