404 not found：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b094db69d247.html
📄
404 not found：日志中应该核对哪些字段
排查 404 not found 时，日志里最该先核对的是请求时间、请求方法、请求路径、查询字符串、HTTP 状态码、来源页、客户端标识、响应字节数和处理耗时。这些字段能把“谁在什么时候请求了什么、服务器为什么返回 404、这个 404 是否值得处理”串成一条可验证的线索。只看状态码数量没有意义，必须把状态码和具体 URL、来源页、时间关联起来。
准备：先确认日志字段是否完整
不同服务器和 CDN 的日志格式不同，但排查 404 至少要能拿到以下字段。如果字段缺失，先在日志配置或日志导出中补齐，否则后续判断容易变成猜测。
time或timestamp：请求发生时间，用于和改版、发版、删除文件的时间对齐。method：GET、POST 等。对 404 来说，GET 通常更值得优先处理，因为可能来自链接或搜索引擎抓取。path或uri：请求路径，是定位问题资源的核心字段。query_string：查询参数。有些 404 只在带参数时出现，去掉参数却正常。status：HTTP 状态码，确认确实是 404，而不是 403、410 或 500。referer：来源页。能判断是站内链接、外部链接还是直接访问。user_agent：客户端标识。可区分浏览器、搜索引擎抓取工具、脚本或监控程序。bytes_sent：响应字节数。404 页面若返回大量内容，可能被误当成正常页面。request_time：处理耗时。用于排除因超时、重写规则异常导致的伪 404。
实施：按优先级核对字段并归类
先按 path 聚合，统计哪些路径出现 404 最多；再对每个高频路径回看 referer 和 user_agent。这一步最关键：它决定 404 是站内链接错误、外链失效、资源被删除，还是抓取工具访问了不存在的路径。
- 用
status过滤出 404，排除 410、403、500，避免把不同问题混在一起。 - 按
path分组，观察是否集中在某个目录、某次改版前后的 URL 结构。 - 查看
referer：来源是站内页面，说明站内链接需要修；来源是外部站点，说明外链指向了已失效地址。 - 查看
user_agent：若大量来自抓取工具，需检查该路径是否曾被收录或出现在站点地图中；若来自监控脚本，可能是脚本配置了错误地址。 - 查看
query_string：确认是否因参数拼接、大小写、尾斜杠差异导致同一资源被判定为不存在。 - 查看
time：把 404 高峰与发版、迁移、删除文件的时间对比，判断是否为变更引入。
假设某路径 /old-page 在日志中持续出现 404，来源页是站内导航，用户代理是普通浏览器，那么应优先修复站内链接或设置重定向。若来源为空、用户代理是脚本，且路径明显是扫描行为，则不必为每个请求创建页面，只需确认服务器没有错误暴露敏感信息。
验证：确认修复后日志字段的变化
修复链接或添加重定向后，不能只看页面能否打开。应回到日志中核对同一 path 的 status 是否从 404 变为 301、302 或 200，并确认 referer、user_agent 与之前一致。若状态码仍为 404，检查重定向规则是否匹配了查询字符串、大小写或尾斜杠。若状态码变为 200 但 bytes_sent 异常小，可能是返回了空页面或错误页，需要进一步核对响应内容。
对于确认永久不再提供的资源，可以考虑返回 410 而不是 404，但两者在日志中的处理方式不同：410 表示明确移除，404 表示未找到。不要用 robots.txt 的抓取限制来代替 404 处理，robots.txt 限制抓取不等于可靠的索引移除；站点地图也不保证收录。HTTPS 同样不保证页面一定可访问或没有漏洞。
维护：把 404 日志核对变成固定检查项
在已有项目上改进时，建议每周或每次发版后导出一次 404 日志，按 path 聚合出前若干条，再结合 referer 和 user_agent 分类处理。维护时重点看三类变化：新增的高频 404 路径、来源页从站内变为站外、以及原本正常的路径突然返回 404。对每一类记录处理结果，例如修复链接、添加重定向、确认无需处理。这样下一次核对时，可以直接对比字段变化，而不是重新翻整份日志。
下一步：从当前日志中导出最近七天的 404 记录，先按 path 聚合，再对排名靠前的路径逐条核对 referer、user_agent 和 time，把确认需要修复的路径列成清单。
