死链工具，日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8aa3b7f8c2f2.html
📄
死链工具，日志中应该核对哪些字段
用死链工具排查时，日志里最该优先核对的是请求URL、响应状态码、来源页URL、User-Agent、请求时间这五个字段。它们分别回答“哪个链接坏了”“坏成什么样”“从哪被发现”“谁在访问”“什么时候发生”。缺少其中任何一个，多人协作时就容易出现“我这边看是好的”“昨天还能打开”这类返工。
观察：先确认日志字段是否齐全
拿到一份访问日志或爬虫日志后，先不要急着改链接，而是检查字段是否可用。常见日志格式里，一行通常包含时间、客户端标识、请求方法、路径、状态码、字节数、来源页和User-Agent。判断能否用于死链排查，看三点：
- 是否有完整的请求路径，而不只是域名或目录。
- 是否有状态码，且能区分 404、410、301、302、403、500。
- 是否有来源页字段，用来判断死链是从站内哪个页面被点开或抓取到的。
如果日志只记录了访问量，没有状态码和来源页，那么它只能说明“有人访问过”，无法定位死链。此时应先在采集或服务端配置中补齐字段，再交给协作成员处理。
判断：各字段分别说明什么
请求URL决定要修的是哪一个链接。注意区分大小写、结尾斜杠、查询参数和URL编码，这些差异会让看似相同的地址指向不同结果。
响应状态码决定处理方式。404 表示未找到，通常是链接写错或页面被删；410 表示已删除，适合明确不再提供的内容；301/302 是跳转，要检查跳转目标是否有效；403 可能是权限或防抓取策略；500 是服务端错误，不一定属于死链，应先修服务。
来源页URL告诉你死链出现在哪个页面、哪条导航或哪篇文章里。多人协作时，这个字段直接决定任务分给谁：内容页问题归编辑，模板问题归前端，跳转规则归运维。
User-Agent用来区分访问者类型。搜索引擎爬虫、站内检测脚本、真实用户浏览器可能得到不同响应。若只有某类爬虫收到 404，要检查是否被服务端规则误伤，而不是立刻删链接。
请求时间用于复查。链接可能已经修复，但旧日志仍显示 404；也可能刚被改动，日志尚未更新。记录时间能避免用过期数据下结论。
处理：把日志转成可交付的清单
建议把筛选后的记录整理成一张表，每行至少包含以下字段，再按状态码和来源页分组：
- 请求URL：保留原始编码形式，另加一列解码后的可读地址。
- 状态码：标出是 404、410、301、302、403 还是 5xx。
- 来源页URL：没有来源页的单独归为“直接访问或外部来源”。
- User-Agent：标注是爬虫、检测工具还是普通浏览器。
- 首次和最近出现时间：判断是长期问题还是新出现的问题。
- 处理人、处理动作、复查结果：供协作交接。
举例说明（以下为假设示例）：日志显示 /old-page 返回 404，来源页是 /guide，User-Agent 为普通浏览器，最近七天持续出现。判断结果是站内文章里的链接已失效，处理动作是把 /guide 中的链接改为新地址，复查时确认该来源页不再产生 404。若同一 URL 只被某个爬虫访问且返回 403，则更可能是服务端访问规则问题，应先核对规则，而不是改内容。
复查：确认问题真的消失
处理完成后，复查要看三项：同一请求URL是否还返回原状态码；同一来源页是否还指向旧地址；修复后的目标页是否返回 200 且内容相关。只改链接不看目标页，可能把 404 换成另一个无效跳转。
同时要区分“可能原因”和“已经定位的原因”。日志出现 404 可能是链接写错、页面被删、路由规则变化或大小写不一致；只有结合来源页、跳转记录和发布时间，才能确定是哪一种。不要因为一条日志就断言全站死链都来自同一个原因。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。用死链工具处理完日志后，下一步是把修复清单交给对应负责人，并在下一轮日志中核对同一组字段，确认状态码和来源页都已更新。
