测试死链接：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28e2a4813fa7.html
📄
测试死链接：入口页面正常但深层链路失效时怎样定位断点
先给结论：入口页面正常、深层链路失效，通常不是死链接工具本身的问题，而是断点发生在入口页可访问的路径之外——常见于导航未覆盖的层级、JS 渲染后才生成的链接、登录或参数化 URL，以及被 robots.txt 或反爬策略拦截的深层请求。定位方法是把“整站扫描”换成“沿一条真实用户路径逐跳验证”，直到找到第一个返回非预期状态的请求。
为什么入口正常会掩盖深层断点
入口页面（首页、栏目页）通常是爬虫抓取优先级最高、缓存最全、链接最密集的部分，它正常只能说明这一层可达。深层页面往往依赖三种入口之外的条件：
- 链接由 JavaScript 在交互后注入，静态 HTML 里根本没有
<a href>； - URL 需要会话、地域、语言或筛选参数才返回 200，裸链返回 404 或 302；
- 深层目录被 robots.txt 的 Disallow 挡住，工具报告“失效”其实是“未抓取”。
这三种原因的排查动作完全不同，所以第一步不是修链接，而是先判断断点属于哪一类。
沿一条真实路径逐跳验证，而不是整站扫描
选一个你确认真实存在、用户会走到的深层页面，例如某篇文章或某个商品详情页。从入口开始，手动记录每一跳的请求与响应：
- 打开入口页，用浏览器开发者工具的 Network 面板勾选保留日志；
- 点击进入下一层，观察这一跳返回的状态码是 200、301、302 还是 404；
- 继续点击到目标深层页，记录第一个状态码异常的那一跳。
这个动作的结果直接决定下一步：如果异常出现在第二跳的跳转链上，问题在重定向规则；如果每一跳都 200 但目标页内容为空，问题在渲染或数据接口；如果手动能打开、工具报 404，则先怀疑抓取拦截而非链接本身。
用可区分原因的证据排除误判
工具报“死链接”不等于链接真的失效。以下证据能把几类原因分开：
- 手动访问返回 200，工具返回 404/403：多为 UA 或 IP 被拦，检查服务器日志里该请求的响应码。
- 手动访问也 404，但站内搜索能找到该内容：URL 规则变更，旧链未做 301，属于真实断点。
- cURL 拿到 200，浏览器渲染后链接为空：链接由 JS 生成，需检查渲染后的 DOM 或数据接口。
- 状态码 200 但内容为“未找到”提示：软 404，工具不会标记，需比对页面标题或正文字段。
注意：robots.txt 的抓取限制不等于可靠的索引移除，也不代表链接失效；站点地图不保证收录；HTTPS 不保证页面无漏洞或排名更好。这些都不能作为“深层链路正常”的证据。不同搜索引擎对 JS 渲染和参数 URL 的支持情况须分别核查，不能用一个引擎的结果推断另一个。
一个假设例子：定位参数化深层页的断点
假设某栏目页返回 200，其下带筛选参数的列表页在工具里全部报 404。手动打开不带参数的列表页正常，带参数则 404。此时可做一次对照：
- 请求
/list?page=2，记录状态码； - 请求
/list?page=2&sort=new，记录状态码； - 对比两次响应头与服务器日志中的路由匹配记录。
如果只有多参数组合 404，说明路由或重写规则未覆盖该组合，断点在服务端规则而非链接本身。修复对象应是路由配置，而不是逐个替换页面上的链接。这个判断会改变后续动作：前者改规则一次生效，后者要改内容里的每一条 URL。
把结论落到一个可复查的断点清单
定位完成后，输出一份最小清单，包含：断点 URL、该跳的请求方式、实际状态码、与预期状态的差异、以及判定为真实失效还是抓取拦截的依据。清单里只保留你亲手验证过的那条路径，不堆整站导出结果。这样交接给开发或运维时，对方能直接复现，而不必重新从入口猜起。
下一步动作取决于清单结论：判定为真实失效的，按 URL 规则统一处理跳转或修正链接；判定为抓取拦截的，先调整抓取条件再重新测试，避免在错误结论上改动线上链接。
