📍 WDQWDWQD987AAAAA:216.73.216.136
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a455dbfaee64.html
📄

301重定向设置 - 修复后怎样验证响应是否正确

验证修复后的 301 响应，核心是确认三件事：旧地址返回的是 301 而不是 302 或 200，Location 指向的目标地址正确，且目标页本身能正常打开。最直接的做法是用命令行工具查看响应头，而不是只看浏览器地址栏是否跳转成功——浏览器会自动跟随跳转，掩盖中间状态。

先区分三种“看起来像修好了”的情况

很多人改完重定向后，在浏览器里输入旧地址，看到页面正常显示就认为完成了。这只能说明跳转链路最终到达了一个可用页面，不能说明状态码正确。需要分开判断：

• 状态码是 301：表示永久重定向，是迁移场景下通常想要的结果。
• 状态码是 302 或 307：表示临时重定向，搜索引擎处理方式与 301 不同，迁移场景下通常不是预期结果。
• 状态码是 200：说明旧地址本身还在返回内容，重定向根本没生效，或者被其他规则覆盖了。

还有一种容易被忽略的情况：旧地址返回 301，但 Location 指向的又是一个会继续跳转的地址，形成链条。链条越长，传递效果越容易衰减，也越难排查。

用命令行检查响应头：可执行的具体步骤

在终端执行下面的命令，把示例地址替换成你要检查的旧地址：

curl -I https://example.com/old-page

如果服务器对 HEAD 请求处理异常，改用：

curl -sSI https://example.com/old-page

重点看输出中的三行：

1. HTTP/1.1 301 Moved Permanently 或 HTTP/2 301：确认状态码是 301。
2. Location: https://example.com/new-page：确认目标地址拼写、协议、路径都正确。
3. 目标地址是否与你在配置里写的完全一致，包括结尾是否有斜杠。

接着单独检查目标地址本身：

curl -I https://example.com/new-page

如果这里返回 200，说明目标页可访问；如果返回 301 或 302，说明还存在第二跳，需要继续追下去，直到某一跳返回 200 或 404 为止。

判断结果：什么算通过，什么算有问题

把检查结果按下面的条件对照：

• 通过：旧地址返回 301，Location 指向目标地址，目标地址返回 200，且没有多余跳转。
• 需要修：状态码是 302、307、308 或 200；Location 指向错误地址；目标地址返回 404 或 5xx；出现两跳以上链条。
• 需要进一步查：同一旧地址在不同协议（http 与 https）、不同主机名（带 www 与不带 www）下返回结果不一致。这说明规则没有覆盖全部变体，需要逐条检查。

如果站点使用 CDN 或反向代理，curl 拿到的可能是边缘节点的响应。此时可以在命令中加 -H "Host: example.com" 并直接请求源站 IP，对比两边结果是否一致，以判断问题出在源站配置还是缓存层。

批量验证与常见误判

当修复涉及多条规则时，逐条手敲命令效率低。可以把旧地址整理成一个文本文件，每行一个，然后循环检查：

while read u; do echo "$u"; curl -sSI "$u" | head -n 1; done < urls.txt

这样能快速看出哪些地址没有返回 301。注意 <urls.txt 中的尖括号在真实命令里是重定向符号，写在 HTML 中需要转义，实际执行时直接使用即可。

几个常见误判需要避免：

• 只看浏览器是否跳转，不看状态码。
• 只测了一个变体（例如只测了 https 版本），漏掉 http、带 www、带尾斜杠等组合。
• 把 301 和 302 混用后没有复查，误以为配置生效。
• 目标页返回 200 但内容与旧页无关，跳转虽然“成功”，对用户和搜索引擎都没有意义。

验证完成后，下一步是把所有检查过的旧地址整理成清单，标注每条的状态码与目标地址，作为后续复查的基线。如果站点规模较大，优先处理有外部链接或已有流量的旧地址，而不是一次性铺开全部规则。