永久重定向方法 - 测试环境与线上怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5678f79e6918.html
📄
永久重定向方法 - 测试环境与线上怎样对照
测试环境和线上环境做永久重定向对照，核心不是比对页面能不能跳，而是确认同一组旧地址在新旧两套环境里，最终落到同一个目标地址，并且返回的状态码一致。只要有一侧返回 301，另一侧返回 302 或 200，搜索引擎看到的就是两套不同信号，上线后容易出现收录混乱。
先观察：两套环境各自返回什么
在测试环境和线上环境分别对同一批旧 URL 发起请求，记录三件事：状态码、Location 响应头里的目标地址、是否经过多跳。可以直接用命令行核对，把下面这段里的域名替换成你实际要测的地址：
curl -I https://example.com/old-page
看返回的第一行状态码是不是 301，再看 Location: 后面的地址。测试环境和线上环境各跑一遍，把结果并排列出来。如果测试环境返回 301、线上返回 302，说明两套配置用的重定向类型不同，这本身就是需要先解决的问题。
判断：哪些差异属于必须统一的项
对照时区分“必须一致”和“可以不同”两类。必须一致的包括：状态码类型、最终目标地址、跳转链长度（尽量一跳到位）。可以不同的是：测试环境域名本身、内部测试用的参数。判断依据是搜索引擎最终抓取到的是线上地址，所以线上那套结果才是基准，测试环境要向它对齐，而不是反过来。
- 状态码：永久重定向应为 301（或 308，视具体实现而定），两侧必须一致。
- 目标地址：去掉测试域名后，路径部分应与线上完全相同。
- 跳转链：A→B→C 这种多跳要压成 A→C，链越长越容易在某一环丢失信号。
- 大小写与斜杠：
/Old-Page与/old-page、带不带结尾斜杠，可能被当成不同地址。
处理：让测试环境按线上规则复现
常见做法是把重定向规则集中写在一处配置里，测试和线上引用同一份规则，只替换域名变量。如果测试环境是独立搭建的，容易漏掉线上后来追加的规则，这时要拿线上的规则清单逐条在测试环境复现，而不是凭印象补。
一个容易踩的坑是：测试环境为了不让搜索引擎抓到，加了 robots.txt 限制或整站跳转到登录页。robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取，不保证已收录的旧地址被移除；而整站跳转会让重定向测试结果失真。测试重定向时，应让被测的那组 URL 能正常返回真实状态码。
假设有一批旧地址 /product-a 要永久跳到 /products/a，测试环境配置写成跳转到 /test/products/a，线上写成 /products/a。这种差异在测试时看着正常，上线后目标地址就错了。正确做法是规则里只保留相对路径，域名由环境变量注入。
复查：上线前后各查一遍
上线前，在测试环境跑完整 URL 清单，确认每条都返回 301 且目标正确。上线后，用同样的清单再跑一遍线上地址，重点看有没有哪条突然变成 302、404 或跳到了首页。可以用脚本批量对比两份结果，把状态码或目标地址不一致的行标出来。
复查时还要注意 HTTPS 与重定向的叠加。HTTPS 不保证安全无漏洞或排名，它只是传输层协议；但如果站点同时做了 HTTP→HTTPS 跳转和旧路径跳转，可能出现两跳。判断方法是看最终地址是否一次到位，中间是否多出一次协议跳转。若确实多跳，考虑把协议跳转和目标路径跳转合并处理。
另外，站点地图不保证收录，把新地址放进 sitemap 只是辅助发现，不能替代 301 本身的作用。不同搜索引擎对 301 的处理节奏和支持细节须分别核查，不要假设所有引擎行为完全一致。
下一步：整理一份包含旧地址、期望目标地址、期望状态码的对照表，先在测试环境逐条验证，再拿同一张表核对线上，把不一致的条目作为上线前必须修掉的清单。
