跳转链是怎么一步步长出来的
单个 301 很常见，问题出在跳转叠加。一次访问要经过好几跳才能到达最终页面，蜘蛛的每次请求都被消耗在中间环节上。常见的叠加来源包括：
- 协议切换：http 跳 https，同时 www 又跳非 www，两件事发生在不同层；
- 结尾斜杠：内链写的是 /about，服务器却把 /about 跳转到 /about/；
- 改版与栏目调整：旧目录 301 到新目录，新目录后来又改了名字，旧地址没有同步更新；
- 平台或插件默认设置：建站程序、CDN、安全组件各自加了一层跳转；
- 大小写与参数规范化跳转，和前面的规则再叠一层。
单独看每一层都合理，串起来就变成三跳、四跳，甚至出现 A 到 B 再回到 A 的循环。跳转链本身不会让页面消失，但它会让同一个目标页面对蜘蛛显得更远。
对抓取的实际影响
搜索引擎对永久跳转的处理是把信号传递到最终地址的，只是这个传递过程并非没有成本。
- 抓取预算被中间地址占用，真正需要更新的页面被排到后面；
- 页面发现变慢，尤其是站外新入口指向的仍然是旧地址时；
- 信号分散，外链、canonical、Sitemap 各自指向不同版本时更容易出现分歧；
- 排查变复杂，日志里同一条路径出现多个状态码，判断抓取问题更费时间。
判断标准可以简单一点：从任意一个入口到最终页面，最好不超过一跳。
自查：一条一条跟到底
不要只看首页，要按 URL 类型抽样。建议至少覆盖这几种：
- 首页的几种写法：http、https、带 www、不带 www、带默认首页文件名的地址；
- 栏目页与文章页，各挑几个，分别从 Sitemap、站内链接、站外入口进入；
- 历史上改过目录或域名的老地址，随机抽几条；
- 移动端地址或其他版本地址（如果有）。
具体做法上，用命令行工具只取响应头是比较直接的方式：对目标地址发一次请求，看 Location 字段指向哪里，再对新的地址重复一次，直到返回 200。浏览器开发者工具的网络面板也能看到同样的链条。日志侧则统计 301、302、307、308 的占比与来源路径，找出被反复请求的中间地址。
处理原则：让人一次跳到终点
- 合并跳转。把 http 到 https、www 到非 www、结尾斜杠规范化收拢成一条规则，一次跳到最终地址。
- 永久迁移用 301。长期用 302 表示迁移时，搜索引擎可能继续保留旧地址，迁移完成后应改回 301。
- 回改站内入口。把导航、面包屑、正文内链、友情链接里的旧地址换成最终地址，让蜘蛛不必经过跳转。
- 同步 Sitemap 与 canonical。两者都写最终地址，避免一个放旧地址、另一个放新地址。
- 避免一律跳首页。下线的栏目页跳到首页是常见做法，但数量一多，会把大量入口指向同一页，更合适的做法是指向最相关的上级栏目，或返回 410。
- 检查循环。定期抽取旧地址做一次全链路跟踪，确认没有多跳回路。
几类容易被忽略的跳转
除了服务器层的规则，还有几种跳转藏在别处：
- 脚本跳转与 meta refresh。蜘蛛需要执行脚本或解析页面头才能发现目标地址，不如 301 直接明确。
- 移动端与桌面端互跳。规则写反时两端会互相指向，蜘蛛来回切换。
- 多语言或多地区版本跳转。按语言自动跳转的页面，最好同时提供可点击的切换入口，别让蜘蛛只能依赖跳转。
- 带参数地址的规范化跳转。筛选、排序参数被跳转到干净地址是合理的，但别让干净地址又跳回带参数的版本。
什么时候该再查一遍
跳转规则会被后来的改动覆盖。下面几个时间点值得重新跑一次自查：换域名或启用 HTTPS 之后、站点改版或栏目调整之后、更换 CDN 或安全组件之后、批量修改内链之后。每次查完把当前的跳转规则记一笔，下次排查会省不少事。
跳转自查不需要多复杂的工具，难的是每次都跟到最后一跳。把这条链路理顺，蜘蛛到页面的路径变短，抓取和页面发现会更接近你的预期。