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

死链接检测工具日志中应该核对哪些字段

用死链接检测工具排查时，日志里最该先核对的是请求URL、HTTP状态码、来源页面、发现时间、User-Agent、请求方法这六类字段。它们能回答“哪个链接坏了、坏成什么样、从哪发现的、谁发现的、是否值得修”。如果日志里只有一条“404”，没有来源页和完整URL，协作时就容易出现“你说是这个页面，我查的是另一个页面”的返工。

适用前提是：你拿到的是一份可导出的检测日志或服务器访问日志，而不是工具界面上的一行摘要。下面按排查顺序说明每个字段的作用。

请求URL与状态码：先分清“真死链”和“误报”

请求URL要核对完整路径，包括协议、主机名、路径、查询字符串。很多返工来自只看了路径而漏掉参数，例如 /product?id=12 和 /product?id=13 在摘要里可能只显示成同一个页面名。

HTTP状态码要区分几类结果：

• 404、410：目标资源不存在或已删除，通常需要处理。
• 301、302：是跳转，不等于死链，但要核对跳转终点是否有效。
• 403、401：可能是权限或反爬拦截，不一定是链接本身失效。
• 500、502、503：属于服务端或网关问题，可能是临时故障，不能直接判定为死链。
• 超时、连接重置：需要复测，单次结果不足以定论。

判断逻辑是：先按状态码分组，再对同一URL做二次请求。如果第二次返回200，说明第一次可能是瞬时故障；如果稳定返回404，才进入修复流程。

来源页面与链接文本：决定修复优先级

来源页面是发现该链接的页面URL，链接文本是锚文本。这两个字段直接影响修复方式：

• 来源页是首页或高流量栏目页，优先级应高于深层旧文章。
• 锚文本如果是“点击这里”这类无描述文本，修复时顺带改成有意义的描述。
• 同一坏链出现在多个来源页时，日志里应能按请求URL聚合，避免逐条重复处理。

验收信号是：每条待修记录都能回答“改哪个页面里的哪个链接”。如果日志无法定位到来源页，就只能猜，协作成本会明显上升。

发现时间、User-Agent与请求方法：判断结果可信度

发现时间用于判断问题新旧。若同一URL在近期多次检测中持续报错，可信度高于只出现一次的记录。

User-Agent要核对检测工具使用的标识。有些站点会对特定UA返回不同结果，例如对普通浏览器返回200，对脚本请求返回403。这不代表真实用户遇到死链，需要换UA复测。不同搜索引擎的抓取工具支持情况要分别核查，不能拿一个UA的结果推断全部。

请求方法通常是GET或HEAD。部分服务器对HEAD支持不完整，可能返回异常状态，而GET正常。遇到这种差异时，应以GET结果为准，并在日志中标注检测方法。

一份可执行的核对清单

拿到日志后，按以下步骤操作：

1. 筛选出状态码为404和410的记录，单独成表。
2. 按请求URL去重，合并同一URL的多条来源记录。
3. 对每条记录补上来源页面和链接文本，缺失的标为“待确认”。
4. 对403、500、超时记录做二次请求，仍失败再转入待修。
5. 按来源页面的重要程度排序，输出修复清单。

验收信号是：清单里每条记录都有完整URL、状态码、来源页、复测结果和负责人。满足这些条件，协作交付时就不需要反复解释“这个链接到底在哪”。

下一步可以直接用同一份日志模板，把状态码分组规则和复测要求固定下来，让每次检测输出格式一致。