旧链接在浏览器里能跳走，就算完成301迁移了吗？

不算。浏览器打开旧地址后进入新页面，只能证明这次访问发生了导航，不能证明旧地址返回了HTTP 301。页面脚本、即时刷新、浏览器已经保存的跳转，都可能让地址栏看起来“迁移成功”。验收公开内容页面的迁移，需要从旧URL的首个响应开始。

先向开发要映射，再检查响应

映射表至少包含旧地址、新地址、永久还是临时迁移、参数如何处理，以及目标内容是否对应。不要只接收一条“全部跳新站”的规则。产品说明应该到同一份说明的新位置，不能为了避免404把不同问题全部送到首页。

涉及语言、型号或筛选状态的参数需要逐项讨论。跟踪参数与决定内容的参数用途不同，全部删除或全部透传都可能有问题。永久与临时也应根据实际迁移目的决定，而不是为了听起来更利于SEO就统一改为永久。

用不跟随跳转的GET看第一步

下面是只读教学命令，example.com需要替换成获准检查的真实旧地址：

curl -sS -D - -o /dev/null https://example.com/old-guide/
curl -sS -L -D - -o /dev/null https://example.com/old-guide/

第一条不跟随重定向，检查状态码与Location；第二条跟随HTTP跳转，检查链路是否到达正确目标。curl不执行页面JavaScript。如果首个响应是200，而浏览器稍后跳走，就不能把这份证据写成“301已配置”。

光算的JavaScript跳转与服务器重定向的区别进一步解释了执行阶段、渲染依赖及页面迁移的选择。这里检查的是公开内容页；支付、表单提交和API端点涉及请求方法，不能直接照搬同一套规则。

到达新地址以后，还要看内容

• 最终页面是否返回预期状态，而不是登录页、错误页或空白外壳。
• 原来的型号、主题与必要资料是否仍能找到，是否错误落到另一语言或产品。
• 新页面的canonical是否符合预定目标，站内重要链接是否已直接使用新地址。
• 从旧地址直接访问和从站内点击，是否表现一致。

浏览器检查尽量使用干净的测试环境，并对照实际网络响应。已有永久跳转缓存可能影响观察，不要因为一台电脑还去旧目标就反复改线上规则。若存在多跳，按CDN、代理、应用与页面脚本分别定位，避免在最后再加一段脚本遮住问题。

交付单写配置结果，不写搜索承诺

保留旧URL、首跳状态、每个跳转目标、最终地址、正文核对和检查时间。代表性检查通过后，再核对完整迁移清单中是否有遗漏或错误映射。技术验收可以确认规则与内容一致，不能据此保证搜索引擎何时换成新URL，或承诺排名不会变化。