伺服器架構導致的SEO收錄異常

戲笑醉紅顏發表於2020-08-24

最近,本人負責的其中一個站點收錄出現了異常,趁著週末有空講述一下整個診斷過程。核心問題有兩點,伺服器架構和網站程式架構導致的;本篇僅分享伺服器架構導致的收錄異常。


首先,介紹一下自己。本人就職於深圳某企業,長期混跡於乙方外包公司,眾所周知seo外包公司接的是絕大部分是小企業網站,這些網站做的關鍵詞往往也僅是改個TDK就完成排名的工作。


再加上,目前絕大部分中小站點的架構很簡單,開源CMS+單一雲伺服器(虛擬主機)+CDN(這還是有點運維能力公司)。鑑於以上經驗,導致本人完全沒有意識到伺服器架構方面也能出現問題。


一、收錄異常的發現


從(圖1)可以和明顯的看出,在3月中下旬收錄是偏向正常的,問題出現在3.31日-4.25日之間出現了浮動,也就是說,這個區間一定是站點出現了問題導致收錄異常。


本人開始按常規方法排查,特別是伺服器日誌有些引數沒有排除注意,以至於導致了問題發現,具體如下:



1.1、站長平臺模擬爬蟲抓取,正常。


1.2、搜尋引擎爬蟲抓取數量在提升,偏向正常。這裡有異常,排查偽蜘蛛爬蟲在抓資料,真實百度爬蟲確實也在增長。


1.3、核心關鍵詞排名浮動,但偏向且上升趨勢靠前,目前核心大詞處於前5名,正常。


1.4、伺服器日誌分析,爬蟲對應的request_uri值(相對地址),暫屬正常,請看下文。


1.5、伺服器日誌是阿里雲的日誌,http請求,7.18日、7.19日、7.20日以及7.26日出現小面積伺服器500訪問錯誤;但最多隻出現有限的時間收錄異常,不至於大範圍不收錄。


在伺服器訪問日誌分析中,一般需要注意的項是:爬蟲抓取時間值,爬蟲頁面URL值,爬蟲在頁面抓取順序,時間內爬蟲抓取數量,另一說蜘蛛IP值有權重高低之分(本人不確定,故不參考)


頁面URL值:一般伺服器日誌是相對地址,本人診斷出現的問題在於忽略host值,真實抓取URL應該是,host+request_uri值組合。


頁面抓取順序:可檢驗網站架構的爬行情況,大概可以知道爬蟲在網站頁面中的爬行順序,可以輔助使用爬蟲軟體或者開發經典爬蟲(PY,PHP等)的爬行情況作為參考


時間內爬蟲抓取數量:檢驗網站頁面總量和時間段內抓取量的佔比,判斷網站的受歡迎程度。


說到這裡,交代一下站點的伺服器架構:


用的是負載均衡,檔案伺服器+資料伺服器+前端伺服器,資料伺服器全部資料是由API介面、GET方式前端和app使用,網站URL是相對地址。伺服器之間自然用的也是內網通訊。


綜上,可能大家也看出有忽略的引數,是1.4中提到的日誌host值,因為是相對地址,host+request_uri才是抓取的完整地址。一直忽略的Host值,原來是API的二級域名(圖2)



說到這裡,大家可能已經基本上可以確定知道原因了。


就是百度根本沒有抓取到真實的頁面URL,實際上抓取的是API域名+request_uri,


即假設資料庫伺服器API給前端渲染的資料路徑是api.tianying888.com,走內網IP,


抓取到的頁面URL為:


真實應該是外網IP的URL:


既然核心問題已把握30%,下一步自然是資料證明,主要從幾個點。


1、翻開發日誌記錄


2、4月前後的伺服器日誌整理對比


從1中發覺,4.13號負載均衡的資料伺服器api取消代理,這樣造成的後果是前端直接抓取了host主機值為api域名下的資料在前端渲染,因為是直接使用內網IP沒經過代理,同時api二級域名為host主機值。


從2中發覺,4月前後日誌的host主機值出現了改變,由變成了api.tianying888.com。


最終,問題就出現在host主機為api的站點,沒有使用代理,也就是說只要api站點透過代理變成www的二級站點渲染即可。如果沒有使用代理,百度GET返回的頁面是內網IP,抓取到的也就是 這個URL。


解決方案:


1、負載均衡的資料伺服器api介面使用代理


2、Head區增加標籤


3、前端渲染的HTML使用絕對路徑


4、開發個API介面推送資料


本文完。鑑於本人僅是SEO,運維能力有限,單機伺服器配置下站可以,負載均衡只是略微聽過,如有運維方面錯誤之處請見諒。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28328249/viewspace-2714219/,如需轉載,請註明出處,否則將追究法律責任。

相關文章