摘要：收集待索引網(wǎng)頁Internet上存在的網(wǎng)頁數(shù)量絕對是個天文數(shù)字，每天新增的網(wǎng)頁也不計其數(shù)，搜索引擎需要首先找到要索引收錄的對象。具體到Google而言，雖然對GoogleBot是否存在DeepBot與...
Internet上存在的網(wǎng)頁數(shù)量絕對是個天文數(shù)字，每天新增的網(wǎng)頁也不計其數(shù)，搜索引擎需要首先找到要索引收錄的對象。
具體到Google而言，雖然對GoogleBot是否存在DeepBot與FreshBot的區(qū)別存在爭議——至于是否叫這么兩個名字更是眾說紛紜。
主流的看法是，在Google的robots中，的確存在著相當(dāng)部分專門為真正的索引收錄頁頁準(zhǔn)備“素材”的robots——在這里我們姑且仍稱之為FreshBot吧
它們的任務(wù)便是每天不停地掃描Internet，以發(fā)現(xiàn)并維護一個龐大的url列表供DeepBot使用，換言之，當(dāng)其訪問、讀取其一個網(wǎng)頁時，目的并不在于索引這個網(wǎng)頁，而是找出這個網(wǎng)頁中的所有鏈接。當(dāng)然，這樣似乎在效率上存在矛盾，有點不太可信。不過，我們可以簡單地通過以下方式判斷：FreshBot在掃描網(wǎng)頁時不具備“排它性”。也即是說，位于Google不同的數(shù)據(jù)中心的多個robots可能在某個很短的時間周期，比如說一天甚至一小時，訪問同一個頁面，而DeepBot在索引、緩存頁面時則不會出現(xiàn)類似的情況。即Google會限制由某個數(shù)據(jù)中心的robots來完成這項工作的，而不會出現(xiàn)兩個數(shù)據(jù)中心同時索引網(wǎng)頁同一個版本的情況，如果這種說法沒有破綻的話，則似乎可以從服務(wù)器訪問日志中時�？梢钥吹皆醋圆煌�IP的GoogleBot在很短的時間內(nèi)多次訪問同一個網(wǎng)頁證明FreshBot的存在。
因此，有時候發(fā)現(xiàn)GoogleBot頻繁訪問網(wǎng)站也不要高興得太早，也許其根本不是在索引網(wǎng)頁而只是在掃描url。
FreshBot記錄的信息包括網(wǎng)頁的url、TimeStamp(網(wǎng)頁創(chuàng)建或更新的時間戳)，以及網(wǎng)頁的Head信息(注：這一點存在爭議，也有不少人相信FreshBot不會去讀取目標(biāo)網(wǎng)頁信息的，而是將這部分工作交由DeepBot完成。
不過，筆者傾向于前一種說法，因為在FreshBot向DeepBot提交的url列表中，會將網(wǎng)站設(shè)置禁止索引、收錄的頁面排除在外，以提高效率，而網(wǎng)站進行此類設(shè)置時除使用robots.txt外還有相當(dāng)部分是通過mata標(biāo)簽中的“noindex”實現(xiàn)的，不讀取目標(biāo)網(wǎng)頁的head似乎是無法實現(xiàn)這一點的)，如果網(wǎng)頁不可訪問，比如說網(wǎng)絡(luò)中斷或服務(wù)器故障，F(xiàn)reshBot則會記下該url并擇機重試，但在該url可訪問之前，不會將其加入向DeepBot提交的url列表。
總的來說，F(xiàn)reshBot對服務(wù)器帶寬、資源的占用還是比較小的。最后，F(xiàn)reshBot對記錄信息按不同的優(yōu)先級進行分類，向DeepBot提交，根據(jù)優(yōu)先級不同，主要有以下幾種：
A：新建網(wǎng)頁;B：舊網(wǎng)頁/新的TimeStamp，即存在更新的網(wǎng)頁;C：使用301/302重定向的網(wǎng)頁;D：復(fù)雜的動態(tài)url：如使用多個參數(shù)的動態(tài)url，Google可能需要附加的工作才能正確分析其內(nèi)容。
——隨著Google對動態(tài)網(wǎng)頁支持能力的提高，這一分類可能已經(jīng)取消;E：其他類型的文件，如指向PDF、DOC文件的鏈接，對這些文件的索引，也可能需要附加的工作;
F：舊網(wǎng)頁/舊的TimeStamp，即未更新的網(wǎng)頁，注意，這里的時間戳不是以Google搜索結(jié)果中顯示的日期為準(zhǔn)，而是與Google索引數(shù)據(jù)庫中的日期比對;G：錯誤的url，即訪問時返回404回應(yīng)的頁面;
網(wǎng)頁的索引與收錄
接下來才進入真正的索引與收錄網(wǎng)頁過程。從上面的介紹可以看出，F(xiàn)reshBot提交的url列表是相當(dāng)龐大的，根據(jù)語言、網(wǎng)站位置等不同，對特定網(wǎng)站的索引工作將分配至不同的數(shù)據(jù)中心完成。
整個索引過程，由于龐大的數(shù)據(jù)量，可能需要幾周甚至更長時間才能完成。
正如上文所言，DeepBot會首先索引優(yōu)先級較高的網(wǎng)站/網(wǎng)頁，優(yōu)先級越高，出現(xiàn)在Google索引數(shù)據(jù)庫及至最終出現(xiàn)在Google搜索結(jié)果頁面中的速度便越快。
對新建網(wǎng)頁而言，只要進入到這個階段，即使整個索引過程沒有完成，相應(yīng)的網(wǎng)頁便已具備出現(xiàn)在Google索引庫中的可能，相信許多朋友在Google中使用“site”搜索時常�？吹綐�(biāo)注為補充結(jié)果只顯示網(wǎng)頁url或只顯示網(wǎng)頁標(biāo)題與url但沒有描述的頁面，此即是處于這一階段網(wǎng)頁的正常結(jié)果。
當(dāng)Google真正讀取、分析、緩存了這個頁面后，其便會從補充結(jié)果中逃出而顯示正常的信息。
——當(dāng)然，前提是該網(wǎng)頁具有足夠的鏈接，特別是來自權(quán)威網(wǎng)站的鏈接，并且，索引庫中沒有與該網(wǎng)頁內(nèi)容相同或近似的記錄(DuplicateContent過濾)。
對動態(tài)url而言，雖然如今Google宣稱在對其處理方面已不存在障礙，不過，可以觀察到的事實仍然顯示動態(tài)url出現(xiàn)在補充結(jié)果中的幾率遠(yuǎn)大于使用靜態(tài)url的網(wǎng)頁，往往需要更多、更有價值的鏈接才能從補充結(jié)果中逸出。
而對于上文中之“F”類，即未更新的網(wǎng)頁，DeepBot會將其時間戳與Google索引數(shù)據(jù)庫中的日期比對，確認(rèn)盡管可能搜索結(jié)果中相應(yīng)頁面信息未來得及更新但只要索引了最新版本即可——考慮網(wǎng)頁多次更新、修改的情況——;至于“G”類即404url，則會查找索引庫中是否存在相應(yīng)的記錄，如果有，將其刪除。
數(shù)據(jù)中心間的同步
前文我們提到過，DeepBot索引某個網(wǎng)頁時會由特定的數(shù)據(jù)中心完成，而不會出現(xiàn)多個數(shù)據(jù)中心同時讀取該網(wǎng)頁，分別獲得網(wǎng)頁最近版本的情況，這樣，在索引過程完成后，便需要一個數(shù)據(jù)同步過程，將網(wǎng)頁的最新版本在多個數(shù)據(jù)中心得到更新。
這就是之前著名的GoogleDance。不過，在BigDaddy更新后，數(shù)據(jù)中心間的同步不再像那樣集中在特定的時間段，而是以一種連續(xù)的、時效性更強的方式進行。
轉(zhuǎn)載請保留原文地址: http://www.biwz.cn/show-160.html