404notfound日志中应该核对哪些字段，排查前先看这五类记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e33a7e4f8e2.html
📄
404notfound日志中应该核对哪些字段，排查前先看这五类记录
处理404notfound时，日志里最该核对的字段是：请求时间、请求方法、请求的完整路径（含查询字符串）、HTTP状态码、响应体大小、Referer、User-Agent，以及服务端返回该状态码的来源标记。判断一个404是正常拦截、链接写错还是资源被删除，靠的是这几项组合，而不是单看状态码。第一次接触时，先固定一条真实404记录，把上述字段抄全，再决定下一步。
先分清日志里的404是哪一种
404notfound在日志中只是一个状态码，它背后的原因至少有四类：路径确实不存在、大小写或尾斜杠不一致、URL被重写规则改写后丢失、以及资源曾被访问但现在已删除。这四类在字段上的表现不同。例如路径大小写问题，请求路径与站内实际文件名只差一个字母；重写问题则常表现为请求路径正常，但响应来源标记指向重写或代理模块。
因此不要看到404就断言“页面被删了”。先看请求路径是否与站内已知URL完全一致，再看响应体大小：如果返回的是一个统一错误页，大小通常固定；如果大小接近0，可能是服务端直接拒绝，而不是应用层返回的错误页。
逐项核对的字段清单
- 请求时间：用于和发布、改版、删除操作的时间点对齐，判断404是否在某个变更之后集中出现。
- 请求方法：GET与HEAD、POST的404含义不同。HEAD返回404可能只是探测，不代表用户可见页面失效。
- 完整路径与查询字符串：这是最关键的一项。查询字符串常被忽略，但带参数的URL失效往往与参数规则变化有关，而不是路径本身。
- HTTP状态码：确认是404而不是410、403或500。410表示资源已明确移除，处理策略与404不同。
- 响应体大小：用于区分统一错误页与空响应，辅助判断404由哪一层产生。
- Referer：显示用户从哪个页面点进来。若大量404来自同一站内页面，问题多在该页面的链接，而不是目标资源。
- User-Agent：区分真实浏览器、爬虫与监控工具。来自爬虫的404需要单独统计，不能与用户访问混在一起。
- 响应来源标记：如上游服务名、重写规则命中标记或应用日志中的路由名，用于定位404产生的位置。
一个可执行的核对步骤
假设你从访问日志中筛出一条404记录，路径为 /old-page，状态码404，Referer为空，User-Agent为常见浏览器。可以按以下顺序处理：
- 在站内搜索该路径，确认当前是否还有对应页面。若没有，进入第2步；若有但大小写或尾斜杠不同，先判断是否由规范化规则导致。
- 检查服务器配置中的重写与重定向规则，确认该路径是否被某条规则改写到了不存在的目标。
- 查看应用日志中同一时间的路由记录，确认请求是否到达应用层。若未到达，问题在Web服务器或代理层；若到达并返回404，问题在应用路由或数据查询。
- 根据Referer判断是否需要修复来源页链接。若Referer为空且该路径曾被外部引用，考虑设置301跳转到最相关的新页面，而不是直接保留404。
- 修改后重新请求同一路径，复查状态码是否变为200或301，并确认响应体大小与预期页面一致。
适用条件：这套步骤适用于你能拿到原始访问日志的情况。如果只能看到统计报表中的404汇总数字，缺少路径与Referer字段，应先补全日志字段，再做判断。判断结果上，若路径存在但状态码仍为404，多半是权限、重写或应用路由问题；若路径确实不存在且无外部引用，保留404是合理选择。
容易混淆的几个判断点
robots.txt中的抓取限制不等于索引移除，日志里出现404也不代表搜索引擎已经删除该URL。站点地图不保证收录，HTTPS也不保证页面一定可访问。这些结论需要分别核对，不能用一个字段替代。
另外，若404集中出现在改版之后，优先对比改版前后的URL规则，而不是逐条修复。若404长期零星出现且Referer为空，多为外部旧链接或扫描请求，处理优先级可以降低。复查时至少观察一个完整访问周期，确认修复后不再产生同类404，再结束这次排查。
下一步：从日志中导出最近一天的全部404记录，按请求路径分组统计出现次数，先处理次数最高且带站内Referer的那一组。
