原文: First date with the Googlebot: Headers and compression
谷歌机器人: 命令正确应答
网站: 谷歌机器人,你来了!
谷歌机器人:是的,我来了!
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”,(呜噎着说)你会不会只是因为里面包含着未知的文件扩展名就把它拒之门外呢?
所以,如果我爬行你的“http://www.example.com/page1.LOL111”URL并发现未知文件扩展名时,我可能会首先把它下载。 如果我从标头中无法弄清内容类型,或者它属于我们拒绝检索的文件格式(例如MP3),那么只能把它放在一边了。除此之外,我们会接着对文件进行爬行。
网站:谷歌机器人,我很抱歉对你的工作风格“鸡蛋里挑骨头”,但我注意到你的“Accept-Encoding”标头这样说:
Accept-Encoding: gzip,deflate
你能跟我说说这些标头是怎么回事吗?
网站:你能更详细地说说文件压缩和“Accept-Encoding: gzip,deflate”吗?我的许多URL都包含尺寸很大的Flash文件和美妙的图像,不仅仅是HTML。如果我把一个比较大的文件加以压缩,会不会有助于你更迅速地爬行呢?
网站:或许我已经把自己的Flash文件进行了压缩,自己还不知道。很显然,我的效率很高喽。
谷歌机器人:Apache和IIS都提供了选项,允许进行gzip和deflate压缩,当然,节省带宽的代价是对CPU资源的更多消耗。一般情况下,这项功能只适用于比较容易压缩的文件,例如文本HTML/CSS/PHP内容等。而且,只有在用户的浏览器或者我(搜索引擎机器人)允许的情况下才可以使用。 就我个人而言,更倾向于“gzip”而不是“deflate”。Gzip的编码过程相对可靠一些,因为它不断地进行加和检查,并且保持完整的标头,不像 “deflate”那样需要我在工作中不断推测。除此之外,这两种程序的压缩算法语言都很相似。
如果你的服务器上有闲置的CPU资源,可以尝试进行压缩(链接:Apache, IIS)。但是,如果你提供的是动态内容,而且服务器的CPU已经处于满负荷状态,我建议你还是不要这样做。
网站:很长见识。我很高兴今晚你能来看我。感谢老天爷,我的robots.txt文件允许你能来。这个文件有时候就像对自己的子女过分保护的父母。
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 切换的方式来控制爬行频率是有副作用的,更好的办法是用网站管理员工具将爬行频率调至“较低”即可。
谷歌机器人: 网站老兄,谢谢你提出的这些问题,你一直做得很不错,但我现在不得不说“再见,我的爱人”了。
网站:哦,谷歌机器人…(结束应答):)