测试死链接：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /31c19840bac6.html
📄
测试死链接：日志中应该核对哪些字段
测试死链接时，日志里最先要核对的是请求URL、HTTP状态码、来源页URL、请求时间、User-Agent、响应耗时这六类字段。它们能帮你区分“链接真的坏了”和“只是某次抓取异常”，也能决定先修哪一批。时间和人手有限时，优先看状态码为404、410、5xx，并且来源页有真实流量的记录。
准备：先确认日志能回答什么
打开服务器访问日志或CDN日志，先确认字段是否齐全。常见格式里，一行通常包含客户端IP、时间、请求方法、请求URL、状态码、响应大小、Referer、User-Agent。不同服务器默认格式不同，缺字段时不要凭猜测补，先看日志配置。
需要重点确认的字段含义：
请求URL：被访问的地址，判断死链接的直接对象。HTTP状态码：404/410表示资源不可用，5xx表示服务端异常，301/302表示跳转，不能一律当死链接。Referer：来源页，决定这个死链接是否值得优先修。为空时可能是直接访问、隐私设置或站内跳转丢失。时间：判断问题是长期存在还是某次改版后出现。User-Agent：区分真实用户、搜索引擎抓取工具和监控脚本。响应耗时：5xx或超时往往和性能、后端故障相关，不只是链接写错。
实施：按优先级筛选要处理的记录
不要从第一条日志开始逐行看。先按状态码分组，再按来源页和访问次数排序。一个可执行的筛选顺序是：
- 筛出状态码为404和410的请求URL，按出现次数降序。
- 保留Referer非空且来源页属于本站的记录，这些是站内死链接的主要线索。
- 单独筛出5xx和超时记录，交给服务端排查，不要和404混在一起改链接。
- 对301/302记录，核对跳转目标是否可达；跳转链过长或目标返回404，同样要处理。
假设某条日志显示：来源页是文章A，请求URL是旧活动页，状态码404，一周出现200次。这属于优先修复项。若另一条404的Referer为空、User-Agent是扫描脚本、只出现1次，可以放到后面。
验证：修完后用日志确认结果
修改链接或配置跳转后，不要只看页面表面。回到日志中核对三项：
- 原请求URL是否还持续出现404；如果仍出现，说明站内还有别处引用，或跳转未生效。
- 来源页是否改为指向新URL，状态码变为200或合理的301。
- 5xx记录是否下降；若没有，问题可能在后端而不是链接本身。
这里要区分“可能原因”和“已经定位的原因”。日志只能证明某次请求返回了某个状态码，不能单独证明是拼写错误、文件被删还是权限配置导致。需要结合来源页内容、服务器配置和实际访问再判断。
维护：把核对字段固化成例行检查
时间和人手有限时，维护阶段只做最小闭环：每周导出一次404和5xx记录，按来源页流量排序，处理前20条；每月检查一次站内主要导航和文章正文的外链。robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以日志核对仍要独立进行。
如果使用第三方死链接检测工具，把它当作补充，不要替代日志。工具可能只抓取部分页面，也可能受登录、反爬或JavaScript渲染影响。判断依据仍是服务器日志中的真实请求和状态码。
下一步：从最近7天日志中导出状态码为404、Referer非空且来源页有访问量的记录，按请求次数排序，先处理前10条。
