死链处理：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d24a97aa87f3.html
📄
死链处理：入口页面正常但深层链路失效时怎样定位断点
结论先行：当入口页面能正常打开、深层链接却失效时，断点通常不在入口页本身，而在“入口页到目标页”之间某一跳的链接生成逻辑或状态码传递上。要定位它，先沿一条真实点击路径逐跳记录状态码和最终地址，而不是先改全站规则。这个结论有一个反例：如果失效只出现在特定设备、登录态或地区，且同一路径在无痕窗口里完全正常，那么断点更可能是前端条件渲染或访问控制，而非链接本身，此时逐跳抓取会把你引向错误方向。
为什么入口正常不代表链路正常
入口页面返回 200，只说明这一个地址可访问。深层链路失效往往发生在入口页输出的链接上：链接指向的地址被改写、参数被丢弃、或跳转链中某一跳返回了 404、410 或软 404。入口页和深层页由不同模板、不同数据源生成时，问题最容易藏在中间层。因此判断断点要区分三种情况：链接在 HTML 里就写错了；链接正确但跳转链中断；链接和跳转都对，只是目标页对特定条件返回了错误状态。三者对应的修复动作完全不同。
用一条路径逐跳记录，而不是全站扫一遍
选一条用户真实会走的路径，从入口页开始，对每一跳记录四项信息：请求地址、响应状态码、响应头里的 Location、以及最终渲染出的页面标题。动作上，用命令行工具跟随重定向并保留每一跳：
curl -sIL "https://example.com/入口路径"
结果如何影响下一步：如果中间某一跳出现 301 指向一个已失效地址，断点就在这条跳转规则；如果所有跳转都返回 200，但页面正文是“未找到”，那是软 404，问题在目标页的内容判断逻辑；如果入口页 HTML 里的链接地址本身就和预期不符，断点在模板或链接生成环节。只有先确定属于哪一类，后面的修复才不会误伤正常链接。
区分链接写错、跳转中断与软 404 的证据
三类断点有可区分的证据，不要混在一起处理：
- 链接写错：入口页源码里的 href 与目标页实际地址不一致，或缺少必要参数。抓取入口页 HTML 搜索该链接即可确认。
- 跳转中断：入口地址可访问，但响应头 Location 指向的地址返回 404/410。逐跳记录能直接看到断在哪一跳。
- 软 404：HTTP 状态码是 200，页面却显示空内容或错误提示。这类问题靠状态码扫描发现不了，必须比对页面正文与预期内容。
如果常规做法（比如批量检查全站状态码）没有发现问题，很可能就是软 404 或条件渲染在起作用，因为这两种情况都不会在状态码层面暴露。
一个假设例子：参数在跳转中被丢弃
假设入口页链接为 /list?cat=3，点击后经一次 301 跳到 /list，参数丢失，目标页因缺少分类参数返回空列表。此时状态码全是 200，全站扫描查不出异常。逐跳记录会显示：第一跳 301，Location 里没有 cat 参数；第二跳 200 但内容为空。断点就是这条跳转规则没有保留查询参数。修复动作是让跳转保留原始参数，然后重新走同一条路径验证目标页是否恢复内容。这个例子只用于说明比较方法，不代表任何真实站点。
什么时候逐跳定位会失效
如果同一路径在无痕窗口、未登录状态或另一网络环境下完全正常，断点就不在链接或跳转规则上，而在前端条件渲染、权限校验或地域限制。此时逐跳抓取会得到“一切正常”的结论，继续按链接问题修复只会浪费时间。正确做法是先固定变量：用相同登录态、相同设备、相同网络复现，再对比差异出现在哪一层。
下一步动作与验证方式
确认断点类型后，只改对应那一环，然后重走同一条路径并再次逐跳记录，确认状态码和最终内容都符合预期。若修复后深层链接恢复但入口页出现新的异常，说明改动影响了上游模板，需要回退并缩小改动范围。不要用 robots.txt 限制抓取来“隐藏”失效链接，抓取限制不等于可靠的索引移除；也不要因为提交了站点地图就假定深层页会被收录。修复完成后，观察该路径的抓取与请求变化只是参考信号，请求量归零也可能由抓取预算调整、路径合并或访问控制引起，不能单独作为处理正确的证据。下一步应把验证范围从单条路径扩展到同一模板生成的一组链接，确认断点是否已被整体消除。
