📍 WDQWDWQD987AAAAA:216.73.216.104
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /044cec281012.html
📄

死链扫描工具：怎样判断问题属于哪一层

用死链扫描工具拿到一批异常 URL 后，判断问题属于哪一层，关键不是看“报错数量”，而是先确认错误发生在哪一环：是链接本身写错，是服务器返回了错误状态，是页面被 robots.txt 或登录墙挡住，还是扫描器根本没抓到真实页面。把这几层分开，才能把修复任务交给正确的人，避免前端、运维、编辑互相返工。

第一层：先确认扫描器看到的是不是真实响应

要查的是扫描器访问目标 URL 时实际收到的 HTTP 状态码和响应头，而不是只看工具面板里的“失效”标签。

• 查什么：单个异常 URL 的完整状态码、重定向链、响应头里的 Content-Type 和 Location。
• 怎么查：从扫描结果里挑 3 到 5 个不同类型异常项，用命令行 curl -I 或浏览器开发者工具的 Network 面板手动访问一次，和扫描器结果对照。
• 结果说明什么：如果手动访问返回 200，而扫描器报 404，可能是扫描器被 CDN、WAF、频率限制或登录态影响，问题属于“扫描环境层”，不是站点内容层。

适用条件：站点有 CDN、防爬策略或需要登录才能访问的页面时，这一步必须做。判断结果是扫描器不可信，还是站点真的坏了，直接影响后续修复对象。

第二层：区分 404、410、5xx 和超时

死链扫描工具常把多种异常混在一个列表里，但它们的责任层不同。

• 404 或 410：通常说明目标资源不存在，问题属于内容层或链接维护层。要查的是这个 URL 是否曾经存在、是否被误删、内链或外链是否写错。
• 5xx：说明服务器端处理失败，问题属于服务层。要查的是应用日志、数据库连接、上游接口，而不是去改页面里的链接。
• 超时：可能是目标服务器慢，也可能是扫描器并发过高。要先用单线程、低频率复测一次，再判断是对方站点问题还是扫描配置问题。

假设一个例子：扫描结果里同一域名下 20 个 URL 同时报 503，而其他域名正常。这更像目标站点服务层故障，不应逐个去改链接。反过来，如果只有某个栏目下的旧文章报 404，而首页和栏目页正常，问题更可能在内容迁移或链接维护层。

第三层：检查 robots.txt、站点地图和登录墙是否干扰判断

要查的是扫描器是否被规则允许抓取目标路径。

• 查什么：目标 URL 是否被 robots.txt 的 Disallow 规则覆盖，是否需要登录或特定 Cookie 才能访问。
• 怎么查：直接打开站点的 /robots.txt，用路径匹配规则核对；再用无登录态浏览器访问一次异常 URL。
• 结果说明什么：如果扫描器被 robots.txt 挡住，它可能把“未抓取”误报为“失效”。这时问题属于抓取权限层，不是死链层。

需要分清：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。它们只能帮助你判断扫描器为什么没拿到内容，不能直接当成死链修复依据。

第四层：判断是单点错误还是模板或规则错误

要查的是异常 URL 的分布规律。

• 查什么：异常 URL 是否集中在同一路径前缀、同一参数、同一分页规则或同一 CMS 模板下。
• 怎么查：把扫描结果按路径前缀和状态码分组，统计每组数量，再抽 2 到 3 个样本手动访问。
• 结果说明什么：如果同一模板生成的页面大量报错，问题属于模板层或规则层，应改生成逻辑；如果只是零散旧链接，问题属于内容维护层，逐个替换或跳转即可。

多人协作时，这一层决定工单该开给谁：模板问题交给开发，内容链接问题交给编辑，服务器 5xx 交给运维。交付时附上分组依据和复测样本，能显著减少返工。

可执行检查清单

1. 从死链扫描工具导出异常 URL 列表，按状态码分组。
2. 每组抽 3 个样本，用 curl -I 或浏览器 Network 面板手动复测，记录真实状态码和重定向链。
3. 核对 robots.txt 和登录要求，排除扫描器被拦截造成的误报。
4. 按路径前缀和模板分组，判断是单点问题还是批量规则问题。
5. 把确认后的层级、样本证据和负责角色写进交付说明，再进入修复。

下一步：拿你最近一次扫描结果，先完成第 1 到第 3 步，把“扫描器误报”和“真实死链”分开，再决定修复工单开给谁。