为什么重定向链值得单独拿出来说
蜘蛛池的入口页往往经过多次迁移：域名换过、协议从 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。
- 定期清理长期未使用的跳转规则，尤其是排期活动留下的临时规则。
入口页层面的检查节奏
蜘蛛池入口页数量通常不小，不需要每天全量检查。可以按批次轮换：每次抽一部分入口，检查跳转层数、终址状态码、终址是否与预期一致。发现链路变长的先记录下来，再统一修改，避免零散改动引入新的循环。
最后提醒一点：跳转修好之后，蜘蛛重新抓取并更新索引需要时间，不同搜索引擎的节奏也不一样。把链路控制在最短状态是可控的部分，至于什么时候生效，不在你能决定的范围内。