整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
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小時內與您取得聯系。
