用途：当某个 URL 在迁移、canonical 变更或路由发布后表现异常时，用 redirect-trace 追踪它的重定向路径。它手动跟随 HTTP 重定向，记录每次响应，并审计最终目标页面的基本可索引性与 canonical 证据。该追踪只是执行机器与时间点的一次观测，CDN、地域、Cookie、User-Agent 及后续部署都可能造成差异。
主要能力：按顺序输出 chain，每步包含请求 URL、状态码、Location、解析后的下一跳 URL 和耗时；对比 finalUrl、finalPage 与 summary.finalStatus；summary.issues 可识别循环、跳数上限、缺少 Location 的重定向、最终 4xx/5xx、最终页面不可索引或 canonical 不匹配。还可查看 metaRobots、xRobotsTag、canonical 和 warnings。
使用方式：MCP 下先调用 seo_list_reports（category 为 monitoring），再调用 seo_describe_report（id 为 redirect-trace），然后调用 seo_run_report，例如 {"id":"redirect-trace","params":{"url":"https://example.com/old-page","maxHops":8,"js":false,"refresh":true}}。CLI 使用同一注册表：seo reports describe redirect-trace --json 与 seo reports run redirect-trace --params '{"url":"https://example.com/old-page","maxHops":8,"refresh":true}' --json。maxHops 需传小的正整数，超长链不是有意义的成功条件。
适用场景：调试重定向循环、断链、落地页不匹配，验证迁移或路由发布后的跳转行为。
限制：缺少 finalPage 或出现抓取警告会限制可索引性结论；JavaScript 渲染只影响最终页面提取，不影响 HTTP 重定向链；canonical 指向别处或 302 都可能是有意为之，报告并不知道期望目标。修改重定向前应先确认目标 URL 映射，真实迁移优先使用一条直接永久重定向，消除循环、补回缺失 Location，仅在目标正确时对齐最终 canonical，部署后重新追踪。不要仅凭链差异就断言 SEO 缺陷或排名影响。