网站死链查询_日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d2debbffb154.html
📄
网站死链查询_日志中应该核对哪些字段
做网站死链查询时，日志里最该先核对的字段是：请求状态码、请求URL、来源页URL（Referer）、User-Agent、请求时间、请求方法，以及响应体大小。其中状态码和请求URL是判断死链的核心，Referer决定这条死链是否值得优先修复，User-Agent和时间用于排除扫描器与偶发波动。
准备：先确认日志里有没有这几列
不同服务器和CDN输出的日志格式不同，字段名可能是status、code、sc-status，也可能是URL、request、cs-uri-stem。核对时不要只看列名，要确认每一列对应的实际含义：
- 状态码：判断死链的第一依据，404、410通常代表资源不存在，403、500需要结合其他字段区分。
- 请求URL：包含路径和查询参数，查询参数有时会导致同一路径被误判为不同死链。
- Referer：记录用户从哪个页面点进来的，用于定位需要修改的内链或外链。
- User-Agent：区分真实用户、搜索引擎爬虫和批量扫描工具。
- 请求时间：用于判断死链是持续存在还是某个时间段集中出现。
- 请求方法：GET与HEAD的返回可能不同，HEAD请求返回404不一定代表页面不可访问。
如果日志中缺少Referer或User-Agent，后续筛选会困难很多，建议先补齐日志字段再开始分析。
实施：用状态码加URL锁定候选死链
先从日志中筛出状态码为404和410的记录，按请求URL聚合计数。计数高的URL通常影响面更大，应优先处理。但要注意以下判断条件：
- 状态码为404且请求URL是静态资源（如.js、.css、.jpg），可能是页面引用路径写错。
- 状态码为404且请求URL是页面路径，可能是页面被删除或链接拼写错误。
- 状态码为403，可能是权限限制或防盗链，不一定是死链。
- 状态码为500，属于服务端错误，应先排查程序或配置，不能直接当作死链删除。
假设某条日志显示：请求URL为/old-page.html，状态码404，Referer为/article/abc，User-Agent为普通浏览器。这说明有真实用户从文章页点进了一个不存在的页面，应优先修复文章页里的这条链接，而不是直接删除/old-page.html。
验证：排除扫描器和偶发请求
日志中的404不一定都是需要处理的死链。验证时要交叉核对：
- 同一URL是否在多个不同Referer下反复出现404，若是，说明链接被多处引用。
- User-Agent是否为已知扫描工具或空值，这类请求可以降权处理。
- 请求时间是否集中在极短时间窗口，集中爆发可能是爬虫扫描而非真实用户。
- 用浏览器或无痕窗口直接访问该URL，确认返回结果与日志一致。
只有真实用户或正常爬虫触发、且返回404或410的URL，才应进入修复清单。修复后要再次查看日志，确认该URL不再出现404，或已通过301跳转到有效页面。
维护：把日志核对变成固定检查项
死链查询不是一次性工作。建议在日志分析流程中固定以下检查项：每周筛一次404和410状态码，按Referer分组找出问题来源页；每月对比一次修复前后的状态码变化；对已删除页面统一返回410而非404，便于后续区分。维护阶段的关键不是追求零404，而是确保影响用户访问和爬虫抓取的死链被及时发现并处理。
下一步可以打开最近一周的访问日志，按状态码筛选出404记录，再按Referer排序，先处理来自站内页面的那部分链接。
