死链检测_日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /459be16bdeef.html
📄
死链检测_日志中应该核对哪些字段
做死链检测时，日志里最该先核对的是状态码、请求URL、来源页URL（Referer）、User-Agent、请求时间和响应大小。只盯着状态码统计“404有多少”往往不够，因为同一个404可能来自真实用户点击、搜索引擎抓取或外部引用，处理优先级完全不同。时间和人手有限时，先用状态码筛出可疑请求，再用来源页和User-Agent判断它值不值得优先修。
常见误解：404数量多就等于死链问题严重
日志里出现大量404，并不直接说明站内有大量坏链接。常见来源包括：被删页面仍被外部引用、扫描器随机探测不存在的路径、页面模板拼出错误参数、旧链接被搜索引擎反复抓取。这些情形的修复动作差别很大：外部引用只能通过跳转或联系对方处理，扫描器探测通常可以忽略，模板问题则必须改代码。
因此，死链检测的日志核对不是“数404”，而是把每条404还原成“谁在什么场景下请求了它”。判断依据就是下面几个字段的组合。
必须核对的字段与各自作用
状态码：区分404、410、301、302、500。404和410才是死链候选；301/302是跳转，需要确认跳转目标是否有效；5xx是服务器故障，不属于死链但会连带产生抓取失败。请求URL：完整路径加查询参数。很多“死链”其实是参数拼错或大小写不一致，去掉参数后同一路径可能正常。来源页URL（Referer）：判断死链是站内链出去的还是外部引用。站内来源优先修，因为影响可控且直接损害用户体验。User-Agent：区分搜索引擎爬虫、普通浏览器、监控或扫描工具。爬虫频繁抓取的404优先级高于一次性扫描请求。请求时间：看请求是持续出现还是集中在某一时段。持续出现说明链接仍在被引用，一次性高峰更可能是扫描。响应大小：辅助判断返回的是标准404页还是被软404（返回200但内容是错误页）覆盖，后者需要单独排查。
按优先级处理的判断方法
把日志按请求URL聚合，统计每个死链的出现次数，再按下面的条件排序：
- 站内来源 + 高频 + 搜索引擎爬虫：最先处理。说明站内仍有链接指向它，且被抓取，直接影响收录与用户体验。
- 站内来源 + 低频：次优先。可能藏在旧文章或分页里，修起来成本低。
- 外部来源 + 高频：考虑做301到最相关的新页面，而不是直接返回404。
- 无来源或仅扫描器：可暂时忽略，除非它对应曾经的重要页面。
举例（假设数据）：某路径在一天内出现300次404，Referer全部为空，User-Agent是某扫描工具，这类请求不需要安排人力。若同一路径出现50次404，Referer来自站内文章页，User-Agent包含常见搜索引擎爬虫标识，就应排进当天任务。
执行时的检查项与注意点
动手前先确认日志字段是否完整。缺少Referer时，站内死链和外部引用无法区分，只能先按请求URL和User-Agent粗排。缺少User-Agent时，无法判断爬虫行为，优先级只能靠出现频率估计。
另外要分清边界：robots.txt的抓取限制不等于可靠的索引移除，屏蔽抓取并不会让已收录的死链消失；站点地图不保证收录；返回410比404在语义上更明确，但不同搜索引擎的处理方式需要分别核查，不能假定效果一致。
如果日志量太大，先按状态码过滤出404和410，再按请求URL去重计数，最后人工核对排名靠前的几十条即可，不必逐条处理全部记录。
下一步：从日志中导出最近7天的404与410记录，按请求URL聚合计数，并补上Referer和User-Agent两列，先处理“站内来源且被爬虫抓取”的那一批。
