SEO教程提供SEO基礎入門教程
微笑SEO優化教程網:關注本站讓你的SEO不斷進步!

網站降權解決方法

您現在的位置:SEO教程 > SEO優化教程 > 時間:2018-10-05 18:22:22 > 作者:smiseo
網站降權解決方法首先分析流量,最常見的應該就是當網站流量上升或下降時,如何使用流量統計工具找原因。
今天跟大家簡單討論一下當網站流量下降時的分析思路。
當發現網站流量有明顯下降時,首先應該分析什么來源的流量下降了。在百度統計中使用“升降榜”的日環比和周同比,或者使用自定義的兩天數據對比,兩個日期最好選擇同一類型的,比如都選擇非節假日的周三等,很容易分析出搜索流量、引薦流量和直接訪問三種流量來源中哪部分流量下降了,或者是全部都下降了。

網站降權解決方法

如果三種流量都下降了,又不是節假日等特殊的日子,那么就很可能是網站出現了問題,或打不開、或速度慢等,也有可能是技術人員改動網站時,把統計代碼誤刪了,在網站改版時經常會遇到這種情況。如果自行檢查確定網站沒有以上問題,那么還可以繼續向下分析流量的地區,在百度統計中使用“地區分布”功能進行以上所述對比操作,分析是否有個別地區出現流量明顯下降的情況,有可能是南北通信有問題或部分地區DNS解析有問題。

如果是引薦流量下降了,那么就使用“升降榜”繼續分析到底是哪些網站過來的流量下降了,找出確切的網站后,再分析對方網站是否有打不開的情況,對方網站是否撤掉了你的鏈接,或者直接聯系對方網站負責人了解相關情況。
如果是直接訪問流量下降,直接訪問的分析比較麻煩,至今也沒有非常靠譜的分析方法。不過直接訪問的流量一般都是老用戶,可以了解一下有哪些原因使得你網站的老客戶突然不來網站了。比如有些中小型電商網站,在“雙11”或其他大型電商有促銷活動的節假日時會出現流量大幅度下降。需要了解的是“直接訪問”的流量并不真的全部是直接訪問,還有一些丟失來源的流量,比如360搜索剛上線時,有段時間隱藏了來源,對于網站來說360搜索過來的流量都是直接流量,后來360搜索改動,又不隱藏來源了,這時就造成了網站的直接流量大幅度下降,不過這種情況下網站的總流量是不會有太大變化的。可以分析網站的Flash或者彈窗廣告是否變少了。
如果是搜索流量下降了,首先需要確定的是具體是哪個搜索引擎過來的流量下降了,同樣使用百度統計的“升降榜”就可以分析。比如分析到是百度的搜索流量下降了。這時需要先看一下網站的核心詞是不是還有排名,如果沒有排名了,繼續查看一下網站主要頁面的目標關鍵詞排名,如果也沒有排名了,那么網站就可能被百度降權了。當然還需要根據site、索引量等數據進一步分析。如果發現網站的核心詞排名都在,那么在百度統計“升級榜”中點擊“百度”,就可以看到各個搜索詞帶來流量的對比了。可以簡單分析一下具體是哪些關鍵詞的流量下降了,
一般是相對應的關鍵詞沒有搜索排名了,根據這些關鍵詞找出具體是網站的哪部分內容的排名被百度處理了。也可以直接使用百度統計的“受訪域名”或GA中的高級篩選來確定具體是網站的哪部分內容被百度處理了。找到具體的“病體”后再對該部分內容進行詳細分析,后續就不是流量分析的范疇了。
網站流量的上升和下降都可能會有很多原因,也并不是搜索引擎的流量下降就意味著網站被搜索引擎降權。搜索流量的浮動在10%-r20%都是比較正常的,很可能是自然的波動,可能是網站內有部分內容信息過時或部分內容突然被搜索引擎推薦,有時也有可能是百度的排序規則有微調。一般只要不是搜索流量減半或搜索流量直接全無,應該就不是被搜索引擎降權了。
流量分析重在分析,只是找出真正的“病體”,具體“病體”的病因是什么就需要另外根據網站近期的實際情況進行具體分析了。
多分析、多發現、多成長:在實際的流量分析工作中,還有很多其他數據值得分析,以上的數據也還有很多值得分析的地方。同樣也有很多需要注意的地方,有時候數據也會騙人,比如極端的數據都是需要分析后再確定是否值得相信的,跳出率100%或者0%的數據以及突然有一篇文章的流量比重要目錄頁的流量還要高出很多的情況是否是真實的流量呢?再比如同一數據不同比例尺的趨勢圖可能會造成變動幅度不同的假象等。
SEO中流量分析的目的就是效果檢測、發現和分析問題及發現網站流量的成長空間。不同問題的細分分析方法和思路都不盡相同,不同SEO基礎的人在數據中所看出的問題也會不同。現在由于SEO這個工作的特性,幾乎網站流量中所有數據都可以和SEO扯上關系,SEO人員應該提升自己對數據的敏感性,學會發現流量數據背后的問題。要想使流量分析在SEO工作中真正起到指導性的作用,做數據驅動型的SEO,還是需要SEO人員提升自身的相關知識儲備和素質,沒有足夠的基礎知識支撐,SEO人員也就只能是看看統計中的Pv和Uv數據了。
另外,所有的流量數據本身所能反映出的問題都是有限的,只有結合“趨勢”和“細分”才能發現更多更深層次的問題。百度統計中的升降榜及GA中的多維度高級篩選都是流量分析中的高級助手。多分析,多發現,多成長。
 
