网站死链，入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a2fadf30bded.html
📄
网站死链，入口页面正常但深层链路失效时怎样定位断点
入口正常只说明第一跳可达，深层失效通常发生在入口之后的跳转、参数或权限环节。先别急着改入口，把深层链路按“入口→中间页→目标页”拆成可复现的请求序列，再逐跳记录状态码、重定向和响应内容，断点会落在第一处与预期不符的环节。
先取一条真实链路，而不是先看整站报告
你手里通常有一个具体对象：某个栏目页、某篇内容或某个下载入口。从它出发，手工走一遍到深层目标的完整路径，把每一跳的请求地址抄下来。假设入口是 /a，深层目标是 /a/b/c，中间经过 /a/b，这条三段链路就是你的定位样本。
优先选那种“入口能打开、点进去几步后失败”的路径，而不是随机抽整站链接。整站报告会把入口层和深层混在一起，掩盖断点的位置。一条可复现的链路，比一百条状态码更有定位价值。
逐跳比对状态码与最终落点
对每一跳分别请求，记录原始状态码和最终落点。判断断点看三件事：哪一跳开始偏离预期、偏离是状态码变化还是内容变化、后续跳转是否还能回到目标。
- 入口返回 200，中间页返回 301 到
/a/b/，目标页返回 404：断点在目标页，中间跳转正常。 - 入口 200，中间页 302 到登录页，登录后回不到目标：断点在权限或会话，不在链接本身。
- 入口 200，中间页 200 但正文为空，目标页实际存在：断点在中间页的渲染或参数拼接。
状态码一致不代表链路健康。中间页 200 却把参数丢掉，后面照样会失效，这种情况只看状态码会漏掉。
区分链接失效、参数失效与权限失效
三类原因的验证动作不同，先分清再动手。
链接失效
把中间页里的目标地址原样取出，直接请求。如果直接请求也失败，说明链接本身指向了不存在的地址，断点在链接生成规则或内容迁移。
参数失效
中间页地址带查询参数时，去掉参数再请求目标。假设 /a/b/c?id=12 失败而 /a/b/c 成功，断点在参数传递或后端对参数的处理，而不是路径不存在。
权限或会话失效
用未登录和已登录两种状态分别请求同一深层地址。若仅未登录失败，断点在访问控制；若两者都失败，回到链接或参数层面继续查。
这一步的实际动作是固定变量：每次只改一个条件，记录结果变化。结果指向哪一类，下一步就只查那一类，不再全站撒网。
两种处理顺序的取舍条件
定位到断点后，常见两种做法：先修中间跳转，还是先修目标页。选择取决于断点是否影响其他链路。
- 若中间页被多个入口共用，先修中间页，代价是要回归验证所有依赖它的入口，收益是一次修复覆盖多条链路。
- 若只有单条入口受影响，先修目标页或链接规则，代价是可能重复出现同类问题，收益是改动面小、验证快。
判断依据是共用程度：中间页被复用的范围越大，越值得先修；孤立链路则优先修末端。没有共用关系时，先修中间页只是把风险扩大。
验证修复是否真的到达深层
改完后重走同一条链路，并从入口开始逐跳确认落点，而不是只请求最终地址。最终地址返回 200，不能证明入口到深层的跳转已经恢复。
还要注意，站点地图里列出的深层地址被抓取，不等于它已被收录；robots.txt 的限制只影响抓取，不等于可靠的索引移除。这两点都不能作为链路已修复的证据。验证以实际请求序列为准，记录每一跳的状态与落点，确认断点消失后再进入下一条链路。
