301重定向，怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /32d0f2b7dfaf.html
📄
301重定向，怎样取得可复查的状态证据
可复查的状态证据，指的是任何人按你记录的时间、请求地址和命令重新执行一次，都能得到相同或可解释的响应结果。对301重定向来说，核心证据不是“我看到浏览器跳过去了”，而是原始响应行、Location响应头和重定向链这三类可留存、可比对的数据。浏览器地址栏变化只能证明发生了跳转，不能区分301、302、307，也不能证明跳转发生在哪一跳。
为什么浏览器截图不算证据
浏览器会自动跟随重定向，并可能缓存结果。你看到最终页面，中间经过几次跳转、每次用什么状态码，界面上通常不显示。换一台设备、清一次缓存、换一个网络，结果就可能不同，所以截图无法复查。
另一个常见误解是只看最终状态码。假设A跳到B、B跳到C，你测C返回200，这不能说明A的301配置正确。必须逐跳检查，把每一跳的状态码和Location单独记录下来。
用命令行取得原始响应
在终端执行下面的命令，只发一次请求、不跟随跳转，直接看服务器返回的响应头：
curl -I https://example.com/old-page
重点看三行：
- 第一行状态码，确认是
301而不是302、303、307、308。 Location:后面的目标地址，确认指向预期URL，且带正确的协议和域名。- 如果存在
Cache-Control或Expires，记录缓存策略，它会影响复查时是否命中旧结果。
要观察完整跳转链，用：
curl -IL https://example.com/old-page
-L会跟随跳转，输出里会出现多组响应头。每一组都以状态码开头，按顺序数清楚有几跳、每跳落在哪个地址。把输出重定向到文件保存，例如curl -IL 地址 > redirect-check.txt，文件本身就是可复查证据。
判断证据是否合格的四项检查
- 可重复：同一命令在不同时间、不同网络下执行，状态码和Location一致，或差异能被缓存、CDN节点解释。
- 逐跳完整：记录从起点到终点的每一跳，而不是只记录首尾。
- 无链式堆积：如果出现A→B→C→D这种多跳，说明旧规则没清理干净，应直接改成A→D。
- 无循环：链中出现重复地址即为循环，必须修复，否则用户和抓取都会失败。
适用条件是你能在服务器或本机运行命令行工具。如果只能通过网页工具检查，选择能显示状态码和完整跳转链的工具，并把结果页面连同测试时间一起存档；但这类结果依赖工具自身的请求方式，复查时最好固定用同一个工具。
把证据整理成可交接的记录
时间人手有限时，优先给每个待迁移或已迁移的URL建一行记录，字段包括：原始URL、期望目标URL、实测状态码、实测Location、跳转跳数、测试命令、测试时间。这样别人复查时不需要猜你当时怎么测的。
假设一个旧页面应指向新页面，你测出状态码是302，Location正确。这仍不合格：302是临时跳转，不会把权重信号稳定传递到新地址。此时应改服务器配置为301，再重新执行同一条命令，对比两次输出，确认状态码已变为301。
如果状态码是301但Location指向了带参数的中间页，再跳到最终页，说明规则写在了错误的层级。处理方式是找到产生第一跳的配置位置，直接把它指向最终地址，然后重新取证。
下一步
挑一个你最不确定的旧URL，执行一次curl -IL并把完整输出保存下来，按上面的四项检查逐条核对；发现多跳、循环或非301状态码时，先改配置再重新取证，不要用旧输出交差。