日志分析:日志分析也是SEO工作中比較重要的數據分析工作,SEO人員都知道這一點。但是和流量分析不同的是,部分SEO人員還知道使用流量統計工具看一下網站的Pv和Uv數據,但是從來沒有看過或者還不懂得如何看網站訪問日志。日志文件對網站的所有訪問行為都有記錄,日
志文件中的數據比普通流量統計工具中的數據更加全面、精確,但是通過日志來分析網站的流量數據需要借助特定的工具,技術大牛一般會自己寫腳本跑整個日志文件以獲得自己所需要的數據報表,并且與GA和百度統計這樣的工具相對比,使用網絡上的日志分析軟件所得到的網站流量數據和報表往往可分析性會差很多。所以如果不懂相關的技術,還是使用普通的流量統計工具來統計分析流量吧。
對于大眾SEO人員來說,對網站日志的分析,更多地還是針對搜索引擎Spider抓取行為的分析,當然技術大牛同樣可以自寫腳本獲得自己需要的日志分析報表,大眾SEO人員還是通過類似前面介紹的《光年SEO日志分析系統》來進行日志分析工作吧。本節以《光年SEO日志分析系統》和IIS W3C格式的日志為例,簡單從SEO的角度討論一下日志分析相關的內容。和流量分析中重復的內容不再冗述,比如用戶瀏覽器使用情況等。
SEO基礎知識:SEO工作中與日志相關的基礎知識包含日志中各字段的含義和狀態碼的含義。現在網絡上有很多相關知識的介紹,在此為了章節內容的完整性,對相關內容也進行簡單的介紹。現在很多經常做日志分析的SEO人員,并不完全明白日志文件中各字段的含義,對不常見的狀態碼同樣不是太明白,當遇到相關問題時,才會重新查詢相關知識。
IIS W3C格式的日志中常用的字段有:date, time, cs-method, cs-uri-stem, cs-username, c-ip,cs-version, cs(User-Agent), cs(Referer), sc-status, sc-substatus, sc-bytes。這些字段各自的含義及SEO人員所應該了解的內容如下。
1.date:發出請求時候的日期,也就是年月日。在日志分析中,一般會提取一天的日志進行分析,并且大部分網站都是按天生成日志的.。所以日志分析中的這一列數據基本都是相同的。
2.time:發出請求的時間,也就是時分秒。這個字段可以分析出搜索引擎對整站或指定內容的抓取頻率。
3.cs-method:請求中使用的HTTP方法,值為GET或POST, GET是向服務器索取數據的一種請求,POST是向服務器提交數據的一種請求。搜索引擎對網站的訪問一般不會自動提交數據,所以搜索引擎Spider的抓取記錄的狀態基本上都是GET,
4.cs-uri-stem:訪問的URL,也是日志分析中的主體對象。
5.cs-username:用戶名,訪問服務器已經經過驗證的用戶名。搜索引擎Spider的訪問一 ‘一般是匿名的,匿名在日志中會以氣”表示。c-ip:客戶端IP地址,也就是訪問者的IP。如果及時發現同一IP地址頻繁地訪問網站,可能會是采集器,可以經過分析確定后加以封禁。
6.cs-version:客戶端使用的協議版本,值為HTTP或FTP,搜索引擎Spider為HTTP,不必在乎此字段。
7.cs(User-Agent):用戶代理,客戶端瀏覽器、操作系統等情況。搜索引擎Spider也會在此字段表明身份,也會有一些假Spider混跡其中,比如站長工具一般都有模擬搜索引擎Spider抓取的功能,這種訪問就會產生假的搜索引擎Spider訪問。現在擁有外鏈查詢的站長工具,為了防止網站封禁IP,也會冒充成搜索引擎Spider訪問網站。SEO人員可以統計各種搜索引擎對網站的抓取情況,屏蔽無流量的搜索引擎或工具的抓取,以減少網站的服務器和帶寬壓力。
8.cs(Referer):訪問來源,即普通引薦流量中的引薦頁面,如果沒有來源,則會以“一”表示。在搜索引擎基礎知識章節中己經詳細講過,搜索引擎Spider并不會從一個頁面爬到另一個頁面,所以Spider對網站的訪問都是直接訪問,因此搜索引擎Spider對網站的訪問記錄中該字段都是“一”。
9.sc-status:協議狀態,記錄HTTP狀態碼。200表示成功訪問、404表示找不到網頁、
10.301表示永久重定向等,這個字段是需要SEO人員尤為關注的字段,后續會對各種狀態碼進行簡單介紹。
11.sc-substatus:協議子狀態,記錄HTTP子狀態碼。一般網站都不使用子狀態,所以這個字段的值一般為00
12.sc-bytes:服務器發送的字節數,可以理解為文件的大小。

以上為日志文件中常見的字段,還有一些字段如cs-bytes表示服務器接受字節數,這些字段對SEO來說幾乎沒有什么分析價值,所以不再介紹。需要了解的是,網站日志中的所有字段記錄與否及字段的排序都是可以在服務器上配置的,所以并不是所有的服務器日志的字段都會按以上順序排列。在以上介紹的字段中。協議狀態碼是SEO比較關心的數據,根據需要,常見的狀態碼簡單介紹如下。
1.200:表示訪問成功,訪問正常。
2.301:表示資源永久重定向,即向搜索引擎表示該網頁已經完全轉移到另一個網頁,告訴搜索引擎該網頁的相應權重需要疊加到另一個網頁上,并刪除該網頁的索引。雖然百度站長平臺已經推出了網站改版工具,但是現在對于301的支持還是比較緩慢。由于301有疊加權重的作用,所以有不少人利用大量子域名301到某一個固定網頁以提升該網頁的權重,簡稱“301作弊”。
3.302:表示資源暫時轉移,如果網站改版,建議使用301而不是302, 302作弊曾經流行過一段時間,已被搜索引擎打擊,其實現在302作弊依然存在,正規網站不必過多關注此狀態碼。
4.304:網頁無變化,如果搜索引擎Spider訪問返回304,可能會造成Spider訪問該頁面的頻率降低。
5.404:資源未找到或已刪除,有的服務器在數據出現讀取錯誤時,會默認返回404狀態碼,對SEO非常不利,應該改為503。同時所有404狀態的訪問都應該引起站長和SEO人員足夠的重視。
6.503:服務器過載或暫停維修,建議網站出現突發事故時最好默認返回503,未建好的網頁也最好返回503而不是4040

以上為日志分析中常見的狀態碼,在日志中還有其他很多狀態碼,SEO人員最好都了解一下,但是不熟知其他狀態碼表示的含義也沒有多大關系,按照開頭數字對狀態碼的含義總結如下。
1**:表示請求己經收到,需要繼續處理。
2**:表示請求己被服務器成功接收、分析。
3**:表示客戶端需要進行進一步操作才能完成請求。
4**:表示請求包含語法錯誤或不能完成。
5**:表示服務器錯誤。
在日志分析中,4**和5**的狀態碼是需要足夠重視的。在實際工作中,經常會把404狀態碼的訪問記錄單獨提取出來進行分析;會搜索日志中503之類的服務器錯誤,來查看指定時間段服務器是否出現宕機、帶寬使用是否超過限制等。

