整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
404页面的目的是：告诉浏览者其所请求的页面不存在或链接错误，同时引导用户使用网站其他页面而不是关闭窗口离开。
现在大部分开源系统都会为大家考虑到404页面的跳转引导，比如：z-blog/wordpress，都是很不错的开源系统（注意不要用最原始的开源系统，而是采用带有模板的系统）。菜鸟后院网站本身也是wordpress的开源程序，然后我们用robin模板。(花299元拥有和菜鸟后院一样的网站，包括域名和1G阿里巴巴云空间)
搜索引擎使用 http 状态码来识别网页的状态。当搜索引擎获得不正确的链接时，网站应该返回一个状态代码404，告诉搜索引擎放弃索引该链接。如果返回一个200或302状态代码，搜索引擎会对链接进行索引，导致许多不同的链接指向相同的页面内容。结果，搜索引擎对这个网站的信任度大大降低。很多网站存在这个问题，那就是404页面返回的是200或302状态码而不是404状态码。
1、做一个简单的404页面，命名如：404.html；
2、通过ftp把这个404页面上传到网站根目录；
3、进入虚拟主机管理后台，找到404页面提交的入口，添加以上404页面的地址，如：www.cnbackyard.com/404.html（一般空间服务商都有带着种功能，也可以直接找他们技术客服完成这步操作）
4、输入一个错误的链接进行访问测试，随便输入，比如：www.cnbackyard.com/123.html，如果正确返回到404.html页面，则算正确；
5、使用站长工具（http://tool.chinaz.com/pagestatus），输入任意一个错误网址，检查返回值是否为404。如果返回值是200，代表该主机商设置有误，可以与其技术反馈。
以上操作方法对于一个seo初学者来说，还是有点复杂，同学们可以关注燃灯教育直播课程，参加我们的培训，理解起来会更透彻一点。
日志的时候，我发现有大量请求到了站点其实并不存在的地址，但是返回码居然是 200？？这就不正常了，于是手工访问了一下一个不存在的页面，虽然 站点 在前台给我展示了一个 404 页面，但是浏览器显示返回码确实是 200！！纳尼？
还以为站点更新后改了这个机制呢，把主题下的 404.php 加了一个强行的 404 返回码，发现没有任何效果。
最后发现，居然是自己以前把 404 页面静态化留下的坑！
原因很简单，当时经常有人攻击一些不存在的页面，也就是每次都是动态的 404，服务器自然就容易高负载，因此做了一个静态化处理：
通过 curl 请求一个不存在的地址，触发 404 返回内容，然后保存在网站的某个目录下，比如 xxxx 下面
curl -o /data/wwwroot/web/xxxx/404.html https://xx.com/404/404
然后，在 Nginx Vhost 下新增 404 响应规则：
error_page 404=/xxxx/404.html;
重启 Nginx 之后，再访问不存在的博客页面的时候，Nginx 就直接返回 404.html 的内容了，从而实现 404 页面的静态化。
但是，Nginx 这里我写错了，导致每次返回 404.html 都是 200 返回码！！这样其实会误导搜索引擎的判断，以为页面是存在的。。。。大坑。
正确的 Nginx 配置方法应该是：
error_page 404 /xxxx/404.html;
也就是不用等号，而是用空格！修改后，重启 Nginx，然后访问不存在的地址发现已经是 404 返回码了，问题解决！
户反映：说自己的网站走nginx代理后，打开空白。直接IP加地址访问是好的（http://ip:port）
故障排查：
1、打开chrome浏览器，访问了下，访问情况真是客户描述的那样。
2、感觉打开chrome ，开发者工具，发现部分请求URL是404，css和js的
3、找客户要服务器登录的账号，检查nginx配置文件
upstream www.test.com{
server 127.0.0.1:8080;
}
server {
listen 80;
listen 443 ssl http2;
ssl_certificate /usr/local/nginx/conf/ssl/www.test.com.pem;
ssl_certificate_key /usr/local/nginx/conf/ssl/www.test.com.key;
server_name www.test.com;
access_log /data/wwwlogs/www.test.com_nginx.log combined;
index index.html index.htm index.jsp;
root /data/wwwroot/www.test.com;
location ~ .*\.(js|css)?$ {
expires 7d;
access_log off;
}
location / {
proxy_pass http://www.test.com;
include proxy.conf;
}
}
4、大家有发现上面配置有问题不？刚开始我也没有注意，自认为配置文件是对 的。
打算检查nginx的日志，一遍请求URL,一遍查看nginx果然还是404.（感觉疑惑），明明配置了proxy_pass http://www.test.com。
故障原因：
是因为 “location ~ .*\.(js|css)?$” 这个匹配拦截掉了，请求不能正常发往下一个“location /” ，也就不能正常抵达后端proxy_pass了。
解决方法：
第一种解决方法：是将后端的静态文件（css 和js ），放入前置nginx 机器/data/wwwroot/www.test.com
第二种解决方法 ：修改配置文件
upstream www.test.com{
server 127.0.0.1:8080;
}
server {
listen 80;
listen 443 ssl http2;
ssl_certificate /usr/local/nginx/conf/ssl/www.test.com.pem;
ssl_certificate_key /usr/local/nginx/conf/ssl/www.test.com.key;
server_name www.test.com;
access_log /data/wwwlogs/www.test.com_nginx.log combined;
index index.html index.htm index.jsp;
root /data/wwwroot/www.test.com;
location ~ .*\.(js|css)?$ {
proxy_pass http://www.test.com;
expires 7d;
access_log off;
}
location / {
proxy_pass http://www.test.com;
include proxy.conf;
}
}
*请认真填写需求信息，我们会在24小时内与您取得联系。
