404状态码，检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /59c42d9efe5d.html
📄
404状态码，检查前需要准备哪些信息
要排查404状态码，检查前最该准备的不是“打开网页看看”，而是能还原请求与响应过程的证据：完整URL、请求时间、请求方式、返回状态码与响应头、服务器或CDN日志、当前路由或重写规则、以及这条链接的来源。只有这些信息齐了，才能判断404是链接写错、资源被删、路由未匹配，还是抓取工具或监控工具误报。
先确定要交付什么结果
检查404不是交一份“打不开的链接清单”就结束。可验收的交付结果通常包括：每条404的完整URL、首次发现时间、请求来源（浏览器、站内链接、外部链接、站点地图、抓取工具或监控）、实际响应状态码、服务器日志中的对应记录、判断结论（应保留、应重定向、应恢复内容或应返回410）以及处理后的复测结果。先把交付物定下来，再倒推需要哪些资料，能避免查了半天却无法给出结论。
必须收集的基础信息
- 完整URL：包含协议、主机名、路径、查询字符串。带参数的地址常被误判，例如
?page=2被删掉后可能落到404。 - 请求方法与时间：GET、HEAD、POST的结果可能不同；时间要精确到分钟，便于和日志对齐。
- 响应状态码与响应头：重点看状态码是否确为404，以及
Location、Cache-Control、Content-Type等字段。有些页面返回404但内容仍是正常页，属于软404的近似情况。 - 服务器或CDN日志：日志能确认请求是否到达源站。若日志中没有记录，可能被CDN、WAF或缓存层拦截，而不是源站路由问题。
- 当前路由与重写规则：包括Web服务器配置、应用路由表、反向代理规则。路径大小写、末尾斜杠、URL编码差异都可能导致匹配失败。
- 链接来源：站内导航、文章正文、站点地图、外部引用、旧版页面、广告落地页。来源不同，处理优先级不同。
按现象区分可能原因，不要急着下结论
同一个404现象可能有多种解释。URL拼写错误、资源被删除、路由规则未覆盖、重定向链断裂、大小写不一致、CDN缓存了旧响应、抓取工具访问了被robots.txt限制的路径，都可能表现为“打不开”。其中robots.txt只表达抓取限制，不等于可靠的索引移除；站点地图列出URL也不保证被收录。检查时应先记录现象，再逐项排除，不要看到404就断言“页面被删了”。
如果日志显示请求到达源站且返回404，问题更可能在应用路由或资源本身；如果日志没有记录，优先检查CDN、WAF、负载均衡和DNS解析链路。若响应头中出现重定向，还要确认最终落地页是否返回200，避免重定向到另一个404。
用一条链接做最小验证
假设某文章地址为https://example.com/guide/seo-basics，检查时可以按以下步骤执行：
- 用浏览器开发者工具的Network面板请求该地址，记录状态码、响应头和最终URL。
- 用命令行请求同一地址，例如
curl -I https://example.com/guide/seo-basics，对比状态码是否一致。 - 在服务器访问日志中按路径和时间筛选，确认请求是否到达源站。
- 检查应用路由表或重写规则中是否存在该路径，注意大小写和末尾斜杠。
- 若确认内容已迁移，配置301重定向到新地址；若内容永久删除且无替代，返回410比返回404更明确。
- 处理后再次请求原地址，确认返回301或410，并确认目标地址返回200。
这套步骤适用于已有页面或项目的日常排查。判断结果是：日志有记录且路由缺失，属于应用侧问题；日志无记录但CDN有记录，属于边缘层问题；状态码为404但页面内容正常，需要按软404进一步核查。
责任分工与验收条件
检查前还要明确谁提供什么：开发提供路由与日志权限，运维提供服务器或CDN日志，内容或SEO人员提供链接来源与业务优先级，测试人员负责复测。验收条件应写成可核对的结果，例如“原URL返回301，目标URL返回200”“日志中不再出现该路径的404记录”“站点地图与站内链接不再指向已删除地址”。没有这些条件，404处理很容易停留在“改了一个链接”的层面。
下一步建议先选一条有代表性的404链接，按上面的清单收集信息并完成一次最小验证，再决定是批量重定向、恢复内容还是返回410。
