死链扫描工具：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /33e822884d0a.html
📄
死链扫描工具：入口页面正常但深层链路失效时怎样定位断点
当入口页面返回正常、扫描首页也看不到问题时，断点通常不在入口本身，而在“入口到深层页”的中间跳转或深层页自身的响应上。判断方法不是继续加大扫描深度，而是先把深层链接按来源分组，再用单条请求逐跳验证，直到找到第一个返回异常状态码或异常内容的环节。
先区分两种失效条件，再决定扫描策略
深层链路失效至少有两种成因，对应不同的处理顺序。
- 条件一：中间跳转失效。入口页里的链接指向一个跳转地址或中间层，跳转目标已下线或跳转链断裂。此时入口页本身正常，深层页也正常，坏的是中间那一跳。
- 条件二：深层页自身失效。链接路径没有中间层，入口页直接指向深层页，但深层页已删除、改名或返回错误状态。
区分依据很直接：把入口页里指向深层页的链接原样取出，逐条请求，记录每一跳的状态码和最终落地地址。如果某条链接在中间跳转处就返回异常，属于条件一；如果每一跳都正常、只有最终地址异常，属于条件二。两种条件的修复对象不同，前者改跳转配置或中间层，后者改目标页或链接本身。
用分组抽样代替全量深扫
全量深扫在深层链路失效时往往给出大量重复告警，因为同一个失效中间层会被不同入口反复引用。更有效的做法是按链接来源分组：同一模板、同一栏目、同一跳转规则下的深层链接归为一组，每组抽若干条验证。
实施动作：先导出扫描结果中“入口正常、深层异常”的链接，按路径前缀或跳转参数聚类；对每一类取少量样本逐跳请求；确认某一类整体失效后，再回到该类全部链接批量处理。这样做的结果是把问题从“几千条死链”收敛到“几条跳转规则”，下一步的修复范围也随之明确。
例外情况：如果深层链接由用户生成内容或第三方接口动态拼出，分组可能不成立，此时应改为按生成时间或参数模式抽样，而不是按路径前缀。
逐跳验证时重点看什么
逐跳验证不是只看最终状态码。需要记录三项：每一跳的响应状态、跳转目标地址、以及最终页面是否包含预期内容。常见误判是中间跳转返回 200 但落地页已是无关内容，这类“软失效”不会被状态码扫描捕获。
如果逐跳结果显示中间跳转正常、最终页返回 404 或 410，断点在目标页，处理方向是恢复页面或更新链接。如果中间跳转直接返回 3xx 指向一个已失效地址，断点在跳转配置。如果中间跳转返回 5xx，则先排查服务端而非链接本身。
一个假设例子：某深层链接经两次跳转后落地，第一跳 301 正常，第二跳 302 指向一个已删除页面并最终返回 404。此时断点在第二跳的目标配置，而不是入口页或最终页。按这个结论去改跳转规则，比逐条替换深层链接更省事。
修复后如何确认断点真的被消除
修复后不要只重跑一次全量扫描就收工。应针对之前定位到的那一组链接重跑逐跳验证，确认每一跳状态和最终内容都符合预期。如果该组链接数量大，先验证样本，样本通过后再批量复扫。
需要注意：复扫结果正常不等于所有同类问题都已解决，可能只是抽样未覆盖到的分支仍存在。若复扫后仍有零星异常，回到分组步骤，检查是否有未归入任何一组的链接。这一步决定后续是收尾还是继续排查。
容易把断点判断带偏的几种情况
robots.txt 的抓取限制不等于可靠的索引移除，扫描工具报出的“不可访问”有时是抓取限制造成的，而非链接真的失效，需要先排除这一层再判断断点。站点地图不保证收录，深层链路失效也不能仅凭站点地图里仍列着该地址就认定它可用。HTTPS 不保证安全无漏洞或排名，逐跳验证时不要因为协议正常就跳过内容核对。
另外，请求量或某项统计归零不能单独证明断点已修复，也可能是扫描范围缩小、抓取被限或缓存命中造成的。要结合逐跳记录和最终内容一起判断，而不是只看一个总数。
