站点做过改版、换过域名、切过 HTTPS，或者调整过栏目结构之后，同一个页面往往要经过好几跳才能到达终点。跳转本身不是问题，问题在于跳转链越接越长、指向越来越乱时，搜索引擎和用户看到的“最终版本”可能和运营以为的不一样。收录核对里，这类问题经常表现为：搜到的 URL 是中间某一跳，点进去又跳一次；或者老 URL 和新 URL 都被收录，内容却是同一份。
跳转链为什么会干扰收录
抓取一个 URL 时，遇到 301 或 302 会顺着 Location 继续请求，直到拿到 200 的页面。链条越长，中间任何一环出问题——超时、状态码异常、目标页被 robots 屏蔽——都可能让这次抓取停在半路。抓取没走完，后续的收录环节自然无从谈起；即使走完了，最终记录在索引里的也可能是链条中段的某个 URL。
另一个容易忽略的点是：多跳跳转会让每次抓取多花几次请求。对抓取预算有限的站点来说，这属于无谓的消耗。
第一步：把完整跳转链拉出来
不要只看第一跳。用 curl 的 -L 参数、浏览器开发者工具的 Network 面板，或者任意一个跳转链检查工具，把从入口 URL 到最终的每一步都列出来。重点看三件事：
- 一共几跳。两三跳以内通常可以接受，五跳以上就该考虑收敛了。
- 每一跳的状态码。301、302、307、308 语义不同，混用时要确认是否符合预期。
- 是否出现循环。A 跳 B、B 又跳回 A，抓取会直接失败。
建议把结果记成一行文本：入口 → 中间 → 中间 → 终点，旁边标注状态码。后续核对都基于这一行展开。
第二步：核对最终落地页是不是你以为的那个
很多跳转问题的根源不在链条长度，而在终点错了。常见的情况包括：老栏目整体 301 到了首页，用户和爬虫点进去发现内容对不上；产品下线后跳到某个不相关的分类页；HTTP 版本跳 HTTPS，但 HTTPS 那一侧又配了别的跳转规则，最后落到带 www 或不带 www 的另一个版本。
核对时把落地页和原始 URL 的主题对一遍。如果两者主题差距很大，这个跳转在收录层面大概率会被当作一次无关迁移，原来页面积累的信号很难顺利传递过去。
第三步：区分必要跳转和历史遗留跳转
不是所有跳转都要清掉。有些是当前架构必需的，比如 HTTP 到 HTTPS、非 www 到 www、大小写规范化。这些跳转应当保留，而且最好只有一跳。
真正要处理的是历史遗留：早年的域名跳转、已经废弃的旧栏目、被合并的重复页面，一层层叠加后，入口到终点可能要绕四五跳。判断方法很简单——问一句“如果去掉这跳，会不会影响现在的正常访问”。不会，就属于可以收敛的对象。
几种容易出问题的跳转形态
- 链式跳转：旧域名 → 老域名 → 当前域名，中间每一层都没清理。
- 跳转终点也是跳转：目标是某个已下线页面，它自己又 301 去别处。
- 跳转参数丢失：带参数的旧 URL 跳转时参数被截断，导致部分落地页收到错误参数。
- 跳转目标不可抓取：终点页被 robots.txt 屏蔽或返回 404，链条走到这里就断了。
- 混合协议与主机名：https 与非 https、带 www 与不带 www 之间来回跳。
收敛顺序：从末端往源头改
- 先确定每个页面的唯一权威 URL，作为所有跳转的终点。
- 把多跳链改成直接一跳到位，跳转规则写在离入口最近的位置。
- 检查终点页本身是否能正常返回 200、是否可抓取、是否和内容一致。
- 改完后重新拉一次跳转链，确认从入口到终点只剩必要的那一跳。
- 观察一段时间，看索引里是否还残留中间 URL 的版本，再决定是否需要单独处理。
改跳转规则属于对线上生效的改动，建议先在少量 URL 上验证，确认没有误伤正常访问后再批量铺开。测试域名、预览环境上的跳转配置不要和线上混在一起，否则排查时容易看错对象。
跳转链的问题往往不是“跳了”，而是“跳得太多次、最后一跳还跳错了”。核对收录时，先花十分钟把链拉直，比反复刷新索引状态更有效。