確定目標和精簡樣本:不僅是日志分析,所有的數據分析工作都應該有其目的性,不然就失去了分析的意義。SEO人員分析日志一般有兩個目標:了解網站內容和鏈接是否正常、了解搜索引擎Spider對網站的抓取情況。前者是為了發現網站運行中的問題并加以修復,保證網站的良好運營;后者是為了發現搜索引擎的抓取規律,并分析是否有優化的空間,引導搜索引擎多抓取指定重要內容而弱化對無關緊要頁面的抓取,一般會配合搜索引擎對網站的收錄情況進行分析。
因為網站日志記錄了網站的所有訪問數據,所以稍有規模的網站的單天日志可能會很大,少則幾百MB多則幾個GB。作為SEO人員,平時只需要分析搜索引擎的抓取情況就可以了,如果網站存在服務器錯誤和頁面404之類的錯誤,一般都會在搜索引擎抓取中遇到,并且較普通用戶的訪問,搜索引擎的抓取可能更加全面。所以在進行日志分析前,可以根據分析目標先對日志進行精簡,比如只提取出百度Spider和Googlebot的抓取記錄來進行分析。當然也可以根據分析目的只提取指定時間段、指定IP、指定瀏覽器、指定來源頁面或指定狀態碼的記錄。根據分析目標把日志分析范圍縮小和精簡,可以大大提高分析效率及提升分析工作的質量。如果你想查看是否有垃圾爬蟲或對網站運營無關的工具批量訪問的IP,進行封禁以降低服務器和帶寬的浪費,還是需要即時查看日志或分析整個日志文件的。
發掘死鏈接及網站異常:
1.發掘死鏈:百度一直在強調站長應該重視站內死鏈接,并在百度站長平臺推出了死鏈提交工具。因為搜索引擎的Spider在抓取之前并不知道鏈接是不是死鏈接,所以對于死鏈接也是正常抓取。如果由于網站程序錯誤或批量刪除了一些頁面,就可能白白浪費掉搜索引擎Spider的抓取;由于單位時間內搜索引擎對一個網站的抓取是有上限的,所以站內過多的死鏈接會影響到搜索引擎對正常內容的抓取;如果網站批量刪除了一批頁面,且這些頁面在搜索引擎中是有排名的,眾所周知搜索結果中的網頁出現404是對搜索用戶體驗的最大傷害,所以針對這種情況搜索引擎一般是嚴格控制的,如果網站中突然大量有排名的網頁出現404的情況,搜索引擎可能會認為網站整體的運營有問題,從而降低網站整站的搜索表現。可見站在網站的角度,死鏈接也是必須清理的,但是主動地去尋找這些死鏈接并不是一件容易的事。
雖然現在可以通過xenu來批量發掘網站的死鏈,但是對于網頁數量比較大的網站這樣做是非常消耗資源的,并且如果網站頁面數量過多,在普通PC上跑xenu會經常造成軟件不響應甚至電腦死機的狀況。如果是批量刪除網頁所產生的死鏈,可以根據刪除規則批量生成URL,如果是其他原因產生的死鏈,就只能通過類似的批量抓取驗證來尋找了。
其實完全可以通過日志分析尋找死鏈。因為站外拼寫錯誤之類的原因所產生的死鏈接總是有限的,這種鏈接也不是站內產生的,所以沒有必要過于關注。而如果網站存在大量的死鏈接,那么這些死鏈接的產生肯定有特定原因的。分析少量樣本發現死鏈接的規律,并尋找產生死鏈接的根本原因,尋找網站中存在這些死鏈接的頁面,之后不論是修補錯誤還是批量生成死鏈接列表都不是太大問題了。所以發掘網站內的死鏈接只需要分析一定的死鏈接樣本就可以了,由于搜索引擎每天都會抓取一定量的網頁,所以分析網站日志中搜索引擎抓取的記錄就可以了,或者分析整個日志中的404狀態的訪問都可以。
2.發掘網站運行異常情況:一般是分析網站是否出現過服務器錯誤或誤刪資源的情況,也就是分析日志中狀態碼為5**和404為主的記錄。根據5**狀態的記錄,分析網站是否出現過異常,根據出現異常時間分析可能的原因并予以解決。根據404狀態的記錄,分析網站中是否有誤刪的圖片和資源或CSS及JS文件等,如果相應的圖片和資源訪問用戶過多,根據需要考慮是否恢復刪除的圖片和資源,以保證用戶體驗良好;如果相應的CSS和JS當下還被網站中不少頁面使用著,那么就要設法恢復相應文件,以彌補網站網頁樣式錯亂或功能出現錯誤。
另外,在網站程序一切正常的情況下,搜索引擎也可能會抓取一些奇怪的站內不存在的鏈接,這一般是由外鏈造成的,如果站長發現搜索引擎Spider抓取了過多的404頁面,并發現這些頁面都是站內不可能存在的,那就要分析一下這些外鏈產生的原因了,有可能是網站分享程序有問題,也有可能外鏈建設過程中由于某種意外使用了大量錯誤鏈接,需要根據實際404的URL進行具體分析。當然除了搜索引擎抓取的404頁面外,在日志中也會經常看到黑客掃描網站漏洞產生的404訪問記錄,雖然站在SEO角度這并沒有什么可分析的,但是為了網站安全還是需要多加注意。
通過日志分析還可以發現網站是否有意料之外的重定向,比如有的網站因為泛解析問題,會導致用戶訪問不存在的頁面www.za9bao.com/abc時,網站會自動301或302跳轉到子域名abc.smiseo.com,如果該域名不存在,服務器或返回網站首頁內容,或返回404狀態碼。這種錯誤在日志中提取301, 302及404狀態的記錄都可以很容易地發現。除了200之外的狀態碼稍微過多就需要高度注意,仔細分析其產生的原因,并找出解決問題的辦法。
在日志分析中什么千奇百怪的問題都可能遇到,有時可能服務器設置錯誤,刪除的內容也會返回200狀態碼,這些都需要SEO人員仔細分析網站的日志文件才能發現。站長在日志分析過程中,可以使用《光年SEO日志分析系統》的日志拆分功能按照需求進行提取,以輔助分析。如果沒有明確的分析目的,那么日志分析工作就是在日志文件中找尋一切異常的記錄,并深挖異常記錄產生的原因,從而為網站解決一些潛在的問題。

