用户点击旧文章链接，经过几次跳转后进入首页，服务器最后返回200。技术上这次请求结束了，内容迁移却可能没有完成：用户找的是具体教程，首页并没有回答原来的问题。检查重定向时，应同时看链路和目标内容。
从用户真正拿到的旧地址开始
在XunL HTTP状态码检测中输入最初入口。如果迁移涉及HTTP升级，就保留http起点；如果旧外链带着旧目录，也要保留这个目录，不要一开始就替换成最终地址，否则会跳过需要验收的部分。
例如想验证 http://example.com/products/a 是否迁到 https://www.example.com/items/a，应先测前者，再读每一跳。这里的地址是教学示意，实际应换成自己有权维护的公开页面。工具从本站服务器访问标准HTTP或HTTPS公开地址，不是本地浏览器的会话重放。
把每次跳转写成一条可理解的路径
若请求先补HTTPS、再补www、最后替换目录，就要记录这三段分别由哪一层规则产生。管理员可以评估能否让旧入口更直接地到达正确页面，但不能只为了减少次数而破坏已有语言、登录或业务分流。
301表达永久迁移，302表达临时跳转。看到302不应机械改成301，先确认它用于长期改址，还是短期维护或其他临时业务。状态语义与实际目的相符，比把所有响应统一成同一个数字更重要。
检查不能停在首页。抽查历史文章、产品详情与主要广告落地页，才能发现某个旧目录遗漏或批量规则指错。将旧地址、新地址和是否保留原内容列成映射表，后续复查也能使用同一组样本。
200、403、429与5xx，下一步完全不同
200只说明这次HTTP请求成功。应打开正文核对是否真的是目标页面，排除错误提示被包装为成功响应、登录页或人机验证页等情况。页面还可能带有不索引指令，这也不是状态码本身能解决的问题。
403表示本次访问被拒绝，可能与防护、地区或身份条件有关；429涉及频率限制，继续密集重试可能扩大干扰。404是找不到资源的线索，不能与前两者混为一谈。服务端5xx则要结合代理、应用和日志排查，不能把所有失败都归到“链接失效”。
如果本地浏览器正常、检测服务器失败，先保存时间、请求地址和状态，再查对应日志。不同来源、Cookie和防护策略可能得到不同结果，一次差异不够证明网站对所有用户都不可用。
修复后怎样证明链路符合预期
仍从原来的旧网址复测，确认各跳目标、最终状态和内容。改了域名或目录时，还要让导航、站点地图及规范网址使用正式地址，避免用户持续从站内链接进入旧路径。需要改配置时保留原规则和回滚方法，先验收少量代表链接再扩大范围。
这份检测不访问内网、回环地址或自定义端口，也不检查登录后的操作流程。结果只能说明本次公开请求的观察，真实收录、表单提交和用户体验仍需采用相应方式验证。
所有删除的产品都跳首页，能避免404吗？
可能改变状态，但不一定满足用户意图。应根据是否有等价替代内容制定迁移或退役方案，不能把得到成功响应当成保留了原页面价值。
改完规则，为什么浏览器结果没变？
可能存在浏览器、CDN或服务器缓存，也可能修改的并非实际生效层。先对比检测链路与配置，再核查缓存来源，避免在错误位置重复添加规则。
个人微信：ssevening
