网站死链检测，日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d2cb4e09eee8.html
📄
网站死链检测，日志中应该核对哪些字段
做网站死链检测时，日志里最该核对的是状态码、请求URL、来源页、User-Agent、请求时间这五个字段。它们能回答三个问题：哪个链接坏了、是谁在请求它、它是否值得优先修复。只看状态码会漏掉大量误判，只看URL又无法判断影响范围。
先分清两类日志，字段含义不同
服务器访问日志和爬虫日志记录的内容不一样。服务器日志通常包含客户端IP、时间、请求方法、URL、状态码、响应大小、来源页、User-Agent；爬虫日志则由搜索引擎或第三方工具提供，字段更少，但会标注抓取频次和抓取结果。做死链检测时，两者要分开核对，不能混在一张表里比较。
适用条件：如果你能拿到原始服务器日志，优先用它，因为404、410、301、302都会如实记录；如果只有爬虫日志，就要接受它只覆盖被爬取过的URL，未收录页面不会出现。
状态码字段：区分真死链和临时故障
状态码是死链检测的第一判断依据，但不能只看一个数字。
404：页面不存在。若同一URL连续多天出现404，基本可判定为死链。410：页面已永久删除。比404更明确，修复优先级通常更高。301/302：跳转。301是永久跳转，302是临时跳转。若跳转目标本身返回404，链路上仍然存在死链。500/502/503：服务器错误，属于临时故障，不能直接当死链处理，应先观察是否恢复。
判断方法：把状态码按URL分组，统计每个URL在最近7天或30天内出现404/410的次数。只出现一次404的，可能是爬虫误抓或临时问题；持续出现的，才进入修复清单。
请求URL与来源页：定位死链位置
请求URL告诉你坏的是哪个地址，来源页告诉你用户或爬虫是从哪里点到它的。两者必须一起看。
假设日志中出现：
请求URL: /old-page.html 状态码: 404 来源页: /blog/post-1.html
这说明/blog/post-1.html里有一个指向/old-page.html的链接已经失效。修复时要么更新来源页的链接，要么给旧URL设置301跳转到新页面。
检查项：来源页为空时，说明请求可能来自外部链接、直接输入或爬虫首次发现，不能只改站内链接。来源页是站内页面的，优先修复，因为影响可控且能直接验证。
User-Agent与请求时间：判断影响范围
User-Agent能区分请求来自普通用户、搜索引擎爬虫还是监控工具。不同来源的处理优先级不同：
- 搜索引擎爬虫频繁抓到404：可能影响抓取效率，应尽快处理。
- 普通用户点击到404：直接影响体验，优先修复来源页链接。
- 监控工具或安全扫描产生的404：可先忽略，避免误报。
请求时间用于判断死链是长期存在还是刚刚出现。把时间字段与状态码交叉比对：如果某个URL从某天开始突然大量404，可能是改版、删除页面或配置错误导致，需要结合当时的发布记录核查。
两种处理方案的适用条件
核对完字段后，通常有两种处理方式：
- 修复来源链接：适用于来源页仍在、只是链接写错或指向了已删除页面。做法是更新来源页的<a>标签地址。验收信号：再次抓取来源页时，该链接不再返回404。
- 设置301跳转：适用于旧URL有外部链接或已有流量，且站内有内容相近的新页面。做法是把旧URL永久跳转到新URL。验收信号：请求旧URL返回301，且跳转目标返回200。
如果旧URL没有任何外部链接和访问量，也可以保留404，不必强行跳转。判断依据是日志中该URL的请求次数和来源页分布，而不是凭感觉决定。
下一步：从日志中导出最近30天状态码为404和410的URL，按请求次数从高到低排序，先处理来源页为站内页面且请求次数最多的那批。
