蜘蛛拿到一个 URL 后先发请求。如果响应是 301 或 302，它不会就此停下，而是读取 Location 头，继续请求下一个地址，直到拿到真正的页面，或者走到它愿意放弃为止。这条"跟着走"的路径就是重定向链。链条短，抓取顺畅；链条长，抓取预算被消耗在中间站，页面被抓取的节奏也会被拖慢。这里不讨论能不能收录，只讨论怎么让蜘蛛少走冤枉路。
重定向链是怎么走出来的
大多数跨多跳的链子不是一次设计出来的，而是几次配置叠加的结果。典型顺序是：蜘蛛请求 http 版本，301 到 https；再 301 到带 www 的域名；再 301 到带尾斜杠的规范形式；最后才是页面。每一跳听起来都合理，合起来就是四跳。
常见的拼接来源：
- 协议升级：http 到 https，通常是最先加的一层。
- 域名收敛：裸域到 www，或者反过来。
- 路径规范：去尾斜杠、大小写统一、补默认文件名。
- 站点改版：旧栏目 301 到新栏目，旧栏目后来又被新规则再转一次。
- 中间层跳转：CDN、负载均衡、地域或语言判断，在到达源站前先做一次 302。
单看每一层都没问题，问题在于它们会相乘。
几跳算多
没有一个官方阈值，可以按下面的经验给自己定规矩：
- 1 跳到落地：正常。
- 2 跳到落地：可接受，但要记下来，能合并就合并。
- 3 跳及以上：当作待修项，尤其是栏目页和详情页这类关键地址。
链子越长，中间任何一跳出现超时、5xx 或配置遗漏，整条路就断了。很多蜘蛛对跳转次数本身也有上限，超过上限就不再往下走，你看到的"抓了但没进索引"，有时只是它没走到最后。
状态码别用错
- 301：永久跳转，适合已经确定的新旧对应关系。
- 302 / 307：临时跳转，适合灰度、临时维护页。
- 308：永久且保持请求方法，接口类地址用得多。
- meta refresh 与 JS 跳转：蜘蛛要渲染才能识别，属于较弱的信号，能用服务端 301 就别用它们。
临时跳转长期挂着很常见：怕改错，所以一直用 302。如果新旧地址的关系已经定了，早点换成 301，让蜘蛛和用户拿到一致的信号。
怎么查出多余的跳转
从命令行和日志两头查最省事：
- 用 curl -I 逐个访问重要 URL，看返回码和 Location；再用 curl -IL 跟着走一遍，数清楚跳了几次、每跳耗时多少。
- 在访问日志里筛 301/302 的请求，重点看两类：跳转目标又返回 3xx 的，以及被大量内外链指向的跳转地址。
- 检查 Sitemap 里提交的是不是最终地址。提交中间地址，等于让蜘蛛从半路开始走。
- 检查站内链。菜单、面包屑、正文链接如果指向 301 的旧地址，蜘蛛每次都会多走一跳。
收敛的顺序
按影响面从大到小改：先把入口全部替换成最终地址，包括内链、Sitemap 以及能谈判的外链；再合并协议、域名、斜杠这几层，尽量压到一跳。改完用命令行复测一遍，并在日志里观察一段时间，看 3xx 请求量是否下降、落地页的抓取是否变密。
重定向链本身不是错误，它只是有成本。把成本控制在能解释的范围内，抓取路径就清爽了。