Das erste Date mit Googlebot: Header und Komprimierung

Montag, 10. März 2008


Name/User-Agent: Googlebot
IP-Adresse: Hier verifizieren
Ich suche: Websites mit einzigartigem
und gutem Content
Geht gar nicht: Verstöße gegen die
Richtlinien für Webmaster
Googlebot – ein echter Traumtyp. Es ist so, als würde er uns von Kopf- bis Fußzeile kennen, als wüsste er über unseren <body> genau Bescheid. Er ist wahrscheinlich nicht auf der Suche nach etwas Festem; er sieht Milliarden anderer Sites (allerdings teilen wir unsere Daten auch mit anderen Bots :), doch heute Abend werden wir uns als Website und Crawler richtig nahe kommen.

Ich weiß, es ist nie gut, das erste Date zu sehr zu analysieren. Wir werden den Googlebot ein bisschen langsamer kennen lernen, in einer Serie von Posts:
  1. Das erste Date (heute!): Von Googlebot gesendete Header; Dateiformate, die er "versteht"; ob es besser ist, Daten zu komprimieren
  2. Seine Antwort deuten: Response-Codes (301, 302), wie er mit Weiterleitungen und If-Modified-Since umgeht
  3. Nächste Schritte: Den Links folgen, wie lasse ich ihn schneller oder langsamer crawlen (so dass er nicht zu aufdringlich wird)
Und heute Abend ist gerade mal das erste Date…

***********
Googlebot : ACK
Website : Googlebot, du bist da!
Googlebot : Ja, hier bin ich. 
Host: example.com
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1;
+https://www.google.com/bot.html)
Accept-Encoding: gzip,deflate
 Website: Diese Header sind echt schick! Crawlst du mit den gleichen Headern, egal ob meine Site in den USA, Asien oder Europa ist? Verwendest du jemals andere Header?

Googlebot: Meine Header sind normalerweise weltweit einheitlich. Ich versuche zu sehen, wie eine Seite in ihrer Default-Sprache und mit den Default-Einstellungen aussieht. Manchmal ist der User-Agent anders, zum Beispiel verwendet AdSense "Mediapartners-Google":

User-Agent: Mediapartners-Google

Für die Bildsuche heißt der User-Agent:

User-Agent: Googlebot-Image/1.0

Bei der kabellosen Datenübertragung werden häufig betreiberspezifische User-Agenten verwendet, während die RSS-Abrufe von Google Reader zusätzliche Informationen beinhalten, beispielsweise die Anzahl der Feed-Abonnenten.

Ich meide gewöhnlich Cookies (also kein "Cookie:"-Header), da ich nicht will, dass der Content zu sehr von sessionspezifischen Informationen beeinflusst wird. Wenn ein Server eine Session-ID eher in einer dynamischen URL als in einem Cookie verwendet, dann kann ich das normalerweise erkennen, damit ich nicht die gleiche Seite von dir mit Millionen verschiedener Session-IDs eine Million mal crawle.

Website: Ich bin sehr komplex. Ich habe viele Dateitypen. Deine Header sagen "Accept: */*". Indexierst du alle URLs oder werden bestimmte Dateiendungen automatisch gefiltert?

Googlebot: Das kommt darauf an, wonach ich Ausschau halte.

Wenn ich für die reguläre Websuche unterwegs bin und Links zu MP3-Dateien und Videos sehe, dann lade ich diese wahrscheinlich nicht herunter. Wenn ich ein JPG sehe, dann behandle ich es auch anders als einen HTML- oder einen PDF-Link. Beispielsweise ist mit großer Wahrscheinlichkeit anzunehmen, dass sich JPGs nicht so oft ändern wie HTML, also checke ich das JPG weniger häufig, um Bandbreite zu sparen. Bin ich unterdessen dabei, als gelehrter Google Scholar nach Links zu schauen, dann bin ich viel interessierter an dem PDF-Artikel als an der JPG-Datei. Es lenkt einen Gelehrten einfach zu sehr ab, Doodles (wie JPGs) and Videos von Skateboard fahrenden Hunden herunterzuladen, findest du nicht?

Website: Ja, das stimmt. Ich bewundere deine Disziplin – ich liebe Doodles (JPGs) und kann ihnen kaum widerstehen.

Googlebot: Ich auch, ich bin nicht immer so schulmeisterlich. Wenn ich für die Bildsuche crawle, dann bin ich äußerst interessiert an JPGs. Für News-Ergebnisse schaue ich hauptsächlich nach HTML und nahe liegenden Bildern.

Es gibt auch viele Dateiendungen (exe, dll, zip, dmg…), die oft zu groß und weniger nützlich für eine Suchmaschine sind.

Website: Wenn du meine URL siehst, würdest du sie (wimmer wimmer) abweisen, nur weil sie eine unbekannte Dateiendung enthält?

Googlebot: Website, lass mich ein bisschen weiter ausholen. Nachdem ich eine Datei heruntergeladen habe, benutze ich den Content-Type-Header, um zu prüfen, ob sie wirklich HTML, ein Bild, Text oder etwas anderes ist. Für spezielle Datentypen wie PDF-Dateien, Word-Dokumente oder Excel-Tabellen vergewissere ich mich, dass sie ein gültiges Format haben und extrahiere den Text-Content. Vielleicht haben sie einen Virus; man weiß ja nie. Wenn das Dokument oder der Datentyp richtig vermurkst sind, dann kann ich normalerweise nicht viel tun, außer den Content zu verwerfen.

