301重定向：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6a8c53f39aaa.html
📄
301重定向：入口页面正常但深层链路失效时怎样定位断点
先给结论：入口正常只说明第一跳成立，深层链路失效通常断在“中间某一跳的目标地址”或“服务端规则匹配顺序”上。定位时不要从入口重测，而要从失效的深层页反向逐跳回溯，记录每一跳的响应状态与 Location，直到找到第一个不再指向预期地址的节点。
先判断断点在前端链路还是在服务端规则
两种常见原因需要分开处理。第一种是链路本身断：A 跳到 B、B 跳到 C，但 C 已不存在或又跳回 A，形成断链或循环。第二种是规则断：请求某个深层路径时，服务端根本没有命中你期望的规则，而是被更宽泛的规则先截走。
区分依据是看响应头里的 Location 是否为你预期的下一跳。如果每一跳的 Location 都符合设计，但最终落地页返回 404 或 410，问题在目标资源；如果某一跳的 Location 突然变成首页、栏目页或带参数的陌生地址，问题在规则匹配顺序。假设一个场景：/old/a/b/ 应跳到 /new/a/b/，实际却跳到 /new/，这说明匹配 /old/a/b/ 的规则没有生效，被更靠前的通配规则抢先命中。这个判断决定下一步是去查内容迁移记录，还是去查规则文件。
条件一：只有部分深层页失效时，优先做反向逐跳回溯
当入口和多数深层页都正常、只有个别路径异常，问题往往出在这些路径自身的规则或目标资源上，而不是全局配置。此时动作是：从失效 URL 开始，用 curl -I 或浏览器开发者工具的 Network 面板逐跳请求，记录每次的状态码和 Location，直到出现 404、410、循环或非预期地址。
这个动作的结果会直接缩小范围。如果第一跳就返回 404，说明源路径的规则缺失；如果第一跳正常、第二跳 404，说明目标路径写错或目标页已被删除；如果出现 A→B→A，说明两条规则互相指向。确认断点后，下一步只需修那一处规则或恢复目标资源，不必全站重扫。代价是逐跳排查耗时，适合异常路径数量少、且你能拿到完整跳转链的情况。
条件二：大面积深层页同时失效时，先查规则顺序与匹配范围
当大量不同层级的深层页在同一时间失效，个别修复不现实，应优先怀疑规则顺序或匹配范围被改动。典型证据是：失效路径都带有相似前缀，或都落在某条通配规则的作用域内；而入口页因为规则更具体，反而没受影响。
动作是导出当前重定向规则，按实际生效顺序排列，检查宽泛规则是否排在具体规则之前。服务端通常按顺序匹配，先命中的先执行，所以一条 ^/old/(.*)$ 放在具体规则前面，就会把本应精确处理的深层路径全部收走。调整顺序或收窄匹配范围后，重新请求若干条代表性深层路径验证。这个动作的结果决定后续是继续微调规则，还是回滚到上一版配置。代价是改动影响面大，必须先在少量路径上验证，再全量生效。
例外：链路正常但仍失效，要查目标资源与缓存
如果每一跳的状态码和 Location 都正确，最终地址却打不开，断点不在重定向，而在目标资源本身：页面被删除、权限变更、或返回了错误的内容类型。此时继续改重定向规则没有意义。
另一种例外是缓存。中间层或浏览器缓存了旧的 301，导致你看到的是历史跳转链，而不是当前规则的真实结果。验证方法是换一个未访问过的客户端或加随机查询参数请求，对比响应是否一致。若不一致，先清理相关缓存再判断，否则会把缓存现象误判为规则故障。
把排查结果落成可复用的判断顺序
- 从失效的深层 URL 反向逐跳请求，记录状态码与 Location。
- 找到第一个偏离预期的节点，判断它是规则问题还是目标资源问题。
- 个别路径异常查该路径规则与目标页；大面积异常查规则顺序与匹配范围。
- 链路全对但打不开时，转向目标资源与缓存核查。
- 修复后在同类路径上抽验，确认断点不再复现，再决定是否扩大修改范围。
需要提醒的是，抓取工具报告某路径“消失”或请求量下降，并不能单独证明重定向处理正确，它也可能是抓取预算调整、robots.txt 限制或目标页本身被移除造成的；robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。定位断点应以逐跳响应为准，而不是以某一份统计的归零为结论。把断点定到具体那一跳，后续的修复动作才有明确对象，也才能判断这次改动是否真的解决了问题。
