404页面优化 - 怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a77b732424a2.html
📄
404页面优化 - 怎样取得可复查的状态证据
可复查的状态证据，指的是任何人拿到你交付的记录后，都能独立重现同一次请求、看到同一个状态码，并判断这个404是预期结果还是故障。常见误解是：截一张浏览器显示404的图就够了。实际上截图只能证明“当时某个浏览器显示了404”，无法证明响应头状态码、请求URL、时间、来源环境，也无法排除缓存或前端路由伪造的404。要交付清楚、减少返工，必须记录机器可读的原始响应。
为什么截图和口头描述不算证据
浏览器页面上的“404”可能来自三种完全不同的情况：服务器真的返回了HTTP 404；服务器返回200但页面内容写着“未找到”；前端路由在客户端渲染出404视图，而网络层状态码是200。这三种情况对搜索引擎和后续处理的意义完全不同。截图无法区分它们，也无法证明请求的是哪个URL、是否跟随了重定向。
另一个问题是不可复现。截图没有记录请求头、响应头、时间戳和工具版本，别人换一台机器、换一个网络环境重试，可能得到不同结果，于是协作中就会出现“我这边是404，你那边是200”的争论，返工由此产生。
最小可复查证据应包含哪些字段
一次404状态检查，至少应固定以下内容，缺一项就会削弱可复查性：
- 完整请求URL，包含协议、主机、路径和查询参数，不要只写路径。
- 请求方法与关键请求头，尤其是
User-Agent和Accept，因为部分服务会按客户端返回不同结果。 - 响应状态码与状态行，例如
HTTP/1.1 404 Not Found。 - 响应头中的
Location（若有跳转）、Cache-Control、Content-Type。 - 是否跟随重定向，以及最终落地的URL。
- 执行时间（含时区）与执行工具及版本。
这些字段能让人判断：请求是否被重定向、是否命中缓存、返回的是HTML还是其他类型。它们是复查的锚点，而不是装饰。
用命令行取一份可交付的原始记录
以curl为例，下面这条命令只取响应头，不下载正文，适合快速核对状态码：
curl -sS -D - -o /dev/null -L --max-redirs 5 "https://example.com/not-exist"
参数含义：-D -把响应头打印到标准输出，-o /dev/null丢弃正文，-L跟随重定向，--max-redirs 5限制跳转次数。输出里会依次出现每个跳转的响应头，最后一个状态行就是最终结果。
如果需要同时保留请求头用于复查，可加-v，但注意-v的输出包含连接细节，交付时建议把请求头和响应头单独整理，避免混入无关内容。把命令原文和完整输出一起存档，别人复制命令即可复现。
判断结果时的适用条件与例外
拿到状态码后，不要只看数字就下结论。需要结合条件判断：
- 若最终状态码是404，且
Content-Type为text/html，说明服务器确实以404响应，属于标准的未找到。 - 若状态码是200但页面内容提示未找到，说明这是“软404”，对搜索引擎而言仍是可索引页面，需要单独处理。
- 若出现301或302后落到200，说明该URL被重定向到有效页面，此时它不是404，而是跳转配置，应另行核对跳转目标是否符合预期。
- 若不同
User-Agent得到不同状态码，说明服务端做了客户端区分，证据中必须注明所用UA，否则结论不成立。
还要注意：robots.txt中的抓取限制不等于可靠的索引移除，它只影响抓取行为，不能替代404或noindex；站点地图也不保证收录。这些是不同机制，不能互相替代，检查时不要混为一谈。
多人协作中的交付与复核约定
要让证据真正可复查，交付格式需要统一。建议约定：每条记录一行命令加一段原始输出，输出保留状态行和关键响应头；文件名包含URL的哈希或简短标识与执行日期；执行时间统一用带时区的ISO 8601格式。复核人只需运行同一命令，比对状态行和Location是否一致。若不一致，优先排查缓存、CDN节点、请求头和网络出口差异，而不是直接判定对方记录有误。
下一步：挑一个你正在处理的404 URL，用上面的命令取一份带响应头的记录，与协作者各自执行一次并比对状态行，把差异点作为排查起点。