Wenn ich also URLs wie https://www.example.com/page1.LOL111 mit einer unbekannten Dateiendung crawle, dann beginne ich wahrscheinlich mit dem Herunterladen. Falls ich den Content-Typ nicht aus dem Header erschließen kann, oder falls es ein Format ist, das wir nicht indexieren (z. B. mp3), dann lasse ich sie in Ruhe. Ansonsten fahren wir mit dem Indexieren fort.

Website: Entschuldige, dass ich dich unter die Lupe nehme, Googlebot, aber mir ist aufgefallen, dass deine Accept-Encoding-Header sagen:

Accept-Encoding: gzip,deflate

Kannst du mir diese Header erklären?

Googlebot: Klar. Alle großen Suchmaschinen und Webbrowser unterstützen die gzip-Komprimierung des Contents, um Bandbreite zu sparen. Andere Angaben, die du an dieser Stelle sehen könntest, sind unter anderem "x-gzip" (dasselbe wie "gzip"), "deflate" (das wir ebenfalls unterstützen) und "identity".


Website: Kannst du mir mehr über Dateikomprimierung und "Accept-Encoding: gzip,deflate" erzählen? Viele meiner URLs bestehen aus großen Flash-Dateien und atemberaubenden Bildern, nicht nur aus HTML. Würde es dir dabei helfen, schneller zu crawlen, wenn ich meine größeren Dateien komprimiere?

Googlebot: Auf diese Frage gibt es keine einfache Antwort. Zunächst einmal: Viele Dateiformate, so wie swf (Flash), jpg, png, gif und pdf, sind bereits komprimiert (es gibt auch spezielle Flash-Optimierer).

Website: Vielleicht habe ich also meine Flash-Dateien schon komprimiert und wusste noch nicht einmal davon? Ich bin offenbar echt effizient.

Googlebot: Sowohl Apache als auch IIS bieten die Möglichkeit, die gzip- und deflate-Komprimierung zu aktivieren, obwohl die gesparte Bandbreite zu Lasten der CPU geht. Üblicherweise ist sie nur für einfach zu komprimierenden Text-Content in HTML/CSS/PHP aktiviert. Sie wird auch nur dann verwendet, wenn der Browser des Users oder ich (ein Suchmaschinen-Crawler) sie unterstützen. Ich persönlich mag "gzip" lieber als "deflate". Gzip ist eine etwas robustere Kodierung – es gibt immer eine Prüfsumme und einen vollständigen Header, so dass ich weniger Rätselraten muss als bei deflate. Ansonsten sind sie sehr ähnliche Komprimierungsalgorithmen.

Falls du auf deinen Servern noch Prozessorleistung übrig hast, dann lohnt es sich vielleicht, mit der Komprimierung zu experimentieren (Links: Apache , IIS ). Wenn du jedoch dynamischen Content lieferst und deine Server-CPUs schon sehr ausgelastet sind, dann ist das vielleicht nichts für dich.

Website: Das ist sehr interessant. Ich bin wirklich froh, dass du heute Abend gekommen bist – zum Glück hat meine robots.txt das zugelassen. Diese Datei führt sich manchmal auf wie überfürsorgliche Eltern!

Googlebot: Ah ja, die Vorstellung bei den Eltern; die robots.txt-Datei. Ich habe schon viele verrückte getroffen. Manche sind eher HTML-Fehlerseiten als anständige robots.txt-Dateien. Einige haben überall unendliche Weiterleitungen, manchmal zu Sites, zu denen es überhaupt keinen Bezug gibt. Wieder andere sind einfach nur riesig und listen Tausende verschiedener URLs einzeln auf. Hier ist ein Beispiel für einen unglücklichen Umgang mit robots.txt. Diese Site ist normalerweise erpicht darauf, dass ich sie crawle:

User-Agent: *
Allow: /

Dann, in einer Stoßzeit mit viel User-Traffic, ändert sie ihre robots.txt-Datei und schließt das Crawling aus:

# Kannst du eine Zeit lang wegbleiben?
# Du darfst bald wiederkommen, versprochen!
User-Agent: *
Disallow: /

Das Problem bei dieser Art von Änderung der robots.txt-Datei ist, dass ich, sobald ich diesen restriktiven Befehl sehe, möglicherweise Content verwerfen muss, den ich vorher bereits gecrawlt und indexiert hatte. Anschließend, wenn ich dann wieder an die Site heran darf, muss ich viel von diesem Content erneut crawlen. Ein vorübergehender 503 Response-Code wäre zumindest zeitlich begrenzt.

Ich überprüfe die robots.txt-Datei gewöhnlich einmal am Tag (ansonsten würde ich bei vielen virtuellen Hosts den Großteil meines Crawlings nur damit verbringen, robots.txt nachzuprüfen, und wer will bei einem Date schon ständig "die Eltern treffen"). Es geht für Webmaster normalerweise nach hinten los, wenn sie versuchen, die Crawl-Rate durch die Änderung der robots.txt-Datei zu kontrollieren. Es ist besser, die Crawling-Geschwindigkeit in den Webmaster-Tools auf "Langsamer" zu setzen.

Googlebot: Website, danke für deine Fragen, du warst wunderbar, aber ich muss mich jetzt verabschieden – "FIN, meine Liebe".

Website: Oh, Googlebot…ACK/FIN. :)

First date with the Googlebot: Headers and compression (English version)

Post von Maile Ohye als Website und Jeremy Lilley als Googlebot (Übersetzung von Johanna, Search Quality)