Spider抓取情01119和b:搜索引擎Spider對網站的抓取情況,應該是最值得SEO人員研究的內容。但是很多SEO人員面對已經在日志中提取出來的搜索引擎抓取記錄,并不知道需要分析什么。這里簡單討論一下Spider對網站的抓取情況都有哪些方面是值得分析的,以及分析出的結果是如何指導SEO工作的。
Spider的抓取數據可以分析:Spider對整個網站的抓取頻率、Spider對重要頁面的抓取頻率、Spider對網站內容的抓取分布情況、Spider對各種類型網頁的抓取情況、Spider對網站的抓取狀態碼情況等。
1.通過分析Spider對整個網站的抓取頻率的趨勢,可以簡單了解網站在搜索引擎眼中的質量。如果網站沒有進行過大幅度的變動,并且內容正常更新,搜索引擎的抓取頻率卻逐漸或突然大幅度降低,不是網站運行出現錯誤,就是搜索引擎認為網站質量出現了問題;如果搜索引擎的抓取頻率突然增大,可能是網站有404之類的頁面引起了Spider的集中重復抓取;如果搜索引擎的抓取頻率逐漸增大,可能是隨著網站內容的逐漸增多,權重的逐漸積累,而獲得的正常抓取。持平和平緩的變動不足為奇,如果出現大幅度的變動,就需要引起足夠的重視了。
2.通過分析Spider對重要頁面的抓取規律,可以輔助網頁內容更新頻率的調整。一般搜索引擎Spider會對站內的重要頁面進行高頻度的抓取,這類頁面一般不會是內容頁,而是首頁、列表頁或者擁有大量外鏈的專題頁。
提取的百度Spider對某網站nbc.html頁面的抓取情況,該頁面為該網站的最新內容頁面,即專門為搜索引擎發現網站內的新內容所準備的頁面。該頁面中有300個鏈接,每5分鐘更新一次,并且已知5分鐘內網站所產生的新頁面要遠遠超過300個,也就是說并不是所有新產生的頁面都會在nbc.html中出現。根據圖10一中百度Spider對該頁面的抓取情況可以看出,最多間隔不到2分鐘百度Spider就會抓取一次該頁面,然而該頁面的更新頻率為5分鐘,也就是說百度Spider有超過一半的抓取次數并沒有獲取到新鏈接,并且網站新內容的鏈接也沒有完全在該頁面上展現一遍。根據這種數據差,就可以指導SEO人員推進技術人員對該頁面的緩存時間的改進,增大更新頻率,可以把更新頻率設置為2分鐘一次,這樣不僅可以使百度Spider每次對該頁面的抓取都獲得新鏈接,同時也可以增大網站新內容被百度發現的幾率。
在網站中有很多種此類抓取頻率非常大的頁面,比如前面所說的網站首頁、目錄頁和專題頁。在網站中往往還會有其他更多類型的聚合頁同樣有著比較大的抓取頻率。尤其是網站的首頁,很多網站的首頁每天都會得到搜索引擎成千上萬次的抓取,但是不少網站首頁上更新的鏈接很少,有些浪費了首頁本身權重所帶來的Spider高抓取頻率。在不影響SEO關鍵詞密度和布局的前提下,SEO人員可以充分利用這部分資源,來使網站內所有的新內容都被搜索引擎及時發現,也減少搜索引擎的無效抓取。
雖然現在通過百度站長平臺的sitemap工具,可以直接把站內的URL提交給百度,并不需要太過擔心百度發現不了網站內新內容的問題,但是現在也有部分網站是沒有sitemap提交權限的,并且這種通過頁面發現鏈接的形式還會帶有一定的權值傳遞。眾所周知,網頁的收錄與否,除取決于網頁內容的質量外,與網頁所獲得的外鏈和網頁的權重也是有關系的,所以以上分析和改進還是值得進行的。
3.分析Spider對網站內容的抓取分布情況。每個網站都會分出一些不同的頻道,可能大家感覺在網站內鏈和外鏈的建設中并沒有特別的偏向,或者為某個頻道做了很多鏈接,就認為該頻道應該會得到搜索引擎的青睞,但是事實可能不是這樣的。Spider對網站內容抓取分布情況的分析一般會結合網站的收錄數據,分析網站各頻道內容的更新量、搜索引擎收錄量和Spider對各頻道的每日抓取量是否成正比。
如果某個頻道的搜索引擎收錄不佳,首先就要分析搜索引擎對該頻道的抓取是否正常。比如分析百度對網站各頻道的抓取情況,可以使用《光年SEO日志分析系統》先把百度的抓取記錄提取出來,然后使用該工具對提取出來的日志進行分析。在該工具生成的報表中有一個“目錄抓取”的報表,可以輕松獲得百度對網站目錄級別的抓取。也可以通過該工具的日志拆分功能,拆分出百度對網站每個頻道的抓取情況,然后進行詳細分析。
通過這種分析可以很輕松地了解到百度對網站內各頻道的抓取情況,會經常發現收錄不佳的頻道得到的抓取次數也很少,或者會發現百度對該頻道內容頁的抓取情況不佳。此時就需要調整網站內的鏈接分布,或者使用nofollow標簽來弱化百度對不重要頻道的抓取,而引導百度多抓取指定的頻道。如果搜索引擎的收錄并沒有異常,百度對內容的抓取分布情況也是值得分析的,研究百度抓取量大和抓取量小的頻道之間的差別,從而了解百度Spider的喜好,進而對網站結構或者內容建設方法進行改進。
4.分析Spider對站內各類頁面的抓取情況。不同網站都有著自己不同的網頁類型,這里進行舉例說明。在大眾網站中一般會有首頁、目錄頁、文章頁,目錄頁和文章頁可能會有分頁,但是經過分析百度Spider的抓取記錄后,可能會發現百度Spider幾乎不怎么抓取分頁,不論是列表分頁還是文章分頁。
如果網站更新量比較大,每天更新的內容會在列表新增很多分頁,就可能造成百度不能及時發現網站新內容的情況;如果網站的文章的內容量都比較大,并且分頁也是經過精心設計的,每個分頁都有一個核心的小主題,這種文章的分頁也是有收錄價值的。為了解決這兩個問題,可以在網站上建立不進行分頁的“最新內容”頁,然后引導百度Spider頻繁抓取該頁面;把文章的分頁的URL格式和文章首頁的URL統一,并在列表頁或上述“最新內容”頁進行推薦。先保證百度發現這些頁面才能進一步促進百度對有價值分頁的抓取和收錄。
5.分析Spider對網站的抓取狀態碼情況。除了上面所提到的注意網站異常的狀態碼,還應該留意Spider對網站的抓取記錄中是否還有其他不常見的狀態碼出現。2012年12月9日(星期日)百度Spider對某網站首頁的抓取記錄。因為周末沒有人更新網站,所以網站首頁內容全天是無變化的,造成了百度Spider抓取全部返回了304狀態碼。這樣一段時間后百度Spider就會發現網站的首頁更新規律了,以后即使周末有更新內容也不會得到百度的及時抓取和收錄了。所以,雖然這不會對網站的排名造成直接的負面影響,但是如果以后整個周末百度Spider都不來抓取網站,以至于以后在這個時間段內發布新內容都不再被及時收錄,那多少都有點悲催了。面對這種情況,SEO人員一般都會策劃根據Spider抓取頻率在相應的時間對頁面做出一定的更新,以保證搜索引擎Spider持續地抓取網站。根據具體情況或加大內容發布量,或為頁面增加最新內容的調用,或為頁面增加評論類的動態內容等。當然諸如大部分內容頁返回304是很正常,需要具體情況具體分析,并沒有必要單純為避開對Spider返回304狀態碼而刻意改變網頁內容。
在分析日志的過程中,所有的狀態碼都有可能會發現,都需要根據狀態碼的實際含義及網站的實際狀態進行分析,從而考慮是否需要改變現狀,以保證網站在搜索引擎上的良好表現。
以上只是簡單討論了一下日志分析中常見的分析目標、方法及對SEO的指導性作用,在網站日志中還可以分析出很多問題,當網站遇到搜索引擎相關的問題時,也應該優先分析搜索引擎對網站的抓取日志。網站運營過程中可能會遇到很多千奇百怪的事,SEO人員就需要多遇問題,然后進行分析、思考和解決,從而提升自己。如果有能力,可以開發一個小程序監控網站日志,以方便分析每天搜索引擎對網站的抓取記錄中的常規數據:Spider總抓取URL的條數、
Spider抓取唯一URL的條數、各種主要狀態碼出現的次數、網站主要頁面的抓取次數、站內各類頁面的抓取次數等。同流量分析一樣,可能單天的數據所能說明的問題有限,長期監控并做成趨勢圖,就可以及時發現搜索引擎Spider對網站抓取過程中的很多問題了。當然這種監控只是輔助及時發現問題,具體的問題分析還是需要提取到相關記錄,進行逐層細分分析。
 
