重定向看起来是件小事，一条 301 就能把老地址指向新地址。但当站点经历改版、换域名、调整目录结构，或者只是把 http 改成 https 之后，重定向规则往往会攒下不少问题：跳转链一层套一层、两条规则互相指、跳转之后路径和参数丢失。访客遇到这些，可能只是多等半秒；爬虫遇到，往往就直接放弃跟进。
重定向为什么会越积越多
大多数重定向都不是一次规划好的，而是遇到问题临时加的。第一次换域名加一条规则，后来统一 www 再加一条，再后来启用 HTTPS 又加一条，最后上线新栏目结构时又补一条。单看每条规则都没错，叠在一起就成了一条冗长的链路：A → B → C → D。每多一跳，就多一次请求往返，也多一次出错的机会。
四类高频问题
1. 跳转链太长
理想情况下，从旧地址到最终地址应当只有一跳。可以抽查一批历史 URL，用带重定向追踪的工具看完整链路。如果发现两跳以上，就把中间环节合并，让旧地址直接指向最终地址。
2. 循环或互相重定向
典型场景是 http 跳 https、https 又跳回 http，或者 www 与非 www 互相指。浏览器通常提示“重定向次数过多”，爬虫同样会停止跟进。检查这几组规则时，建议同时确认服务器配置（如 Nginx、Apache）和 CDN、负载均衡层是否各写了一套规则，多层叠加是最容易打架的地方。
3. 跳转类型用错
- 301：地址永久变更，适合改版迁移、目录调整。
- 302 / 307：临时跳转，适合活动页、灰度期间。长期用 302 处理永久变更，会让搜索引擎一直不确定最终地址是哪一个。
- JavaScript 跳转或 meta refresh：能不用就不用。它依赖页面被渲染，链路里一旦夹着它，排查会变得很麻烦。
4. 跳转后路径、参数丢失
把 /old/a.html 统一跳到首页，等于把原本有内容价值的地址全部指向同一个页面。更合理的做法是尽量做到一对一映射；确实没有对应页面的，再归拢到最接近的栏目页或首页。带跟踪参数的地址，跳转时也应保留核心参数，避免访客落地后丢失来源信息。
自查清单
- 把站点当前生效的重定向规则列出来，集中放在一处，避免散落在多个配置文件里各自为政。
- 抽查旧地址样本，确认跳转链只有一跳，且最终响应状态码为 200。
- 检查 www 与非 www、http 与 https 是否收敛到唯一版本。
- 确认没有循环跳转，也没有指向 404 页面的跳转。
- 确认跳转后路径与必要参数被保留。
- 检查分页、筛选、大小写、结尾斜杠等容易产生重复地址的形式是否被正确处理。
- 更新站点地图与内部链接，尽量让链接直接指向最终地址，减少对跳转的依赖。
改版迁移时先做映射表
迁移前把旧 URL 和新 URL 整理成一张对照表，逐条标注处理方式：一对一、一对多、合并到栏目页，还是确认下线。表里空着的条目就是风险点，需要在上线前补上决定。上线后按表逐条验证状态码和落地页面，比随机抽查靠谱得多。
重定向是给已经存在的地址兜底，不是长期方案。内部链接、站点地图、对外分享的地址，都应该尽早更新到最终版本，让重定向只服务外部旧链接。
验证时看什么
不要只看浏览器能不能打开。用命令行查看响应头里的状态码和 Location 字段，往往能更快发现问题；批量验证时可以写个脚本遍历映射表，把状态码不是 200、链路长度大于 1 的地址挑出来逐一处理。处理完隔一段时间再跑一遍，因为有些问题会在新规则上线之后才暴露出来。