白帽SEO之搜尋引擎工作的基礎流程與原理

來源:互聯網
上載者:User

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

搜尋引擎最重要的是什麼?有人會說是查詢結果的準確性,有人會說是查詢結果的豐富性,但其實這些都不是搜尋引擎最最致命的地方。 對於搜尋引擎來說,最最致命的是查詢時間。 試想一下,如果你在百度介面上查詢一個關鍵字,結果需要5分鐘才能將你的查詢結果回饋給你,那結果必然是你很快的捨棄掉百度。

搜尋引擎為了滿足對速度苛刻的要求(現在商業的搜尋引擎的查詢時間單位都是微秒數量級的),所以採用緩存支援查詢需求的方式,也就是說我們在查詢搜索時所得到的結果並不是及時的,而是在其伺服器已經緩存好了的結果。 那麼搜尋引擎工作的大體流程是什麼樣子呢?我們可以理解為三段式。 本文僅僅是對著三段工作流程進行大體上的講解與綜述,其中一些詳細的技術細節將會用其它的文章進行單獨的講解。

一.網頁搜集。

網頁搜集,其實就是大家常說的蜘蛛抓取網頁。 那麼對於蜘蛛(google稱之為機器人)來說,他們感興趣的頁面分為三類:

1.蜘蛛從未抓去過的新頁面。

2.蜘蛛抓去過,但頁面內容有改動的頁面。

3.蜘蛛抓取過,但現在已刪除了的頁面。

那麼如何行之有效的發現這三類頁面並進行抓取,就是spider程式設計的初衷與目的。 那麼這裡就涉及到一個問題,蜘蛛抓取的起始點。

每一位站長只要你的網站沒有被嚴重降權,那麼通過網站後臺的伺服器,你都可以發現勤勞的蜘蛛光顧你的網站,但是你們有沒有想過從編寫程式的角度上來說,蜘蛛是怎麼來的呢?針對于此,各方有各方的觀點。 有一種說法,說蜘蛛的抓取是從種子站(或叫高權重站),依照權重由高至低逐層出發的。 另一種說法蜘蛛爬在URL集合中是沒有明顯先後順序的,搜尋引擎會根據你網站內容更新的規律,自動計算出何時是爬取你網站的最佳時機,然後進行抓取。

