Nach meinem Beitrag werde ich nun etwas zur Anatomie von Google schreiben. Der Beitrag beruht im Großen und Ganzen wieder auf dem von Google. Es gibt noch immer viele SEOs, die noch nichts von diesem Papier gehört haben, oder der englischen Sprache nicht mächtig sind. Ich halte es jedoch für sehr wichtig, da es glaubwürdig ist und kein anderer Artikel die Anatomie von Google so genau beschreibt wie dieser. Deshalb habe ich beschlossen, mit diesem Artikel die Anatomie verständlich auzubereiten.

Einleitung

Fangen wir bei einer Suchabfrage an: Gibt jemanden einen Begriff in die Suchmaschine Google ein, bekommt er ein nettes Ergebnis zurück geliefert. Diese Funktion einer Suchmaschine ist zunächste recht simpel man könnte es selbst mit einer mySQL Datenbank realisiert. mySQL liefert sogar verschiedene Funktionen um Ergebnisse nach Relevanz zu sortieren. Steckt also vielleicht hinter Google eine mySQL Datenbank mit einem kleinen PHP Script, welches die Ergebnisse liefert? Natürlich nicht. Eine mySQL Datenbank mit der Anzahl an Seiten, die Google indiziert hat, würde vermutlich bei der zweiten Suchabfrage zusammenbrechen. Zudem würde eine Suchabfrage in einer mySQL Datenbank dieser Größenordnung ewig dauern. Google setzt auch nicht auf eine Scriptsprache (PHP), sondern nutzt hauptächlich C und C++.

Nun aber zurück zu unserer Ausgangssituation: Ein Benutzer gibt eine Suchabfrage ein und erhält ein sortiertes Ergebnis zurück. Dieses Ergebnis enthält zwei wichtige Elemente. Die Daten und die Sortierung, wobei letzeres auch teilweise auf den Daten beruht. Diese Daten müssen zunächst von Google gesammelt werden, also dem offenen Web entnommen.

Man sieht also schon jetzt, dass hier verschiedene Aufgaben von Google erledigt werden müssen: Daten Sammeln, Daten Sortieren. Diese Aufgaben lassen sich sogar noch weiter in Teilaufgaben aussplitten. Und so erhält man am Ende 8 verschiedene Aufgaben, die alle dazu beitragen, dass der Benutzer sein Suchergebnis angezeigt bekommen. Diese 8 Aufgaben werden in der Grundidee von Google von 8 verschiedenen Servern/Crawlern unternommen.

Die Anatomie

Diese 8 Server zur Aufgabenbewältigung sollen nun erläutert werden und sind in der folgenden Grafik grün hinterlegt. Hinzu kommen einige Datenbanken, welche in der Grafik blau hinterlegt wurden.

Zunächst haben wir eine Ausgangssituation, in der alle URLs, die bei Google gelistet sind, im sogenannten Doc Index gespeichert sind. Der Doc Index ist eine Datenbank. Die URLs die hier gepspeichert sind werden mit einer docID identifiziert. Jede einzelne Internetadresse hat bei Google also ihre eigene docID.

Der erste Server, dem wir uns nun zuwenden, ist der URL Server. Dieser nimmt sich aus dem Doc Index verschiedene URLs mit den docIDs und sendet diese an den Crawler. Es handelt sich hierbei nur um die einzelnen URLs, ohne Seiteninhalt.

Der Crawler besucht die entsprechende Seite, liest den Inhalt, und sendet diesen weiter an den Storeserver. Der Storeserver erhält den Inhalt, komprimiert ihn, und speichert ihn in einer Datenbank (Repository). Bei dem Komprimierungsverfahren handel es sich um zlib, also kein von Google selbst entwickelter Algorithmus.

Aus dieser Repository Datenbank bedient sich nun der Indexer, der verschiedene Funktionen erfüllt. Zunächst muss er eine aus dem Repository entnommene Seite zunächst dekomprimieren. Anschließend wird die Seite geparst und alle Links werden entnommen. Die Links der Seite werden in einer anderen Datenbank wieder gespeichert (Anchors). Und zwar werden hier drei wichtige Werte zu jedem Link gespeichert: Die docID der Seite mit dem Link / die docID auf die der Link zeigt / Der Link Text.

Der Indexer wertet die Seite aus dem Repository zudem anhand der vorkommenden Wörter aus. Zu jedem Wort, welches auf der Seite vorkommt, werden wieder verschiedene Daten gespeichert (Anzahl der Vorkommen im Text, Schriftgröße, usw.).

Diese Daten werden wieder in einer sehr großen Datenbank gespeicher. Google bezeichnet dies nicht als Datenbank, sondern als “set of barrels” (eine Gruppe von Fässern). Diese Barrels machen den eigentlichen Index aus.

Nun kommt der URLresolver zum Einsatz. Dieser hat eine große Aufgabe, was die Verlinkung der Seiten angeht. Zunächst nimmt er sich Seiten aus der Anchor Datenbank. Die URLs der Seiten werden von relativen Pfadangaben in absolute Angaben abgeändert. Anschließend werden den einzelnen URLs docIDs zugeordnet und diese Daten im DocIndex gespeichert. So ist bereits ein Kreislauf entstanden, bei dem neue Seiten geparst werden, Links entnommen und die Zielseiten der Links anschließend wieder geparst werden.

Der URL Resolver hat jedoch noch zwei weitere Aufgaben. Er speichert zu jedem Link das docID-Paar in der Datenbank Links ab. Diese dient einem anderen Server zur Berechnung des PageRanks. Auch sendet der URL Resolver Daten an die Barrels, also den eigentlichen Index. Diese Daten bestehen aus dem Linktext und der docID der Zielseite zu jedem Link. Diese Daten dienem nämlich auch der Sortierung.

Der Pagerank wird von einem eigenen Server berechnet. Dieser Server erhält nur Daten aus der Link Datenbank. Der Server kennt also nur das docID-Paar zu jedem Link, sonst nichts. Alleine mit diesen Daten lässt sich der für jede Seite errechnen.

Der wohl wichtigste Server für eine Suchanfrage ist der Searcher. An diesen werden die Suchanfragen gestellt. Der Server bedient sich aus dem Doc Index, um an die eigentlichen Daten zu gelangen. Um diese zu sortieren, benötigt er Daten von dem Pagerank Server und den Barrels. Zudem kommt hier ein Lexicon zum Einsatz. Das Lexicon ist eine weitere Datenbank mit einer großen Menge an Wörtern.

Aus der Sicht des SEOs

Man muss sich die Frage stellen, was an dieser Anatomie denn wichtig für SEO ist. Meiner Meinung verrät die Anatomie sehr viel, um Seiten für Google zu oprimieren.

Nicht neu ist, dass der PageRank nur zu einem Teil in die Sortierung der Ergebnisse einfließt. Großen Einfluss nach dieser Anatomie hat auch der Linktext, welcher aber wiederum nichts mit der Berechnung des PageRanks zu tun hat.

Vermissen tut man in diesem Modell verschiedene andere Kriterien, wie das Alter einer Domain, das Vorkommen von Keywords im Domainnamen, usw. Jedoch muss man sich auch klar machen, dass es sich hierbei um eine sehr frühe Beschreibung der Google Anatomie handelt. Viele der Kriterien wurden sicher erst mit dem erhöhten Aufkommen von Spam in den Algorithmus integriert.

Fortsetzung folgt…