页面从 A 跳到 B 再跳到 C，用户端可能只感觉“慢了一点”，但对搜索引擎来说，这等于一次抓取被拆成了三次请求。跳转链本身不违规，也不直接等于不收录，可当站点里大量 URL 都存在两跳以上时，抓取资源就会被消耗在中间环节，新页面被发现、被处理的节奏自然会被拖慢。
每次跳转都是一次独立请求
爬虫遇到 301 或 302 时，需要重新请求 Location 指向的地址，直到拿到最终返回 200 的页面。两跳就是三次请求。中间地址如果还带参数、大小写或尾斜杠变化，处理结果可能被延后甚至丢弃。更麻烦的是，链路中间那些地址本身也可能被抓取、被索引，最后形成一堆指向同一内容的不同 URL。
先量清楚跳转链到底有几跳
不要凭印象判断，建议按下面几步抽样统计：
- 抽真实入口 URL，包括首页导航、Sitemap 里的地址、外链落地页、日志中出现频次最高的地址，而不是只测首页。
- 用支持跟随跳转的抓取工具或命令行查看完整链路，逐跳记录状态码和 Location。
- 按链长分组，统计一跳、两跳、三跳及以上的 URL 各有多少。
- 把链路最长、同时被抓取最频繁的那批 URL 排到处理队列最前面。
多跳通常是从哪来的
- HTTP 跳 HTTPS、裸域跳 www 各写了一条规则，叠加起来就变成两跳。
- 旧栏目 301 到新栏目，新栏目又 301 到最终目录，历史规则一直没有清理。
- CDN、负载均衡或反向代理层又额外设置了一次跳转。
- 尾斜杠、大小写、参数清理由不同层分别处理，一次请求被多次改写。
- 页面内 JS 跳转和服务器端跳转混用，链路上很难判断终点在哪。
- 移动端与 PC 端互相跳转，没有一方作为固定终点。
收敛顺序：从流量大的入口开始压
建议按这个顺序动手，避免一边改一边制造新的跳转：
- 先合并同源跳转，把 HTTP 到 HTTPS、裸域到 www 合成一条直接指向最终地址的规则。
- 把历史栏目跳转的目标改成最终地址，而不是指向另一个会跳转的地址。
- 检查代理和 CDN 层是否重复配置了跳转，同一次请求只保留一层处理。
- 尾斜杠与大小写策略在规则层一次性定下来，不要靠跳转去纠正。
- 站内链接、Sitemap、canonical 全部改成最终地址，停止自己制造跳转。
- 旧规则保留一段时间，等日志里确认中间地址已不再被抓取，再考虑下线。
收敛之后该看什么
重点看三个变化：最终地址的抓取频次有没有上升、中间 URL 的抓取量有没有下降、新页面从被发现到被抓取的间隔有没有缩短。索引量本身每天都会波动，不要拿一两天的高低下结论。
跳转链是抓取效率问题，不是收录开关。把链路压短是减少损耗，并不能保证某个页面一定进索引。
几个容易忽略的边界
- 临时性跳转不要长期挂 302，状态码要和实际意图一致。
- 链上任意一跳出现 404 或 5xx，整条链就断了，最终页面等于没被访问到。
- 跳转目标如果被 robots.txt 屏蔽，抓取跑过去也拿不到内容。
- 跳转目标带 noindex，抓取到了也不会留在索引里，等于白跑一趟。
- 跨域跳转的信号传递比同站跳转更难判断，能避免就避免。
总结起来就是三步：先量清楚每条入口的跳转链长度，再按入口价值从高到低合并规则，最后用日志验证中间地址是否真的退场。链路越短，抓取和发现的损耗就越少。