其實對於不同的搜尋引擎,其抓取出發點定然會有所區別,針對于百度,Mr.Zhao較為傾向于後者。 在百度官方博客發佈的《索引頁連結補全機制的一種辦法》(位址:HTTP://stblog.baidu-tech.com/?p=2057)一文中,其明確指出「spider會儘量探測網頁的發佈週期,以合理的頻率來檢查網頁」, 由此我們可以推斷,在百度的索引庫中,針對每個URL集合,其都計算出適合其的抓取時間以及一系列參數,然後對相應網站進行抓取。

在這裡,我要說明一下,就是針對百度來說,site的數值並非是蜘蛛已抓取你頁面的數值。 比如site:www.***.com,所得出的數值並不是大家常說的百度收錄數值,想查詢具體的百度收錄量應該在百度提供的站長工具裡查詢索引數量。 那麼site是什麼?這個我會在今後的文章中為大家講解。

那麼蜘蛛如何發現新連結呢?其依靠的就是超連結。 我們可以把所有的互聯網看成一個有向集合的聚集體,蜘蛛由起始的URL集合A沿著網頁中超連結開始不停的發現新頁面。 在這個過程中,每發現新的URL都會與集合A中已存的進行比對,若是新的URL,則加入集合A中,若是已在集合A中存在,則丟棄掉。 蜘蛛對一個網站的遍歷抓取策略分為兩種,一種是深度優先,另一種就是寬度優先。 但是如果是百度這類商業搜尋引擎,其遍歷策略則可能是某種更加複雜的規則,例如涉及到功能變數名稱本身的權重係數、涉及到百度本身伺服器矩陣分佈等。

二.預處理。

預處理是搜尋引擎最複雜的部分,基本上大部分排名演算法都是在預處理這個環節生效。 那麼搜尋引擎在預處理這個環節,針對資料主要進行以下幾步處理:

1.提取關鍵字。

蜘蛛抓取到的頁面與我們在瀏覽器中查看的源碼是一樣的,通常代碼雜亂無章,而且其中還有很多與頁面主要內容是無關的。 由此,搜尋引擎需要做三件事情:代碼去噪。 去除掉網頁中所有的代碼,僅剩下文本文字。 ②去除非正文關鍵字。 例如頁面上的巡覽列以及其它不同頁面共用的公共區域的關鍵字。 ③去除停用詞。 停用詞是指沒有具體意義的詞彙,例如「的」「在」等。

當搜尋引擎得到這篇網頁的關鍵字後,會用自身的分詞系統,將此文分成一個分詞清單,然後儲存在資料庫中,並與此文的URL進行一一對應。 下面我舉例說明。

假如蜘蛛爬取的頁面的URL是HTTP://www.***.com/2.html,而搜尋引擎在此頁面經過上述操作後提取到的關鍵字集合為p,且p是由關鍵字p1,p2,......,pn組成,則在百度資料庫中,其相互間的關係是一一對應 ,如下圖。

  

2.消除重複與轉載網頁。

每個搜尋引擎其識別重複頁面的演算法均不相同,但是其中Mr.Zhao認為,如果將消重演算法理解為由100個元素組成,那麼所有的搜尋引擎恐怕其80個元素都是完全一樣的。 而另外20個元素,則是根據不同的搜尋引擎針對seo的態度不同,而專門設立的對應策略。 本文僅對搜尋引擎大體流程進行初步講解,具體數學模型不多做講解。

3.重要資訊分析。

在進行代碼除噪的過程中,搜尋引擎並非簡單的將其去除掉而已,而是充分利用網頁代碼(例如H標籤、strong標籤)、關鍵字密度、內鏈錨文本等方式分析出此網頁中最重要的片語。

4.網頁重要度分析。

通過指向該網頁的外鏈錨文本所傳遞的權重數值,來為此網頁確定一個權重數值,同時結合上述的「重要資訊分析」,從而確立此網頁的關鍵字集合p中每一個關鍵字所具備的排名係數。

5.倒排檔。

正如上文所說,使用者在查詢時所得到的查詢結果並非是及時的,而是在搜尋引擎的緩存區已經大體排好的,當然搜尋引擎不會未卜先知,他不會知道使用者會查詢哪些關鍵字,但是他可以建立一個關鍵字詞庫,而當其處理使用者查詢請求的時候, 會將其請求按照詞庫進行分詞。 那麼這樣下來,搜尋引擎就可以在使用者產生查詢行為之前,將詞庫中的每一個關鍵字其對應的URL排名先行計算好,這樣就大大節省了處理查詢的時間了。

簡單來說,搜尋引擎用控制器來控制蜘蛛爬取,然後將URL集與原始資料庫進行保存,保存之後再用索引子控制每個關鍵字與URL之間的對應關係,並將其保存在索引資料庫中。

下面我們來舉例說明。

假若HTTP://www.***.com/2.html頁面被切詞成p={p1,p2,p3,......,pn},則其在索引資料庫中由下圖方式體現。

  

上圖是為了方便大家便於理解而做出來的,索引資料庫實際上是搜尋引擎中對性能要求最高的資料庫,因為裡面所有因素都會受到演算法影響,所以實際上的索引資料庫我覺得應該是由多維陣列所組成的較為複雜的索引表, 但其主要體現的大體作用與上圖相同。

三、查詢服務。

查詢服務顧名思義,就是處理使用者在搜索介面的查詢請求。 搜尋引擎構建檢索器,然後分三步來處理請求。

1.根據查詢方式與關鍵字進行切詞。

首先先把使用者搜索的關鍵字切分為一個關鍵字序列,我們暫時用q來表示,則使用者搜索的關鍵字q被切分為q={q1,q2,q3,......,qn}。

然後再根據使用者查詢方式,例如是所有詞連在一起,還是中間有空格等,以及根據q中不同關鍵字的詞性,來確定所需查詢詞中每一個詞在查詢結果的展示上所佔有的重要性。

2.搜尋結果排序。

我們有了搜索詞集合q,q中每個關鍵字所對應的URL排序——索引庫,同時也根據使用者的查詢方式與詞性計算出每個關鍵字在查詢結果的展示上所佔有的重要,那麼只需要進行一點綜合性的排序演算法,搜尋結果就出來了。

3.展示搜尋結果與文檔摘要。

當有了搜尋結果後,搜尋引擎就會將搜尋結果展示在使用者閱覽的介面上以供使用者使用。

在這裡,大家可以思考兩個個問題。

大家在搜索介面中經常發現百度展示的摘要是使用者搜索詞周圍的,如果我不僅僅只看第一頁,多往後翻一些頁,會看到有些結果由於其目標頁面本身並未完全包含搜索詞,而在百度提取的摘要中標紅詞僅是部分搜索詞,那麼我們可以這樣理解, 百度在搜索詞不被完全包含的情況下,是不是應該優先展現在分詞結果中被百度認為較為重要的詞呢?那麼從這些搜尋結果中我們是不是就可以看出百度分詞演算法的部分端倪呢?

②有時候頁面中會多次出現搜索詞,而百度搜尋結果頁面中在網站摘要部分僅會顯示部分,通常這麼部分是連續的,那我們是不是可以理解在摘要部分,百度會優先展示頁面中它認為與對此搜索詞最重要的部分呢? 那麼由此我們是不是可以揣度出百度針對頁面除噪後對不同部分賦予權重的演算法呢?

這兩個問題仁者見仁智者見智,做SEO的朋友們自己去探索與摸索吧,Mr.Zhao不敢在此無人子弟。

四、現今百度的流程漏洞。

請原諒我用流程漏洞來形容這個模組,但我不得不說,在如今點擊器橫行的天下,我覺得說是漏洞無可厚非。

那就是除了上面三個大環節外,百度還構建了使用者行為模組,來影響原始資料庫與索引庫。 而影響原始資料庫的,是百度的快照投訴,主要處理互聯網暴利的一些行為,這點無可厚非。 而影響索引庫的,是使用者的點擊行為,這個設計本身也無可厚非,但百度演算法的不成熟,導致了點擊器作弊猖獗。

百度的使用者行為分析模組很簡單,除了自身投訴的提交入口外,就是搜集使用者在搜索介面的點擊行為,如果此頁面結果被大部分使用者閱覽,但沒有產生點擊,使用者居然大部分選擇點擊第二頁甚至更後面的頁面,則此現象就會被百度工程師們所知道, 則會根據這方面來微調演算法。 如今百度針對不同行業,其演算法早已不同了。

如果前兩頁內某個搜索介面被大量使用者選擇點擊,則通常會在24小時候,這個搜尋結果被大幅前提,甚至會被提升至第一名。

五、搜尋引擎大體流程圖(加上使用者行為分析器)

  

以上就是我所對搜尋引擎工作的基礎流程與原理的理解。

最後我想說廣大的SEO從業者們應該已經發現無論是百度還是谷歌或者其它的商業搜尋引擎,他們都會要求seoer們不要去在意演算法、不要去在意搜尋引擎,而是去多關注使用者體驗。 這裡我們可以理解成一個比喻,搜尋引擎是買西瓜的人,而SEO們是種西瓜的人,買西瓜的人要求我們這些種西瓜的人不要關心他們挑選西瓜的標準,而是多多在意怎麼去種出好西瓜,而對於什麼樣的西瓜是他們需要的好西瓜, 他們又往往用一些模糊的概念掩蓋過去。 誠然,這樣搜尋引擎得到的結果將會多樣化,他們可以在挑選結果時有更多的選擇,能夠最大限度的維護這些商業搜尋引擎自身的利益,但是請其也不要忘記,我們這些種西瓜的也要有口飯吃。

Mr.Zhao始終堅持白帽SEO,深入研究UE,做對使用者有意義的站。 但與此同時,我也堅信身為seoer,我們還應該對演算法有及時瞭解,以便我們做出的站在符合使用者口味的時候,更能在搜尋引擎中得到良好的展現,因為畢竟seoer也是人,也希望過得好一點。 今後我將在其它的文章中逐步剖析搜尋引擎的各個環節,併發表在我博客「搜尋引擎原理」的欄目下,希望對大家有所説明。

本文首發Mr.Zhao的博客:HTTP://www.seozhao.com/319.html 轉載請注明。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.