本文翻譯自：First date with the Googlebot: Headers and compression

谷歌機器人 -- 多么神奇的夢幻之舟！他了解我們的靈魂和各個組成部分?；蛟S他并不尋求什么獨一無二的東西；他閱覽過其它數十億個網站（雖然我們也與其他搜索引擎機器人分享自己的數據:)），但是就在今晚，作為網站和谷歌機器人，我們將真正地了解對方。

我知道第一次約會的時候，過分地分析從來就不是什么好主意。我們將通過一系列的文章，一點點地了解谷歌機器人：

我們的第一次約會（就在今晚）：谷歌機器人發出的數據標頭和他所留意到的文件格式是否適于被進行壓縮處理；

判斷他的反應：響應代碼（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; +http://www.google.com/bot.html)

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“http://www.example.com/page1.LOL111”,（嗚噎著說）你會不會只是因為里面包含著未知的文件擴展名就把它拒之門外呢？

谷歌機器人： 網站老兄，讓我給你講點背景知識吧。一個文件真正下載完成后，我會使用“內容—類別”（Content-Type）標頭來檢查它屬于HTML、圖像、文本還是別的什么東西。如果它是PDF、Word文檔或Excel工作表等特殊的數據類型，我會確認它的格式是否合法有效，并從中抽取文本內容。但是你永遠也不能確定里面是否含有病毒。但是如果文檔或數據類型混亂不清，我除了把它們扔掉之外，也沒有什么更好的辦法。

所以，如果我爬行你的“http://www.example.com/page1.LOL111”URL并發現未知文件擴展名時，我可能會首先把它下載。 如果我從標頭中無法弄清內容類型，或者它屬于我們拒絕檢索的文件格式（例如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 切換的方式來控制爬行頻率是有副作用的，更好的辦法是用網站管理員工具將爬行頻率調至“較低”即可。

谷歌機器人： 網站老兄，謝謝你提出的這些問題，你一直做得很不錯，但我現在不得不說“再見，我的愛人”了。

網站：哦，谷歌機器人…（結束應答):)