收錄、排名、站內搜索數據分析:在前面競爭對手分析一章中已經簡單提到過收錄排名數據的監控了,由于那是站外分析,所以數據在很大程度上是不準確的。SEO人員對自己的網站應該進行全面的了解,不僅要詳細了解網站的收錄和排名,對網站用戶的站內搜索數據也要進行細致的分析和研究,進而才能了解網站自身哪些方面存在明顯的不足,哪些方面已經擁有絕對的優勢,從而更好地指導SEO的工作。

收錄和排名統計分析:對于站內的數據,SEO人員最起碼需要統計網站各頻道及各類型頁面的收錄情況,通過site.inurl指令及百度站長平臺的索引量查詢工具可以獲得相關數據。雖然site和inurl所得到的數據并不準確,但是體現在時間軸上的大趨勢應該是正確的,這些數據的趨勢可以讓SEO人員隨時了解網站各方面內容的收錄情況的變動,一旦網站的收錄量出現異常,可以方便地追查到具體是哪方面的內容或哪些類型的頁面出現了問題,是內容問題、模版問題還是鏈接問題,這些都很容易進行分析。
和搜索引擎收錄量相對應,SEO人員也應該掌握網站各頻道及各類型頁面的實際數量,和搜索引擎的收錄量進行對比,可以發現網站頁面的收錄比例有多大。這個收錄比例在時間軸上的趨勢可以反映出相應時間段內網站內容的質量有所提升還是下降。前面在Google Webmaster的介紹中,介紹了“索引狀態”工具,這個工具就有這方面的作用,百度站長平臺還沒有類似工具的推出,所以只有靠站長和SEO人員自己來進行數據統計和分析了。
除了以上數據的跟蹤統計外,SEO人員還應該了解到網站每天新增內容的搜索引擎收錄比例是多少。如果網站每天所產生的新頁面并不是太多,完全可以讓技術人員寫個腳本批量地在搜索引擎中查詢這些新頁面的URL,查看是否收錄及收錄比例,也可以使用站長工具介紹章節中所提到的“批量查詢URL百度收錄情況”的工具進行查詢和統計。如果每天新增大量內容,但是搜索引擎并不收錄,就有點兒悲催了。收錄比例突然出現異常,也可能是網站出現了某些問題,都需要根據實際情況進行分析,比如分析每天的新內容是否都被搜索引擎所抓取,未被收錄的內容和已被收錄的內容頁面之間有什么區別等,來指導調整SEO工作的方向。

比對搜索引擎收錄情況和相應的網站中實際網頁的數量,發現收錄相對不理想的頻道或特定類型的網頁。這種頁面是有足夠的收錄提升空間的,此時就按照上一節日志分析中提到的那樣,.先確定網頁類型,然后分析日志抓取情況擴進而調整站內鏈接或設置專門推薦這些網頁鏈接的頁面,來促進搜索引擎發現這類網站的鏈接。當然也有可能是網頁內容的問題,需要根據實際情況做出相應的分析。

針對關鍵詞排名方面,SEO人員應該跟蹤統計網站所有核心關鍵詞的排名變化情況。同時也利用流量統計工具統計每天的搜索詞數量,以及搜索流量中的著陸頁數量。這些數據的單日數據可能并不能反映出太多問題,但是在時間軸上建立趨勢圖就可以反映出很多問題了。比如搜索流量中的著陸頁數量,代表了網站內有多少搜索有效頁面,這個數值占網站總網頁數的比例越大,代表網站的“無效頁面”越少,搜索引擎越認可網站的內容。如果這個數值占網站總網頁數的比例很小,代表網站中大部分網頁是不能從搜索引擎上帶來流量的,如果網站沒有發展其他推廣方式,這些頁面甚至都可以被當成垃圾頁面了。這個比例在時間軸上的趨勢,可以反映出網站在SEO方面是否是良性發展的,當然也要根據網站的類型進行具體分析。

