改版、换域名、合并栏目，这些动作在运营节奏里很常见。真正容易出问题的往往不是新页面本身，而是那些已经存在了几年的老链接。它们还挂在用户的收藏夹、外部引用和搜索引擎的索引里，如果跳转没处理好，蜘蛛每次来访都要在一串重定向里多走几步。
重定向链是怎么被放大的
单次跳转本身没什么成本，但索引里的老 URL 数量常常远超预期。一个栏目页可能被多个入口收录，每个入口都指向同一条链，抓取预算就在这些重复动作里被消耗。重定向链越长，蜘蛛愿意继续跟下去的概率越低，尤其是链条末端还不稳定的情况。
更隐蔽的问题是循环跳转：A 跳到 B，B 又回到 A。蜘蛛通常会放弃，但每次抓取都会重新试一遍，日志里会反复出现同一批地址。
一次合格的重定向应该是什么样
跳一次就到位
旧地址直接用 301 指向最终的新地址，不要先跳到中间页、再跳第二次。链条超过两跳就该整理，超过三步基本值得单独排期处理。
状态码要选对
- 永久迁移：用 301，搜索引擎会逐步把索引和权重迁到新地址。
- 临时调整，比如活动页短期换位置：用 302，不要长期挂着。
- 页面确认不再提供：返回 404 或 410，比跳到一个内容无关的首页更清楚。
把旧链接统一跳首页是最常见的偷懒做法。对用户和蜘蛛来说，它都等于在说“这个内容没了”，很难起到迁移的作用。
目标地址只能有一个
确认跳转终点就是该页面的规范地址，不要再经过带参数、带斜杠或不带斜杠的版本，也不要再叠加一层 CDN 层面的跳转。
自查清单
- 导出近几个月的服务器日志，筛出状态码为 3xx 的请求，按 URL 聚合，看哪些地址被反复访问。
- 随机抽取一批老 URL，用命令行工具或抓取工具查看跳转链条，记录跳了几次、落到哪里。
- 检查跳转终点是否返回 200，且页面的 canonical 指向自身。
- 确认内部链接、导航、面包屑、Sitemap 里已经全部换成新地址，不再依赖跳转。
- 核对 hreflang、分页、移动版等特殊场景的跳转是否指向了正确的对应页面。
- 检查是否有页面跳到了 noindex 页面或被 robots.txt 屏蔽的地址，那等于把入口关上了。
迁移时的操作顺序
- 先确定新旧 URL 的一对一映射表，尽量避免多对一造成的语义丢失。
- 在服务器或 CDN 层配置跳转规则，优先处理访问量最大的那批地址。
- 更新站内所有指向旧地址的链接，让蜘蛛走新路而不是老路。
- 提交新的 Sitemap，同时保留一段时间旧地址的跳转，别急着撤掉。
- 迁移后持续观察日志和索引状态，直到 3xx 请求量明显下降。
几个常见的坑
- 跳转规则写成通配后误伤：把 /old/ 开头的整段都跳走，结果把不该动的栏目也带上了。
- 跳转目标又被重定向到登录页或地区选择页，蜘蛛拿不到真正的内容。
- 链式跳转跨了多套系统：Nginx 跳 CDN，CDN 再跳应用层，排查时很难一次性看全。
- 只在浏览器里点过一遍就认为没问题，浏览器会自动跟完整条链，看不出中间有几跳。
重定向不是“能打开就行”，而是要让蜘蛛用最少的请求走到最该去的页面。链条越短，越不容易在后续维护和调整中被误改。
建议把重定向当作一份长期维护的清单，而不是一次性的迁移任务。每次栏目调整、每次页面下线，都顺手记一笔，半年后再看日志，会发现 3xx 请求始终维持在一个很小的量级上。