2008年3月27日 下午 02:45:00
发表者：Maile Ohye (饰网站)，Jeremy Lilley (饰谷歌机器人)
转载自谷歌中文网站管理员博客
原文： First date with the Googlebot: Headers and compression
发表于： 2008年3月5日星期三，晚上6:13
googlebot with flowers
姓名/用户代理: 谷歌机器人
IP地址: 点击这里查看如何验证
寻觅: 拥有独特而诱人内容的网站
最不喜欢的行为：违反《网站管理员指南》
谷歌机器人 -- 多么神奇的梦幻之舟！他了解我们的灵魂和各个组成部分。或许他并不寻求什么独一无二的东西；他阅览过其它数十亿个网站（虽然我们也与其他搜索引擎机器人分享自己的数据:))，但是就在今晚，作为网站和谷歌机器人，我们将真正地了解对方。
我知道第一次约会的时候，过分地分析从来就不是什么好主意。我们将通过一系列的文章，一点点地了解谷歌机器人：
1. 我们的第一次约会（就在今晚）：谷歌机器人发出的数据标头和他所留意到的文件格式是否适于被进行压缩处理；
2. 判断他的反应：响应代码（301s、302s），他如何处理重定向和If-Modified-Since；
3. 下一步：随着链接，让他爬行得更快或者更慢（这样他就不会兴奋地过了头）。
今晚只是我们的第一次约会……
***************
谷歌机器人： 命令正确应答
网站： 谷歌机器人，你来了！
谷歌机器人：是的，我来了！
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 切换的方式来控制爬行频率是有副作用的，更好的办法是用网站管理员工具将爬行频率调至"较低"即可。
谷歌机器人： 网站老兄，谢谢你提出的这些问题，你一直做得很不错，但我现在不得不说"再见，我的爱人"了。
网站：哦，谷歌机器人…（结束应答):)