站內搜索統計分析:雖然大多數網站都配有站內搜索的功能,但是有相當一部分網站并沒有統計和分析網站用戶的站內搜索數據。對于運營人員來說站內搜索用戶在站內的所有行為都非常值得進行跟蹤和分析。但對于SEO人員來說,站內搜索的搜索詞才是最重要的數據,在第4章中也提到過,通過分析站內搜索詞可以分析網站用戶對網站內容和功能的需求。在搜索引擎中,用戶搜索是想通過搜索引擎找到自己所希望得到的信息;在網站中,用戶的搜索目的雖然和在搜索引擎中沒有什么太大的區別,但是對網站的意義就有所不同了。
“站內搜索”這個行為的產生一般會有這幾類原因:一是用戶經過瀏覽,沒有在站內找到自己所需要的信息;二是用戶認為網站應該有自己所需要的信息,但是懶得通過網站導航尋找;三是站內搜索結果頁的展現形式更符合用戶的瀏覽需求等。前兩個原因一般都是用戶在了解了網站主題的前提下又發起的站內搜索,此時站在網站的角度就應該盡力提供用戶所需要的這些內容,所以通過分析用戶的站內搜索詞可以發現網站內容的不足,并了解網站目標用戶的內容需求,從而指導網站內容的建設工作。
如果感覺自己開發站內搜索數據統計分析功能比較吃力,就可以使用Google analytics提供的比較給力的站內搜索分析功能,基本上可以滿足大部分網站對站內搜索數據的統計和分析需求。在Google analytics的“管理>>配置文件>>配置文件設置”中可以很容易地找到統計站內搜索的設置,經過簡單配置就可以輕松獲得用戶站內搜索的數據及多個數據分析報表了。如圖10-7所示,設置好“查詢參數”就可以統計用戶的搜索詞和相關數據了,如果站內資源有進行分類,并且在搜索的URL中有所體現,那么就可以配置好“類別參數”,以便更細分、更精準地分析用戶站內搜索的數據。只要簡單配置好這兩個參數,就會給網站增加一個強大的輔助用戶數據分析的功能。
Google analytic的站內搜索分析,在給出了站內搜索用戶的一系列數據報表之外,還會給出使用站內搜索的用戶與沒有使用站內搜索用戶之間的數據比對,同時還支持站內搜索用戶特有的數據與普通流量數據的交叉分析,功能非常強大。對站內搜索詞報表,使用了流量來源為關鍵詞的次級緯度過濾,通過綜合此報表及相關數據可以進行如下分析:用戶通過在搜索引擎搜索這些關鍵詞進入網站后,著陸頁內容并沒有滿足用戶的需求,用戶又在站內發起了相應的搜索,比對來源關鍵詞和站內搜索詞之間的區別,并分析這些關鍵詞的著陸頁內容,就可以分析出相應著陸頁內容的不足或網頁關鍵詞定位的失準等,并可以根據以上數據研究相應用戶的真實需求,以指導日后網站常規SEO方向及校準用戶需求、內容建設和關鍵詞定位三者之間的對應關系等。
站內搜索有太多的數據值得分析,每種數據報表都有其特定的意義和作用。同樣Googleanalytics中還有很多的數據、報表和功能值得大家研究,有興趣或需要的朋友可以自行配置嘗試使用一下,太多的功能和數據需要大家親自使用之后才能體會到它的強大。
 
awk:awk:是一款功能非常強大的數據處理工具,是一種用于文本處理的編程語言工具,如果對其進行詳細介紹,完全可以寫一本書了,在此我們只是簡單了解一下它的初級應用,這款工具在SEO的日志分析工作中是最為重要和方便的。
awk其實是早期UNIX中的文本處理工具,后來GUN做了gawk, gawk包含了awk的所有功能,現在很多地方都使用gawk代替了awk。在常見的Linux系統中,為了保留大家使用awk的習慣,系統做了一個軟鏈接,將awk指向gawk,因此在大部分系統中使用awk其實調用的是gawk程序,在Cygwin中也不例外,因此在Cygwin中可以使用awk,也可以使用gawk,可以認為awk是gawk的一個簡短的別名而已。不過在DOS下使用UnxUtils包中的命令時要使用gawk,因為在UnxUtils包中只有gawk.exe程序,系統中又沒有把awk指向gawk.exe,所以在DOS窗口下并不能直接使用awk(如圖10-31所示)。當然為了自己的習慣,也可以在UnxUtils包中直接把gawk.exe改名或復制并改名為awk.exeoawk在SEO中最為突出的功能就是支持對字段的處理,可以按照指定字符把每行數據分成字段的形式,然后按照字段數據做出相應的處理。眾所周知日志文件中的數據都是以空格分段的,因此awk會在日志分析工作中起到很重要的作用。awk的基本格式如下:
awk -F pattern {action}
-F后面跟的是分隔符,也就是以指定的符合來對每一行要處理的數據分段,默認為空格。pattern模式,也就是action執行的條件,當命令中缺少pattern時,awk會對每行數據都執行action。在SEO中經常用到的pattern形式有:/正則表達式/,關系表達式,模式匹配表達式。
action即執行的操作,一般是按照一定格式打印出所需要的數據。當命令中缺少action時,即打印出整行符合條件的數據。
在awk中,使用$n來記錄第n段數據,n為整數;$0表示整行數據;NF為當前記錄中的字段數,$NF可以用來表示最后一個字段。
建立了一個文件8.txt,里面有三列數據:關鍵詞、指數和百度搜索結果(數據為隨便虛構的),下面通過對此文件中數據的處理來演示一下awk的使用方法。條件為正則表達式:在&txt中提取以“SEO”開頭的整行數據,“//”中為正則表達式條件,$0為整行數據。打印整行數據時可以省略action,也就是可以使用第二種形式。
條件為關系表達式:第一條命令為在8.txt中提取指數大于1000的數據行;第二條命令為在8.txt中提取指數大于1000的數據,且只需要提取關鍵詞和指數數據,并不需要提取百度搜索結果數。$1記錄的是數據的第一個字段即關鍵詞,$2記錄的是數據的第二個字段即指數,在action中使用“,”分割兩個變量,結果中會表現為空格,如果不加“,”,則兩列數據會緊貼到一起。第三條命令表示變量之間也可以進行運算,意思是在8.txt中提取指數和百度搜索結果數的比值大于0.001的數據(在一定程度上表示可優化價值),只提取關鍵詞不需要其他數據。
條件為模式匹配表達式:圖10-35中的兩條命令分別表示為提取8.txt內關鍵詞中包含和不包含“SEO”的數據。“一”為匹配,+,”為不匹配。

本節對于awk的介紹就到此為止,以上只是awk最基礎的應用,由于awk本身支持數組和支持格式化輸出的特性,以及其和流程控制命令(if, while, for)及其他命令的組合使用會有更強大的效果和更高效的應用(比如前文中提到的去重),有興趣的朋友可以自行研究一下,有任何疑問都可以搜索一下,基本上每個命令和每種簡單的數據處理效果都可以在百度或Google上找到相應介紹。相信經常分析日志的朋友己經感覺到了awk的作用。另外,需要注意的是在DOS中使用awk時,需要把命令中的單引號換成雙引號,否則會出錯。
至此最為常用的一些文本處理工具己經介紹完了,大家至少可以使用以上命令和工具對日志和關鍵詞之類的數據進行一定的個性化處理,不用依賴于其他相關工具了。如果以上介紹勾起了你學點Shell命令的興趣,那你除了更深入了解以上命令和工具外,還可以了解一下join,tr, cut, dill, sed, lynx, curl等命令和工具以及正則表達式,相信這些命令和工具會大大方便你的工作。
最后提醒一下,Linux和Windows默認支持的文本格式是不同的,Linux一般為UTF-8Windows一般為ANSI。當使用DOS處理UTF-8格式的中文文本或使用Cygwin處理ANSI格式的中文文本時會出現亂碼的情況,此時可以使用Editplus編輯文本另存為指定格式,也可以使用轉碼工具對文件進行轉碼。不過當需要處理的文件過大時,轉碼會很麻煩,因此筆者一般習慣保持電腦可以同時使用Cygwin和通過DOS使用UnxUtils包中的命令,平時會使用Cygwin,當出現亂碼情況時就臨時使用一下DOS,這也是為什么DOS在使用中有些特殊情況比Cygwin要麻煩一些,卻還是要介紹DOS的原因(有時因為文本進制問題,DOS并不能正常直接處理,使用UTF-8格式然后使用Cygwin處理,兼容性會更好一些)。
 
