死链测试工具，入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1f935014459f.html
📄
死链测试工具，入口页面正常但深层链路失效时怎样定位断点
先给结论：当入口页面返回正常、深层链接却失效时，优先用“逐层缩小”而不是“全站重扫”。全站重扫能告诉你坏链总量，却很难指出断点在哪一层；逐层缩小则用少量请求换来确定性。前提是你能拿到站内链接的父子层级或路径规律，并且目标页面的响应状态可稳定复现。
两种做法各自成立的条件
第一种做法是沿导航层级逐层抓取：从入口开始，只抓下一层链接，确认该层全部可访问后再进入再下一层。它成立的条件是层级清晰、每层链接数量可控。代价是请求次数随层数增长，遇到分页或筛选参数多的目录会迅速膨胀。
第二种做法是按路径规律抽样：把失效的深层 URL 归成模板，例如同一目录下的详情页、同一参数结构的列表页，每类抽若干条验证。它成立的条件是失效具有模板共性。代价是当断点只出现在个别分支时，抽样会漏掉它。
选择依据可以简化为一句：失效是否沿某一层集中出现。如果同一层大量失效，逐层缩小更快；如果只有零散深层失效，模板抽样更省成本。两者不是互斥，常见顺序是先抽样判断是否有共性，再对有问题的分支逐层下探。
哪些证据能区分断点位置
把结果按三类信号分开看，比只看“是否 404”更有用。
- 状态码：同一层集中返回 404，通常指向该层生成规则或链接拼接；返回 403 或 429，则更可能是访问控制或请求频率导致，而非链接本身消失。
- 响应内容：状态码正常但页面是空壳或错误提示，说明断点在渲染或数据获取环节，而不是路由。
- 跳转链：入口正常、深层经过多次 301 后落到失效地址，断点在跳转规则而非目标页。
一个假设例子：某目录页正常，其下详情页全部 404。逐层抓取会先确认目录层正常，再把范围压到详情层；此时检查详情链接的生成模板，若模板中混入了已变更的路径前缀，就能定位到断点。这个例子只说明比较方法，不代表任何真实站点的结果。
会让结论失效的反例
逐层缩小并非总是可靠。若站点对同一 URL 的响应随会话、地域或时间变化，同一层可能这次正常、下次失效，此时“某层集中失效”的判断不成立，需要先固定请求条件再复测。另一种反例是入口页面本身由缓存提供，深层走的是实时渲染，两者响应机制不同，入口正常不能作为深层正常的参照。
还要注意，抓取限制不等于索引移除，站点地图存在也不保证收录。若深层失效同时伴随抓取量下降，不能直接断定是死链导致，也可能是抓取预算分配、robots 规则或站点结构调整的结果。请求量或抓取量归零本身不足以证明处理正确。
下一步动作与结果判断
确定断点层后，先修该层的链接生成或跳转规则，再对同层做一次小范围复测，而不是立刻全站重扫。复测通过则把范围扩大到相邻层；复测仍失败，说明断点在更上游，需要回到上一层继续缩小。若修复涉及 HTTPS 或跳转配置，仍要单独核查各搜索引擎的支持与处理差异，不能默认一次修改对所有入口等效。
