改了一版404模板，页面上写着“抱歉，页面不存在”，用户看到的就是这句话。用curl -I打一次响应头，第一行返回的却是200 OK，而搜索引擎只认后面那个，状态码不在模板的改动范围里。
状态码是给爬虫看的判据，模板是给人看的。返回200再加一段空内容，在爬虫那边就是软404，会当成内容单薄的正常页收进去，长期占着索引位，用户点进来看到的是空白。
查法最直接的一条是curl -I地址，看返回的第一行。Windows上要注意的是shell，PowerShell里curl是Invoke-WebRequest的别名，参数不通用，要么写成curl.exe，要么在cmd里跑；小写的i是--include，会把响应头连正文一起打出来，首行同样是状态行。对整站做体检时，把栏目页和文章页各抽几条，一条一条打过去。
最常见的一层是伪静态规则把所有请求都转给入口文件。规则里写了兜底到index.php，找不到的地址也被入口接住，入口再输出一段提示，状态码停在200，看着像正常页。
另一层是状态码被接管了，本该404的请求被某一层换成了200。WordPress本身不这样：请求查不到内容时，核心的handle_404()会自己调status_header(404)，主题走404.php就是对的，原版主题一行代码都不用改。出现200的常见的是这几种：主题或页面构建器自定义了未找到页面，却拿一个普通页面去渲染；插件在pre_handle_404上做了短路；或者404模板里被加了一句status_header(200)。要手动补status_header，只在你自己写了未找到逻辑、盖过核心判断的时候才需要。
面板的404页面功能也是一层，有的面板只替换模板文件、不带返回码，看着配好了，实际没起作用，配完要自己用curl验一次。缓存会把改之前那份200存下来，源站改好了、缓存没刷，测出来还是200，清一次才看到真实状态。
Nginx上用error_page 404 /404.html，不写等号的时候状态码沿用原来的404、响应体换成这个文件；写成error_page 404 =200才会变成200。要确认的是这个文件不会被location里的try_files或rewrite再兜到index.php，绕一圈回来，状态码就跟着入口变成200了。
改完再打一次，先清一次缓存再测，CDN和浏览器都可能把上一次的响应留着。返回404的同时页面还得有内容，用户点进来看到的是一片空白。抽查优先测被删掉的栏目地址。
顺带清一遍旧账。历史遗留的软404不会自己退出索引，把它们整理成清单，该跳转的做301，该删的给真404，这些地址占着索引位置却没有内容，留着只会一直挂着。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
