404页面设置，日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /705eebe434d9.html
📄
404页面设置，日志中应该核对哪些字段
404页面设置完成后，日志中最该优先核对的是请求路径、HTTP状态码、来源页、User-Agent、请求时间和响应字节数这几类字段。它们能回答三个问题：哪些不存在的地址被访问了、访问是真人还是爬虫、以及你的404页面是否真的返回了404而不是200。第一次排查时，先看状态码和请求路径这两列，基本就能判断问题出在哪。
准备：先确认日志里有哪些字段可用
不同服务器和CDN记录的字段名不一样，但含义大同小异。打开一份访问日志，先找到下面这些位置：
- 请求路径：常见写法是
request_uri、cs-uri-stem或引号里的GET /xxx部分。 - 状态码：通常是三位数字，如
status、sc-status。 - 来源页：
referer或referrer，没有则为空或-。 - User-Agent：
user_agent、cs(User-Agent)。 - 时间：
time_local、date、time。 - 响应字节数：
body_bytes_sent、sc-bytes。
如果日志里缺少状态码或请求路径，先补上再谈分析，否则后面所有判断都没有依据。
实施：逐项核对，重点看状态码与路径的对应关系
最关键的一步是把状态码和请求路径放在一起看。正确的404页面设置应当让不存在的地址返回404，同时返回你自定义的页面内容。核对时按下面顺序做：
- 筛选出状态码为404的记录，确认它们确实是你不存在的页面，而不是因为权限、后端错误被误判。
- 检查同一路径是否同时出现200和404。如果同一URL有时200有时404，可能是缓存、重写规则或后端不稳定，需要单独排查。
- 看响应字节数。如果404页面的字节数和正常页面差不多，可能返回了完整页面但状态码写错；如果字节数极小，可能是服务器默认错误页，自定义页面没有生效。
- 看来源页。来源页集中在站内某个页面，说明是站内链接写错；来源页是外部域名，说明是外链指向了已删除地址。
- 看User-Agent。大量404来自同一爬虫标识，说明它仍在抓取旧地址，可结合站点地图和robots规则判断是否需要处理。
假设某条日志显示：路径 /old-page，状态码 404，来源页为空，User-Agent 为普通浏览器，响应字节数 5120。这说明页面确实返回了404，且自定义页面有内容输出，属于正常表现。若同一路径状态码是 200，则说明404页面设置没有真正生效，需要检查服务器配置或应用路由。
验证：用日志之外的方式交叉确认
日志只能反映已经发生的请求，不能证明配置长期正确。验证时可以做两件事：一是用浏览器开发者工具或命令行请求一个确定不存在的地址，看返回的状态码和页面内容；二是隔一段时间再拉一次日志，对比404路径是否在减少或转移。如果日志中404集中在少数几个路径，优先修链接或做重定向；如果404分散且数量大，可能是站点结构或采集行为导致，需要进一步分类。
维护：定期复查字段，避免误判
404页面设置不是一次配置就结束。后续维护时，建议固定核对这几项：状态码是否仍为404、自定义页面是否仍返回内容、来源页是否出现新的集中指向、爬虫请求是否被正确识别。注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，因此日志中的404不能简单等同于“搜索引擎已删除”。如果发现大量404来自同一来源，先判断是站内问题还是外部引用，再决定修链接、做重定向还是保留404。
下一步，从日志中导出最近一周状态码为404的记录，按请求路径分组统计，先处理出现次数最多且来源页指向站内的那几条。
