死链检查:日志中应该核对哪些字段?先从状态码和来源页看起

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

死链检查:日志中应该核对哪些字段?先从状态码和来源页看起

做死链检查时,日志里最该先核对的是请求状态码、请求URL、来源页(Referer)、User-Agent、请求时间这几类字段。它们能回答三个问题:哪些链接真的失效了、用户或爬虫从哪里点进来的、这个问题是偶发还是持续存在。只看状态码列表容易误判,因为404不一定代表死链,200也不一定代表页面可用。

先确认日志格式,再决定字段怎么读

不同服务器和CDN输出的字段顺序不一样。常见的有 Nginx/Apache 的 combined 格式、JSON 格式,以及各类 CDN 的访问日志。第一步不是急着筛404,而是先确认每一列或每个键代表什么。

文本格式通常按空格分隔,URL和Referer里可能带空格或编码字符,直接按空格切分容易出错。JSON日志更稳妥,可以按status、request_uri、http_referer这类键取值。技术示例中提到的标签名要按原文理解,不要把它当成页面结构判断依据。

状态码:区分真死链和假死链

状态码是死链检查的核心字段,但不能只看一个数字。

判断方法:把同一URL的状态码按时间排序,看它是持续404还是偶发。持续404才更可能是真死链;偶发404可能是发布过程中的短暂状态。

URL与来源页:找到死链的入口

只统计哪些URL返回404还不够,还要知道用户和爬虫是从哪里点到它的。这就是来源页字段的价值。

注意查询参数。同一个路径带不同参数可能返回不同结果,去重时不能只取路径部分,否则会漏掉参数导致的失效。同时,来源页为空不代表没有入口,可能是用户直接输入、来自App、或隐私策略屏蔽了Referer。

User-Agent与时间:判断影响范围和趋势

User-Agent 能区分请求来自搜索引擎爬虫、普通浏览器还是监控工具。这对死链检查很关键,因为不同来源的处理优先级不同。

这里要分清:robots.txt 的抓取限制不等于可靠的索引移除,站点地图也不保证收录。日志里看到爬虫没来抓某个URL,不能直接推断它被惩罚或移除,需要结合其他字段和实际页面状态判断。HTTPS 也不保证安全无漏洞或排名,它只是传输层的一个条件。

一份可执行的核对清单

  1. 确认日志字段顺序和格式,取一行样例对照。
  2. 筛出状态码为404、410、301、302、403、429、503的记录。
  3. 按请求URL分组,统计每个URL的出现次数和时间范围。
  4. 对每个高频404 URL,查它的来源页,判断是站内还是站外入口。
  5. 按User-Agent分组,确认主要来自爬虫还是真实用户。
  6. 对301/302记录,跟进跳转目标的状态码,排除跳转链。
  7. 对返回200但疑似软404的URL,人工打开核对页面内容。
  8. 把持续404的URL整理成待修复列表,区分需要301、需要恢复内容、还是需要删除入口。

假设某URL连续七天每天出现几十次404,来源页集中在同一篇旧文章,User-Agent以浏览器为主,那么优先修那篇文章里的链接,而不是先改服务器配置。反过来,如果404只出现在某次发布后的几分钟内,且之后消失,通常不需要处理。

下一步:从日志中导出最近七天的404记录,按请求URL和来源页做一次分组统计,先处理出现次数最高且来源页在站内的那一批。

图1 图2

nginx