HTTP状态码404，怎样取得可复查的状态证据

📍 WDQWDWQD987AAAAA:216.73.217.12
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /00522f2d7792.html
📄

HTTP状态码404，怎样取得可复查的状态证据

要取得可复查的404状态证据，核心是同时记录请求URL、响应状态行、响应头和检测时间，并确保这些记录来自同一个可重复的请求。只截图浏览器页面、只看抓取工具汇总数字，都不足以让人复查。下面按准备、实施、验证、维护四步说明。

准备：先固定要检测的URL和请求方式

404是服务器对某个具体请求返回的响应状态，不是页面上的一句“页面不存在”。因此第一步是把待查URL写清楚，包括协议、主机名、路径和查询参数。例如https://example.com/old-page?from=nav和https://example.com/old-page可能返回不同状态，不能混为一条记录。

同时确定请求方式。普通页面访问用GET；如果只关心资源是否存在，也可以先用HEAD，但HEAD的响应头未必与GET完全一致，复查时应保持同一方法。准备一张记录表，至少包含以下字段：

实施：用可重复的命令拿到原始响应

最关键的一步是保留原始响应，而不是只保留结论。命令行工具适合生成可粘贴、可复查的文本证据。以下命令只作为示例，实际域名和路径需替换：

curl -sS -D - -o /dev/null -L --max-redirs 0 https://example.com/old-page

其中-D -把响应头输出到屏幕，-o /dev/null丢弃正文，-L表示跟随重定向，--max-redirs 0表示不跟随。若想观察重定向链，可去掉--max-redirs 0，并加上-w "%{http_code} %{url_effective}\n"查看每一跳的最终状态。

如果返回404，响应头中通常没有Location；如果返回301或302，则会有Location指向新地址。这两种情况不能都记成“页面没了”。复查者需要看到状态行，例如HTTP/1.1 404 Not Found，才能判断服务器确实对这次请求返回了404。

验证：区分“服务器返回404”和“页面显示404”

浏览器页面显示“404”并不等于服务器返回了404状态码。有些站点会用200状态码返回一个写着“未找到”的页面，这种做法对搜索引擎和监控工具都不友好。验证时至少做三项交叉检查：

  1. 用命令行或浏览器开发者工具的“网络”面板查看状态码，而不是只看页面文字。
  2. 检查响应头中的Content-Type是否为text/html，确认返回的是页面而非图片或接口错误。
  3. 换一个网络环境或DNS解析结果再请求一次，排除本地缓存、代理或hosts文件造成的假象。

如果同一URL在不同时间返回不同状态，例如第一次404、第二次200，可能是缓存、CDN回源或后端发布导致。此时应记录每次请求的时间与响应，不能只保留其中一次。判断结果是：若多次独立请求都返回404，且响应头一致，可认为该URL当前处于404状态；若状态不稳定，应继续排查缓存与发布流程。

维护：让证据可复查、可对比

证据要能被别人复查，必须包含“怎么做的”和“看到了什么”。建议把每次检测输出保存为文本文件，文件名带日期和URL摘要，例如2025-06-01-old-page-404.txt。文件内容保留完整命令和原始响应，不要只写“已确认404”。

若需要长期监控，可定期对同一批URL执行相同命令，并把状态码、响应时间和Location字段提取成表格。对比时重点看三种变化：404变成200、404变成301、404持续不变。前两种说明站点行为已改变，需要重新核查；第三种说明该URL仍未恢复或未做重定向。

注意，robots.txt中的抓取限制不等于可靠的索引移除，站点地图也不保证收录。404证据只能说明服务器对某次请求的响应状态，不能直接推断搜索引擎是否已移除该URL。若关心索引状态，应另外在对应搜索引擎的站长平台中分别核查。

下一步：选一个你怀疑返回404的URL，用上面的curl命令执行一次，把完整输出保存下来，再换一个网络环境重复一次。两次结果一致，这份记录就可以作为可复查的状态证据。

图1 图2
nginx