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

站长死链查询 - 日志中应该核对哪些字段

做站长死链查询时，日志里最该先核对的是五类字段：请求时间、请求方法、请求URL（含查询串）、HTTP状态码、来源页Referer，再补上User-Agent和响应字节数。其中状态码决定这条记录是不是死链候选，URL决定死链指向哪里，Referer决定它是否来自站内链接，三者缺一不可。只看状态码会漏掉软404，只看URL会误判正常跳转。

先分清哪些字段能证明“链是死的”

日志本身不直接告诉你链接坏了，它只记录一次请求的结果。判断死链，需要把字段组合起来看：

• 状态码：404、410是明确的死链信号；301、302是跳转，要顺着Location字段继续跟；200不一定正常，可能是软404页面。
• 请求URL：要保留完整路径和查询参数，?id=123这类参数去掉后可能指向另一个页面，误判会直接导致改错链接。
• Referer：为空说明可能是外部直接访问或爬虫首次抓取；有站内域名说明这条死链正被自己站内的某个页面引用，这才是优先修复对象。
• User-Agent：区分搜索引擎爬虫和真实用户。爬虫反复命中404，说明死链已进入抓取路径；只有用户命中，说明影响面暂时限于访问者。
• 响应字节数：404页面若返回完整模板，字节数会接近正常页，这时单看状态码容易误判，需要结合页面内容确认。

核对顺序：从状态码筛到Referer定位

假设你导出了一天的访问日志，按下面的顺序过一遍：

1. 筛出状态码为404和410的记录，这是死链候选集。
2. 在候选集里按请求URL去重并统计次数，次数高的先处理。
3. 看Referer字段：站内来源的URL就是需要改链接的页面；站外来源的说明是别人链过来的旧地址，处理方式不同。
4. 对301、302记录单独拉一份，检查Location指向的目标是否也返回404，跳转链断裂同样算死链。
5. 抽查若干条200记录，确认返回的页面主体是否包含“不存在”“已删除”等文案，排除软404。

适用条件：日志需包含状态码和Referer字段，部分CDN或反向代理默认不记录Referer，需要先在服务端或CDN配置里打开。如果日志只有URL和时间，这份核对只能做到候选筛选，无法定位引用来源。

一个可执行的小例子

假设日志中有这样一条记录（示例为假设数据）：

2024-06-01T10:22:31 /old/page.html?id=8 404 referer=https://example.com/list/ UA=Googlebot

判断结果：这是一条来自站内列表页、被爬虫抓取到的死链。下一步应打开/list/页面，找到指向/old/page.html?id=8的链接，改成新地址或删除。验收信号是：修改后重新抓取该页面，日志中该URL不再出现404，或出现301指向有效页面。

容易误判的几种情况与检查项

• 带参数的URL：同一路径不同参数可能一个200一个404，核对时不要合并统计。
• 大小写差异：/Page.html和/page.html在部分服务器上是两个资源，日志里要按原样比对。
• 爬虫高频命中：同一URL短时间内大量404，可能是爬虫在重试，先确认是否已在robots.txt中限制，但robots.txt的限制不等于索引移除，仍需用状态码处理。
• 跳转链：301指向的地址若返回404，需要在日志中把两条记录连起来看，不能只处理第一条。
• 软404：状态码200但内容为空或提示不存在，需结合响应字节数和页面模板判断。

下一步：把筛出的站内Referer列表导出，逐条打开来源页面，用编辑器的查找功能定位旧链接，替换为新地址后再观察一轮日志，确认对应URL的404记录消失或转为301。