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

死链检查方法 - 日志中应该核对哪些字段

用服务器日志做死链检查，核心是核对五个字段：请求时间、请求方法、请求URL、HTTP状态码、来源页URL（Referer）。其中状态码决定“是不是死链”，URL决定“哪条链接坏了”，Referer决定“坏链出现在哪个页面”，时间和请求方法用于排除误报。缺了Referer，你只能知道死链被访问过，却找不到该去哪个页面修链接。

字段清单与各自作用

• 请求时间：判断死链是历史遗留还是近期新增。若某URL的状态码从某天起由200变为404，说明是那次改版或删除导致的。
• 请求方法：只看GET和HEAD。POST请求返回404通常来自表单或接口调用，不属于可点击死链，应单独归类。
• 请求URL（含查询串）：定位具体坏链。同一路径带不同参数可能返回不同状态码，去掉查询串会漏判。
• HTTP状态码：404、410是明确死链；301、302、307是跳转，要看跳转目标是否有效；5xx是服务器错误，不能当死链处理；200但内容是错误页的软404，需结合页面内容判断。
• 来源页URL（Referer）：找到坏链所在页面。Referer为空时，可能来自直接输入、外部应用或隐私策略屏蔽，不能直接判定为站内死链。

从交付结果倒推：修好一条死链需要什么

假设目标是“把站内所有指向已删除页面的链接改成新地址或移除”，那么日志至少要能回答三个问题：坏链目标是什么、它出现在哪个页面、出现频率多高。对应到字段就是请求URL、Referer和访问次数。只有状态码和URL，你无法确定修改位置；只有Referer没有状态码，你无法区分死链和正常跳转。因此核对字段的顺序应当是：先按状态码筛出4xx，再按Referer分组，最后按URL去重并统计频次。

两种处理方案的适用条件

拿到日志字段后，常见两种处理路径：

1. 逐条修复来源页链接：适用于死链数量少、来源页集中、且目标内容仍有等价新地址的情况。判断依据是Referer能明确指向站内页面，且该页面仍可编辑。
2. 在服务器层做301跳转：适用于死链URL数量大、来源页分散或无法逐一改稿的情况。判断依据是旧URL有明确的新对应地址，且跳转规则可以用路径前缀批量匹配。若旧URL没有合理目标，应返回410而不是跳到首页，后者属于软404，对用户和抓取都不利。

选择哪一种，不看工作量偏好，而看Referer是否可编辑、旧URL是否有等价新地址这两个条件。两者都不满足时，优先移除来源页上的链接，而不是制造无意义跳转。

核对时的检查项与常见误判

• 先确认日志是否经过CDN或反向代理。若日志记录的是代理层状态码，可能与源站实际返回不同，需要以源站日志或直接请求结果复核。
• 区分“已经定位的死链”和“可能的原因”。某URL返回404，可能是页面被删除，也可能是大小写不匹配、尾部斜杠差异、参数缺失，需实际请求一次确认。
• robots.txt 的抓取限制不等于索引移除，日志里看不到某URL被访问，不代表它已被搜索引擎删除。
• 站点地图不保证收录，日志中没有来自站点地图的抓取记录，不能反推死链已处理完毕。
• 5xx错误应归入服务器稳定性问题，不要混进死链清单，否则修复方向会错。

一个可执行的短例子（假设数据）：日志中 /old-page 返回404，Referer为 /blog/post-1，请求方法为GET，共出现37次。这说明 /blog/post-1 上有一处链接指向已不存在的 /old-page。若 /new-page 内容等价，可改链接或做301；若不等价，直接移除该链接。

下一步：从日志中导出最近30天内所有4xx记录，按Referer分组统计，先处理来源页为站内且出现次数最高的前若干条，再决定剩余部分是改链还是做跳转。