在日志分析中的應用:這些Shell命令在日常工作中有著很重要的作用,基本上可以用于對所有文本數據的處理,但對于SEO人員來說,其作用經常體現在日志分析工作中。日志分析主要分析搜索引擎對網站的抓取情況。下面就簡單演示一下前文介紹過的基礎Shell命令在日志分析中的應用。筆者提取了某一網站兩天的日志文件進行演示。
1.首先查看一下日志文件中的數據格式以空格劃分字段,被訪問的URL為第7字段,狀態碼為第9字段,服務器所發送的字節數為第10字段。
2.查看百度對網站的總抓取數量也可以根據其他搜索引擎spider的名字查看其他搜索引擎對網站的抓取情況。百度在這2013年4月20日和24日分別對網站抓取了841 331次和719 804次,兩天對比百度對網站的抓取少了近1/8,有下跌跡象。只看兩天的日志并不能說明太多問題,在實際工作中,可以多比對幾天查看百度抓取數量的日志,觀察百度對網站總抓取次數的變化,突升突降或持續下跌都有可能是網站出了問題,如果有問題則需要細分分析下去。(現在也可以通過百度站長平臺的“壓力反饋”工具得到抓取次數的趨勢數據)。
3.查看百度對網站的唯一抓取量,即查看百度一共抓取了網站多少唯一URL首先提取日志文件中的百度抓取記錄,然后在百度抓取記錄中只提取被抓的URL,再對被抓的URL排序和去重,最后統計去重后也就是被唯一抓取URL的數量。合并統計一周或一個月的唯一抓取量,然后和網站實際URL數進行對比,可以以此簡單作為百度對網站頁面的抓取比例,抓取比例越大越好,如果太小,可能是網站結構存在一些問題以至于百度并不能很好地抓取全站內容。在實際工作中會對這部分分析工作細分到網站的各個模塊或產品,以確定百度對網站各個模塊或產品的抓取情況,再結合百度對各個模塊或產品的索引情況進行綜合分析。
后面的幾條命令主要演示通配符和幾條命令的靈活使用,圖中所使用的命令在前文都己有過詳細介紹。通配符可以使得輸入更加方便;充分利用命令的功能可以提升數據處理速度。相對來說,同樣處理效果的命令行中,使用管道“}”的數量越少效率越高,再加上awk工具本身處理數據的效率就很高,因此圖10-38中在對目標文件合并后處理的幾條命令行中,最后一條的處理效率一般是最高的(其實,如果大家對awk工具中的數組使用理解比較透徹,那么最后一條命令還可以進一步簡化為“awk `/Baiduspider/&&!a[$7]++ {print $7}'2013.4.2 *.1oglwc -1",使用一次awk直接對URL字段進行去重,更為高效)。
4.查看百度抓取最多的前n個頁面,并查看這些頁面每個頁面被抓取的次數uniq命令的“一。”參數可以在數據行之前輸出該行數據的重復次數,也就是可以得到咱們需要的URL被抓取次數;sort命令的“-n”參數可以讓數據按照數值排序,前文有過介紹,如果需要數據按照數值排序,當數據行開頭的數字超過10時就需要使用“-n”了。
"-r”參數可以使得數據從高到低排序。這樣就可以使得被百度抓取的URL按照被抓取次數從高到低排序了。最后使用head命令提取我們需要查看的前幾條URL的抓取次數(頻率)情況。

數據可以看到,被抓取次數比較多的基本上都是主要頻道頁,大部分網站都會是這種情況。根據這個數據可以調整相關頁面上內容更新的周期或數據緩存周期,以便于百度可以抓取網站更多新內容;如果發現有一些頻道頁面的更新頻率不是很大,頻道下內容也不是很多(可能在站內的重要程度也不高),但是百度對這些頻道頁面的抓取頻率很高,為了提升百度對其他頁面的抓取,可以適當在站內對導向這些頻道頁的鏈接進行nofollow處理。另外注意到提取結果的最后一條URL應該是一個工具頁面,而非內容頁,理論上不應該被百度抓取到,可以進行進一步分析該URL的入口及該頁面的價值,考慮是否需要在robots.txt文件中把該URL對百度屏蔽,以促進百度對網站其他頁面的抓取。
另外,如果此時使用的是DOS,那么“sort -nr”應該改為“sort /r",其實緊跟在“uniq -c"之后的“sort”命令是否使用“-n"’參數結果都是一樣的。
5.統計百度抓取網站時的各個狀態碼的數量由第一步中己經知道,在要分析的日志文件中狀態碼為第9字段,因此只要提取百度抓取記錄第9字段的數據處理即可。如圖10-40所示,相信大家都已經很清楚這條命令行的意思了,不再過多解釋。注意到數據中404的比例是比較大的,如果網站是新聞媒體類網站,每天很少刪除內容,那么這個數據就可能代表網站程序出了問題,需要具體細分分析;如果網站是分類信息等UGC類的網站,因為每天都要刪除大量垃圾內容,所以這個數據相對來說是比較正常的,不必過于擔心。還注意到數據中301的比例也比較大,這需要根據網站具體情況具體分析,如果網站剛剛改版,301的數量過多也是比較正常的,要時刻注意這個數據的變化,在網站正常的改版過程中,301的數量應該是從改版后慢慢減少的;如果網站沒有做過任何改動,日志中就突然出現了大量的301,就需要檢查網站是否有URL錯誤或泛解析錯誤等造成服務器自動對這些訪問返回了301狀態碼,根據網站具體情況進行深入的分析。
 
r-i.查看返回某個狀態碼最多的頻道或目錄
在上一步中發現該網站24日404比較多,細分分析一下到底是哪塊返回的404最多。由日志中的數據可以了解到該網站下有大量子域名,那么第一步就需要先查看主要有哪些子域名返回了大量404。第一條命令行首先提取日志中第9段也就是狀態碼字段值為404的URL ($7);然后使用awk以“.”為分隔符對URL進行分割并提取第1字段,也就是域名中第一個“.”之前的數據,也就是子域名名字;最后對數據排序去重提取數量最多的前10條數據。根據第一條命令行的執行結果可以看出」ian。子域名返回的404最多,也是主要問題域名。這個分析就把問題進行了進一步的定位,下面再進行更細分的定位(這一步其實也可以使用“/”為分隔符,然后提取整個子域名,而非只是子域名名字)。
 
首先使用awk把日志中狀態為404且以“jianc”開頭的URL提取出來(“&&”表示“且’夕,“}}”表示“或”);然后使用awk以“/”為分隔符對URL進行分割,并提取第2字段,也就是一級目錄(根據網站結構,也可能會有內容頁);最后對提取的數據排序、去重,提取數量最多的前10條數據。根據第二條命令行的執行結果可以看出‘'jianc”子域名下的“/cp/"目錄是404的主要根源。有了這個分析結果在去網站中相關頻道分析具體產生404的原因,是其他部門對該頻道進行了規模清理,還是這個頻道所在的服務器出現了問題,還是這個頻道本身網站程序出現了問題等。
7.查看百度抓取最多的頻道或目錄
在上面的命令演示中基本上包含了這個需求,首先把日志中百度抓取的URL數據提取出來;然后以“/”把URL進行分割并提取第1字段,也就是域名數據;再對這個數據進行排序、去重,按抓取量由高到低排序。由于此網站子域名過多,筆者只提取了抓取量最多的15個域名。顯示百度對各個域名抓取量之間的比例,基本上和各個子域名下的資源數量的比例是差不多的,因此這個數據表示百度對站內資源的抓取分配還是比較合理的。如果在這個數據中發現不合理的地方,那么就可以通過使用nofollow或robots.txt屏蔽的方式來調整百度對站內資源的抓取。
8.統計百度一共抓取的字節數
在前文查看日志格式時已知服務器所發送的字節數在第10字段,因此只要統計百度抓取的第10字段的數據然后求和就可以了。在實際的日志分析工作中這個需求還是比較小的,這兒使用了BEGIN, END和變量,有興趣的朋友自行問百度或Google吧,此處不再進行詳細介紹了。如果有同樣的需求,直接套用圖10-43中的命令行即可。第一條命令行為統計百度在24日抓取網站的總字節數:第二條命令行做了進一步計算,計算出了百度抓取網站的總兆數。可見百度存24日對該網站總抓取16 414 892 668Bvte,也就是15654.5MB。
有不少朋友的網站是放在虛擬空間中的,可能有些主機提供商會對空間流量做了一定限制,當這部分朋友發現網站實際流量變化不大,但空間流量消耗很大時,可以使用此命令行來查看是否是某個搜索引擎對網站的抓取量太大。一般情況下主流搜索引擎不會無節制地抓取網站,當發現是不知名的搜索引擎Spider對網站抓取量太大時,可以選擇對其進行robots.txt和IP封禁;如果經過分析發現是主流搜索引擎對網站的抓取量過大,則推薦做升級空間的工作。

以上演示基本把日志分析工作中的基本命令應用都涉及了,更為具體和細分的工作就需要大家根據自己網站的數據情況自行研究了。不過要時刻提醒自己,除非自己想轉向技術,否則這些命令只是輔助自己分析數據的工具而已,只要懂得如何使用這些命令分析數據就可以了,并不需要把Shell命令都系統地學習一遍。另外這些命令行只能得出數據,作為SEO人員,需要細分分析數據背后所反映出來的問題,否則這些命令行所得出的數據都是沒有意義的。
另外,在以上演示中筆者都是對原始日志文件進行操作,大家在真正分析日志時,如果只需要分析某個搜索引擎的抓取情況,可以先根據其Spider名字把相關記錄提取到新文件中,這樣就不必每次都對原始比較大的日志文件進行處理,分析速度會提升不少。還有,一般服務器的日志格式是固定不變的,所以以上常規分析的命令行其實可以打包成腳本(DOS下直接保存為批處理文件),每次執行一下腳本就可以把常規數據提取出來,不需要再一行行地重復輸入命令行。例如如圖10-44所示,筆者使用editplus簡單寫了幾行命令,把這幾行命令保存為以“.bat"結尾的批處理文件,然后按照自己所寫批處理的要求把批處理文件和日志放到同一個文件夾下,雙擊批處理文件,就可以得到結果了。
不僅僅是分析日志,日常工作中需要反復進行的數據處理工作大部分都可以做成腳本處理,這樣會大大提升工作效率。比如筆者有段時間喜歡處理關鍵詞,在多渠道獲得的大關鍵詞庫中提取出筆者需要的特定類型關鍵詞,處理步驟比較復雜,涉及去除包含特殊符號、停止詞、明
確不符合要求的詞根,根據所統計的近1500個規范詞根對已經凈化過的關鍵詞庫進行提詞,把按照各種條件抽取的關鍵詞單獨存放待用,并對各個詞庫進行按照指定要求排序等。需要去除、提取的核心字符有近2000個,如果在命令行窗口中進行操作,可能至少需要手動敲2000多行
命令,并且每次敲完命令都要等待命令執行完成之后,才能進行下一步操作,當需要處理的原始詞庫有幾千萬甚至上億數據時,這個等待過程也是非常痛苦的,更別提每次處理數據都要做一遍重復工作了。因此筆者把相應的命令按照順序進行了打包,做成了一個比較粗糙的批處理
文件,在這個過程中重復的命令可以使用 Excel批量生成,把復雜工作盡可能地簡單化了,同時也大大提升了工作效率,需要處理數據時,只要打開批處理文件,然后去做其他工作,過段時間回來取結果就可以了。
有興趣或有更多個性需求的朋友可以自行研究一下這些常用的命令。針對日志分析,大家也可以求助于技術人員,抽時間寫一個常規的分析腳本,每天在服務器上自動分析昨天的日志,還可以要求把日志分析結果以郵件的形式發給自己,也算是對網站運營情況的一種監測,當在這些數據中發現異常時,再去詳細細分的分析日志文件以找到問題根源。同時,真正對數據分析感興趣的朋友也可以深入研究一下excel, excel中有大量的函數可以輔助進行批量數據分析和
整理,基本上可以滿足絕大部分朋友的需求,除非你要處理的數據超過了1 048 576行或16 384列(Exce12007的限制)。本次的網站降權解決方法大概就到這,有朋友想深入討論的話可以關注微笑的SEO網站:http://www.za9bao.com/或在網站上找到微笑的聯系方式大家一起深入討論。
 
本文出自微笑SEO優化教程網,未經允許不得轉載:網站降權解決方法 http://www.za9bao.com/seoyhjc/310.html
? 撸片av在线观看