谷歌機器人 — 多麼非常奇妙的夢境之舟!他理解我們的魂靈和各個組成局部。也許他並不征求啥子絕無僅有的物品;他閱讀過其他數十億個網站(固然我們也與其它搜索引擎網站機器人分享自個兒的數值:))，不過就在今天晚上，作為網站和谷歌機器人，我們將真正地理解對方。
我曉得首次約會的時刻，不為己甚地剖析從來沒有就不是啥子好意思。我們將經過一系列的文章，一點兒點地理解谷歌機器人：
我們的首次約會(就在今天晚上)：谷歌機器人散發的數值標頭和他所留意到的文件款式是否適於被施行壓縮處置;
判斷他的反響：響應代碼(301s、302s)，他怎麼樣處置重定向和If-Modified-Since;
下一步：隨著鏈接，讓他爬動得更快還是更慢(這麼他就不會興奮地過了頭)。
今天晚上只是我們的首次約會
***************
谷歌機器人： 指示准確回答
網站： 谷歌機器人，你來了!
谷歌機器人：似的，我來了!
GET / HTTP/1.1
Host: example.com
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +)
Accept-Encoding: gzip,deflate
網站： 這些個標頭太炫了!不管我的網站在美國、亞洲仍然歐羅巴洲，你都用一樣的標頭爬動嗎?你以前用過其它標頭嗎?
谷歌機器人： 普通而言，我在全世界各地所用的標頭都維持完全一樣。我打算從一個網站默許的語講和設定動身，搞明白一個網頁到底長得啥子樣。有時許多人的用戶攝理各不一，例如Adsense讀取運用的是Mediapartners-Google:
User-Agent: Mediapartners-Google
還是對於圖像搜索：
User-Agent: Googlebot-Image/1.0
無線讀取的用戶攝理因運營商而異，而谷歌閱覽器RSS讀取則裡面含有了訂閱者數目等另外信息。
我通例會防止Cookies(因為這個不存在所說的Cookie:標頭)，由於我並不期望與具體會話相關的信息對內部實質意義萌生太大的影響。這個之外，假如某個服務器在動態URL而不是Cookies上運用會話ID，一般我都能辨別出來，這麼就無須由於每每會話ID的不一樣而成千累萬到處重復爬動同一個網頁。
網站：我的結構十分復雜。我是用很多類型的文件。你的標頭說：Accept：*/*。你會對全部的URL施行收錄，仍然半自動過淋某些文件擴展名?
谷歌機器人：這要決定於於我想找啥子。
假如我只是對常理的Web搜索施行檢索，當我看見指向MP3和視頻文件內部實質意義的鏈接，我有可能不會下載這些個物品。大致相似地，假如我看見了一個JPG文件，處置辦法天然 就與HTML還是PDF鏈接有所差別。例如JPG 的變化頻率往往比HTML矮半截，所以我不太常常查緝JPG的變化，以節省帶寬。同時，假如我為谷歌學術搜索尋覓鏈接，那末我對PDF文章的興致便會遠遠高於對JPG文件的興致。對於學者而言，下載涂鴉繪畫(例如JPG)，還是是關於小狗玩滑板的視頻文件，是容易讓它們散布注意力的，你說對嗎?
網站：沒錯，它們有可能會感到被攪擾到達。你的敬業神魂令我欽佩得五體投地。我自個兒就喜歡涂鴉繪畫(JPG)，很難抵抗他們的魅惑力。
谷歌機器人：我也同樣。其實我並不是一直都在做學問。假如我為搜索圖像而爬動，便會對JPG十分有興致，遇到新聞，我會花大力量考察HTML和他們近旁的圖像。
還有眾多擴展名，例如exe、dll、zip、dmg等，他們對於搜索引擎網站而言，既數目極大，又沒有多大用法。
網站：假如你看見我的URL/page1.LOL111,(嗚噎著說)你會不會只是由於裡邊粉和水發酵制成的食品含著未知的文件擴展名就把它拒之門外呢?
谷歌機器人： 網站老兄，讓我給你講點環境知識吧。一個文件真正下載完成後，我會運用內部實質意義—門類(Content-Type)標頭來查緝它歸屬HTML、圖像、文本仍然別的啥子物品。假如它是PDF、Word文檔或Excel辦公表等特別的數值類型，我會明確承認它的款式是否合法管用，並從其中取出文本內部實質意義。不過你永恆也不可以確認裡邊是否包括病毒。不過假如文檔或數值類型沒秩序不清，我除開把他們拋棄以外，也沒有啥子更好的方法。
所以，假如我爬動你的/page1.LOL111URL並發覺未知文件擴展名時，我有可能會頭先把它下載。 假如我從標頭中沒有辦法弄清內部實質意義類型，還是它歸屬我們不接受檢索的文件款式(例如MP3)，那末只能把它放在一邊兒了。除此以外，我們會繼續對文件施行爬動。
網站：谷歌機器人，我很對不起對你的工風紀格估計挑毛病，但我注意到你的Accept-Encoding標頭這麼說：
Accept-Encoding: gzip,deflate
你能跟我說說這些個標頭是怎麼回事嗎?
谷歌機器人：當然。全部的主流搜索引擎網站和WEB瀏覽器都支持對內部實質意義施行gzip壓縮，以節省帶寬。你也許還會遇到其他的一點類型，例如x-gzip(與gzip相同)，deflate(我們也支持它)和identity(不支持)。
網站：你能更周密地說說文件壓縮和Accept-Encoding: gzip,deflate嗎?我的很多URL都裡面含有尺寸非常大的Flash文件和睦美滿妙的圖像，不止只是HTML。假如我把一個比較大的文件加以壓縮，會不會有助於你更迅疾地爬動呢?
谷歌機器人：對於這個問題，並沒有一個簡單的解答。首先，swf(Flash)、jpg、png、gif和pdf等文件款式本身已經是壓縮過的了(並且還有專門的Flash 優化器)。
網站：也許我已經把自個兒的Flash文件施行了壓縮，自個兒還不曉得。很顯然，我的速率頎長嘍。
谷歌機器人：Apache和IIS都供給了選項，准許施行gzip和deflate壓縮，當然，節約帶寬的代價是對CPU資源的更多耗費。普通事情狀況下，這項功能只適合使用於比較容易壓縮的文件，例如文本HTML/CSS/PHP內部實質意義等。並且，只有在用戶的瀏覽器還是我(搜索引擎網站機器人)准許的事情狀況下纔可以運用。 就我私人而言，更傾向於gzip而不是deflate。Gzip的編碼過程相對靠得住一點，由於它不停地施行加和查緝，況且維持完整的標頭，不像 deflate那樣子需求我在辦公中不斷測度。除此以外，這兩種手續的壓縮算法語言都很相仿。
假如你的服務器上有擱置的CPU資源，可以試驗施行壓縮(鏈接：Apache, IIS)。不過，假如你供給的是動態內部實質意義，並且服務器的CPU已經處於滿載荷狀況，我提議你仍然不要這麼做。
網站：很長識見。我很欣慰今天晚上你能來看我。拜謝天公，我的robots.txt文件准許你能來。這個文件有時就像對自個兒的子女不為己甚盡力照顧的二老。
谷歌機器人：說到這處，該見見二老大人了——它就是robots.txt。我以前見過不少瘋狂的二老。那裡面有點其實只是HTML不正確信息網頁，而不是管用的robots.txt。有點文件裡飽含了沒有窮盡無盡的重定向，並且有可能指向絕對不有關的站點。額外一點大小極大，包括結果千累萬條單獨成行、各不一的 URL。下邊就是那裡面的一種有副效用的文件標准樣式，在一般事情狀況下，這個站點是期望我去爬動它的內部實質意義的：
User-Agent: *
Allow: /
不過，在某個用戶流量的高峰時段，這個站點轉而將它的robots.txt切換到限止性極強的機制上：
# Can you go away for a while? I’ll let you back
# again in the future. Really, I promise!
User-Agent: *
Disallow: /
上面所說的robots.txt文件切換的問題在於，一朝我看見這種限止性很強的robots.txt，可能使我只得把引得中已經爬動的該網站內部實質意義丟開掉。當我再次被准許進入了這個站點的時刻，我只得將起初的很多內部實質意義從新爬動一遍，至少會短時間之內顯露出來503不正確相應代碼。
一 般來說，我每日只能從新查緝一次robots.txt(否則，在很多虛擬主機站點上，我會將一大多時間花在讀取robots.txt文件上，要曉得沒有 若乾約會對象喜歡這麼次數多地叩見對方二老的)。站長們經過robots.txt 切換的形式來扼制爬動頻率是有副效用的，更好的方法是用網站管理職員具將爬動頻率調至較低即可。
谷歌機器人： 網站老兄，謝謝你提出的這些個問題，你一直做得很不賴，但我如今只得說再見，我的最愛的人了。
網站：哦，谷歌機器人(終了回答):)
行者網站：