永久重定向，入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0f918d272ba8.html
📄
永久重定向，入口页面正常但深层链路失效时怎样定位断点
先给结论：入口正常只说明第一跳可达，深层失效通常发生在第二跳之后。定位时不要从入口页重新测一遍，而要把目标深层 URL 当作起点，逐跳记录状态码、Location 和最终落地 URL，找到第一处不再返回 301/308 或落地内容与预期不符的位置。下面给出两种常见解释、区分证据和可执行动作。
两种解释：断点在服务端规则，还是在链路中间
第一种解释是服务端重定向规则本身存在断层。入口页命中了通用规则，能正常跳转；深层 URL 因为路径层级更多、参数或大小写差异，没有命中同一条规则，于是返回 404、410 或 200 但内容错误。第二种解释是链路中间被改写或截断，例如 CDN、反向代理、负载均衡或前端路由在某一跳把带尾斜杠、大小写或查询参数的请求处理成了另一个地址，导致后续规则不再匹配。
两种解释都会表现为“入口正常、深层失效”，但修复位置完全不同：前者改源站规则，后者改中间层转发或规范化逻辑。因此不能只看最终结果，必须看每一跳。
用逐跳记录区分两种解释
对失效的深层 URL 做一次完整跟随，记录每一跳的请求 URL、响应状态码和 Location。判断依据如下：
- 如果第一跳之后直接出现 404/410，且中间没有 301/308，说明源站规则没有覆盖该路径，偏向第一种解释。
- 如果某一跳的 Location 指向了非预期主机、协议或路径（例如缺少尾斜杠、被改成小写、参数被丢弃），之后才失效，偏向第二种解释。
- 如果链路中存在 302 或 307，说明中间层临时改写了跳转，永久重定向的语义在这里已经中断，后续规则可能不再按预期匹配。
- 如果同一路径在带与不带查询参数时结果不同，说明规则对参数的处理不一致，断点可能出在参数拼接或转发环节。
一个假设例子：目标 URL 为 https://example.com/a/b/c，入口 https://example.com/a 返回 301 到新地址，但深层 /a/b/c 在第二跳返回 404。逐跳记录显示第一跳 301 的 Location 只保留了 /a 对应的新前缀，丢掉了 /b/c。这说明断点在规则拼接，而不是目标页不存在。
实际动作：先固定测试样本，再对比修复前后
不要只测一个深层 URL。先按路径深度、是否带参数、大小写和尾斜杠四个维度各选少量样本，形成一组可重复的测试集。对每个样本记录跳转次数、每跳状态码、最终 URL 和最终页面标题或关键内容。这个动作的结果会直接决定下一步：如果多个样本在同一跳失败，优先检查该跳的转发规则；如果失败只出现在带参数的样本，优先检查参数保留逻辑。
修复后重复同一组样本，而不是换新样本。只有修复前后的记录能一一对应，才能确认断点是否真正消失。注意，抓取量或请求量下降不能单独证明修复正确，它也可能来自抓取配额变化、robots 限制或统计口径调整；robots.txt 的抓取限制也不等于可靠的索引移除。
边界：哪些情况不能照搬这套定位方法
如果深层 URL 本身已经不存在且没有对应新地址，逐跳记录只能确认“没有重定向”，不能推出应该跳到哪里，此时需要先确定内容映射关系。如果站点使用客户端路由，服务端可能只返回入口 HTML，深层可见内容由前端脚本决定，逐跳状态码无法反映最终可见内容，需要额外核对渲染后的落地页面。站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名，这些都不能作为链路正常的证据。不同搜索引擎对重定向和索引信号的支持情况须分别核查，不能用一个引擎的表现推断另一个。
当入口正常而深层失效时，把目标深层 URL 当作测试起点、逐跳记录状态码与 Location、用固定样本对比修复前后，才能把断点定位到具体一跳，而不是停留在“入口能打开”的假象里。
