404 not found - 如何取得可复查的状态证据
📍 WDQWDWQD987AAAAA:216.73.216.163
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d8bf6f7f8b8b.html
📄
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d8bf6f7f8b8b.html
📄
404 not found - 如何取得可复查的状态证据
要取得可复查的 404 not found 状态证据，核心是保存“请求—响应—时间”三者的原始记录：用可导出、可对照的方式记录 URL、HTTP 状态码、响应头、响应时间、请求来源和抓取工具标识。只有能重复执行并得到相同结果的记录，才算可复查证据；截图和口头描述只能作为辅助。
先确认你要证明的是哪一种 404
404 not found 可能出现在不同层面，证据形式不同，不能混在一起判断：
- 服务器对某个 URL 返回 404：证据是原始响应行和响应头，例如
HTTP/1.1 404 Not Found。 - 页面内容显示“404”但状态码是 200：这属于软 404，证据要同时记录状态码和页面正文特征。
- 搜索引擎抓取工具看到 404：证据是服务器访问日志中对应的抓取请求记录，而不是浏览器里的显示结果。
- 站点地图或内部链接指向了 404：证据是链接来源 URL 加目标 URL 的对应关系。
先明确要证明哪一类，再决定采集哪些字段。否则容易拿到一堆截图，却无法回答“谁在什么时候请求了什么，服务器回了什么”。
可直接执行的证据采集步骤
下面步骤以单条 URL 为例，适用前提是你对该站点有访问权限或可公开请求。假设例子：某文章页疑似返回 404，需要留下可复查记录。
- 用命令行请求并保存完整响应。例如
curl -I https://example.com/page，把输出重定向到文件，保留状态行和响应头。 - 记录请求时间，使用统一时区，例如 UTC，避免日志时间与本地时间对不上。
- 保存请求时的完整 URL，包括查询参数和末尾斜杠，因为这两处差异可能导致不同结果。
- 如果涉及抓取工具，从服务器访问日志中筛出对应时间段的请求，记录 User-Agent、来源 IP、请求方法和状态码。
- 对同一 URL 重复请求至少两次，间隔一段时间，观察状态码是否稳定。若两次结果不同，说明存在缓存、重定向或后端不稳定，需要继续定位。
- 把上述记录整理成表格或日志文件，标注采集工具、采集时间和执行人，便于他人复现。
验收信号：另一个人拿到你的记录后，能按同样命令得到相同状态码，并能指出请求时间、请求目标和响应结果。若只能看到一张截图，无法确认请求头和状态码，就不算合格证据。
证据里必须包含的字段
可复查的状态证据至少应包含以下字段，缺一项都会削弱证明力：
- 请求 URL：完整地址，含协议、主机名、路径、查询字符串。
- 请求方法：GET 或 HEAD，两者在部分服务器上可能返回不同结果。
- 状态码：如 404、301、200，必须是原始响应中的数值。
- 响应头：重点关注
Location、Cache-Control、Content-Type。 - 时间戳：请求发出时间和响应返回时间，标明时区。
- 请求来源：浏览器、命令行工具还是搜索引擎抓取工具，附 User-Agent。
- 采集方式：命令、日志导出或抓包文件，保证可重复执行。
如果证据用于向他人说明问题，建议同时保留原始文件和一份可读摘要。原始文件用于复核，摘要用于快速理解，两者不要互相替代。
常见误判与对应检查项
拿到 404 记录后，不要立刻断定原因。同一个现象可能有多种解释，应按检查项逐一排除：
- 浏览器显示 404，但命令行返回 200：可能是浏览器缓存或前端路由渲染，检查响应头与缓存策略。
- 命令行返回 404，但日志里没有该请求：检查请求是否经过了 CDN、反向代理或负载均衡，日志可能记录在另一层。
- robots.txt 禁止抓取某路径，同时该路径返回 404：抓取限制不等于索引移除，两者是不同机制，需要分别核查。
- 站点地图中包含该 URL：站点地图不保证收录，也不代表 URL 一定可访问，应单独请求验证状态码。
- HTTPS 证书正常：HTTPS 不保证页面可访问，也不保证无漏洞或排名，状态码仍需单独采集。
判断结果时，先区分“可能原因”和“已经定位的原因”。只有当日志、响应头和复现结果能互相印证时，才把某个原因写成已确认。
把证据变成可交接的记录
采集完成后，把记录整理成一份最小交接材料：问题 URL 列表、每个 URL 的状态码、采集时间、采集命令、原始响应文件位置、已排除和未排除的原因。若涉及多个搜索引擎的抓取情况，要分别记录，不要用一份浏览器结果代替所有来源。下一步可以挑一条最有代表性的 URL，按上述步骤完整跑一遍，确认记录能被他人复现，再决定是否扩大采集范围。
