对照测试环境与线上的404 not found,关键不是分别看两边是否返回404,而是用同一批URL、同一套请求头,在两边各请求一次,比较状态码、响应正文特征和跳转链路。只有两边对同一URL给出相同状态码,且404页面不是软404,测试结果才有参考价值。
从线上日志、站点地图或爬虫报告里抽取一批URL,至少覆盖四类:正常页面、已删除页面、带参数的页面、大小写或斜杠变体。把这份清单存成文件,测试环境和线上使用完全相同的一份。
请求条件也要固定,否则对照没有意义。重点确认:
User-Agent、Accept-Language、Referer保持一致,避免被规则按来源分流。这一步最容易出错的是只测了首页和几个栏目页。404问题的差异往往出现在带参数、带后缀、带多层路径的URL上,样本里必须包含这些形态。
用命令行工具分别请求测试环境和线上,把状态码、响应头、正文长度一起记录下来。示例命令只展示结构,域名和路径替换成你自己的:
curl -s -o /dev/null -w "%{http_code} %{size_download} %{redirect_url}\n" -A "Mozilla/5.0" https://example.com/old-page
对测试环境执行同一命令,只改主机名。把两边输出并排放在一起,逐条比较。判断规则如下:
如果测试环境有访问限制,无法直接请求,可以让运维在测试环境临时放行你的出口IP,或者用测试环境内部的抓取工具跑同一份URL清单。不要用线上结果去推断测试环境的行为。
状态码正确只是第一层。第二层要确认404页面本身可被识别为错误页:页面应有明确的“未找到”提示,不应包含大量可索引的正文内容,也不应自动跳转到首页或栏目页。自动跳首页再用200返回,本质上仍是软404。
还要把robots.txt和404区分开。robots.txt的抓取限制不等于索引移除,被robots禁止抓取的URL仍可能出现在搜索结果里,只是没有摘要。如果测试环境用robots.txt挡住了全部抓取,你测到的“404”可能只是被拒绝后的表现,不能代表线上真实返回。对照时把两边的robots.txt内容也拉出来比一遍。
站点地图同样不能作为判断依据。站点地图里列出的URL返回404,说明地图过期;地图里没列出的URL返回404,不代表它不该被收录。判断收录状态要看实际请求结果,不能靠站点地图推断。
测试环境和线上会各自变化,一次对照通过不代表长期一致。建议把URL清单和请求脚本放进版本管理,每次发布前跑一遍,输出两列状态码做差异比对。
维护阶段重点盯三类变化:
发现差异后,先判断差异属于配置问题还是内容问题。配置问题在测试环境改完再发布;内容问题需要确认线上是否已有页面承接该URL,再决定返回404还是做301。不要为了消除差异而把测试环境改成和线上一样的错误配置。
下一步:从线上日志导出最近30天返回404的URL,去掉明显是扫描器的请求,把剩下的URL按路径层级分组,每组抽3到5条,用上面的命令在两边各跑一次,把状态码差异列成表格,先处理“一边404一边200”的行。