死链检查工具：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2aaec87cc43d.html
📄
死链检查工具：日志中应该核对哪些字段
用死链检查工具排查问题时，日志里最该核对的是五类字段：请求时间、请求方法与完整URL、响应状态码、来源页（Referer）和用户代理（User-Agent）。这五个字段能回答“谁在什么时候、从哪里、请求了哪个地址、服务器返回了什么”。缺少任何一项，都可能把正常的404、被误判的软404和真正的死链混在一起。
先明确要交付的结论，再决定看哪些字段
日志核对不是把整行读完，而是为了产出一份可执行的死链清单。清单里每条记录至少要能回答：这个URL是否真的失效、失效从什么时候开始、有多少入口指向它、是否需要保留原地址。倒推回来，日志字段就必须覆盖“地址、结果、来源、频率、客户端”五个维度。如果只是统计状态码数量，可以只看状态码和URL；如果要判断某条链接是否该做301，就必须同时看Referer和请求频率。
核心字段逐项核对方法与判断标准
- 请求方法与完整URL：确认是GET还是HEAD。部分死链检查工具默认发HEAD请求，若服务器对HEAD返回404、对GET返回200，日志里就会出现“工具报死链、实际可访问”的假象。核对时要连查询参数一起看，带参数的URL和不带参数的URL可能是不同资源。
- 响应状态码：404、410代表资源不存在，但404也可能是临时配置错误。301、302要区分是正常跳转还是跳转到了另一个404。核对时把状态码和URL成对记录，不要只统计数量。
- 来源页Referer：它告诉你链接是从哪个页面被点到的。Referer为空可能是直接访问、爬虫抓取或隐私策略屏蔽，不能直接判定为死链。若同一失效URL的Referer集中在某个栏目页，优先修那个页面的链接。
- 请求时间：用于判断失效是突发还是长期存在。把时间与状态码对照，如果某天起404数量骤增，多半是改版或删除操作导致，而不是零散的外链失效。
- User-Agent：区分搜索引擎爬虫、站内检查工具和真实用户。爬虫请求的404需要关注是否影响抓取，用户请求的404直接影响体验，两者处理优先级不同。
一个可执行的核对流程
假设日志中某URL出现404，按以下顺序操作：
- 筛选该URL的全部记录，按时间排序，确认最早出现404的时间点。
- 查看这些记录的状态码是否一致，排除HEAD/GET差异造成的误报。
- 提取Referer字段，列出所有指向它的来源页，按出现次数排序。
- 查看User-Agent，把爬虫请求和用户请求分开统计。
- 用浏览器或命令行实际访问该URL，确认当前真实返回结果，与日志比对。
判断结果时注意：如果日志显示404但实际访问返回200，属于日志滞后或缓存问题，不必改链接；如果实际也返回404且Referer集中在站内，优先修站内入口；如果只有外链Referer，考虑做301到最相关的新页面，而不是直接放任404。
容易误判的几种情况
软404是常见陷阱：服务器返回200，但页面内容是“未找到”。这类记录在日志里状态码正常，只靠状态码字段发现不了，需要结合页面标题或内容长度字段判断。另一种是robots.txt限制抓取导致的记录缺失——日志里没有某URL的请求，不等于它没被链接，只说明爬虫被规则挡住了，这与死链是两回事。此外，站点地图里列出的URL不保证被收录，日志中没有对应抓取记录时，应先检查抓取规则和内部链接，而不是直接判定为死链。
核对完成后的下一步
把核对结果整理成三列：失效URL、来源页、建议动作（保留、301、删除链接）。拿这份清单去对照站点当前的链接结构，先处理站内Referer最多的那几条，再处理只有外链指向的地址。处理完一轮后，隔一段时间重新导出日志，用同样的字段再核对一次，确认失效记录是否减少。
