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