Geschrieben von

Wie Suchmaschinen Antworten liefern

SEO

Für uns ist es selbstverständlich: Wie geben bei Suchmaschinen einen Suchbegriff ein und bekommen Ergebnisse ausgespielt. Doch was muss alles passieren, damit Suchmaschinen den passenden Treffer zur Suchanfrage liefern können? Welcher Prozess ist dabei notwendig? Das Verständnis über die Funktionsweise von Suchmaschinen kann SEOs helfen, die Arbeitsweise besser zu verstehen, um so sinnvolle Optimierungen einzuleiten. Daher geht es in diesem Beitrag um:

2 Sachen noch vorweg: Es geht hier nicht um die geheimen Algorithmen von Suchmaschinen. Also um die Art und Weise wie Webseiten bewertet werden und wie sich daraus die Ranking-Position ermittelt. Zudem muss gesagt werden, dass die Systeme deutlich komplexer sind und ablaufen als hier dargestellt. Auch wenn einzelne Aspekte im Detail betrachtet werden, ist es doch nur als Einführung in die Systemarchitektur von Suchmaschinen zu verstehen.

Information Retrieval (IR)

Basis bei allen Suchmaschinen ist das Grundprinzip des Information Retrieval (IR; zu deutsch „Informationsrückgewinnung“). Dabei handelt es sich um einen Begriff aus der Informatik. Im Zentrum steht die computergestützte Suche nach komplexen Inhalten. Grundvoraussetzung ist eine große Datenmenge, mit denen das System folgendes macht:

  • Informationen durchsuchen
  • Informationen bewerten
  • Informationen gewichten

Ziel ist es vorhandene Informationen einfach zugänglich zu machen. Für diese Informationsrückgewinnung gibt es in der Theorie verschiedene Modelle (Retrievalmodelle). Dazu gehören:

  • Boolesches Modell: Dieses arbeitet mit den 3 Funktionen UND, ODER und NICHT. Dabei wird nur nach Informationen gesucht. Eine Gewichtung und ein Ranking findet dabei nicht statt.
  • Textstatistik: Hier existieren WDF*IDF (kennt man im SEO), Vektorraummodell (eine bestimmte Art und Weise wie die Ähnlichkeit von Wörtern bestimmt werden kann) und das probabilistische Modell (Wahrscheinlichkeitsrechnung zum Matching von Dokument und Suchbegriff).
  • Linktopologische Modelle: Diese Modelle basieren auf den Verlinkungen zwischen den Webseiten im WWW. Hier gibt es den Kleinberg-Algorithmus und den PageRank. Der Kleinberg-Algorithmus basiert auf einem Zusammenspiel zwischen Hubs (ausgehende Links) und Authorities (eingehende Links). Der PageRank wurde von den Google-Gründern Sergey Brin und Lawrence Page entwickelt, wo Informationen (bzw. Seiten) anhand ihrer Verlinkungsstruktur bewertet werden.
  • Clustermodell: Mit diesem Modell wird versucht ähnliche Dokumente zusammen in einem Pool zu speichern. Bei der Suche nach Informationen können so alle Dokumente aus dem Pool schneller ausgespielt werden.
  • Nutzer-Nutzungsmodell: Hier steht die Nutzungshäufigkeit eines Dokuments durch einen Nutzer als Ranking-Faktor im Vordergrund.

Am Ende ist das Ziel von Suchmaschinen Ergebnisse zu speichern, um diese dem Nutzer schnell zur Verfügung zu stellen. Bei einer Suchanfrage durchforstet die Suchmaschine nicht „Live“ das Web. Das wäre zu aufwendig bzw. auch fast unmöglich. Daher müssen Suchmaschinen die Informationen zunächst sichten, durchsuchen, bewerten, gewichten und abspeichern, um sie abrufbereit zu machen. Wie das funktioniert, schauen wir uns nachfolgend an.

Die Basis

Als Basis dient uns die nachfolgende Ausgangslage. Auf der einen Seite gibt es Webseiten im World Wide Web und auf der anderen Seite gibt es einen Such-Index (in diesem Fall Google), der die zahlreichen Webseiten im World Wide Web auf Basis von Suchbegriffen auffindbar macht.

Der Grob-Vorgang

Damit die Webseite im Such-Index auffindbar ist muss folgender Prozess grob durchlaufen werden:

  1. Crawling: Der Crawler (Bot, Robot) wird vom Scheduler gesteuert, holt die Dokumente und legt sie ins Repository ab.
  2. Indexierung: Der Indexer holt sich die Daten aus dem Repository, bereitet sie auf und übergibt sie an den Such-Index.

Auf Basis der obigen Darstellung sieht das Ganze visuell folgendermaßen aus:

Der Detail-Vorgang

Jetzt schauen wir etwas tiefer unter die Haube. Dazu beleuchten wir den nachfolgenden Prozess und folgende Begriffe:

Crawler

Ganz am Anfang steht der Crawler (oder auch Bot bzw. Robot), der das Web nach URLs durchforstet. Dabei ruft er eine URL auf und versucht allen internen und externen Links zu folgen. Grob gesagt macht der Crawler folgendes:

  • Nach Vorgabe des Schedulers holt er sich ein Web-Dokument
  • Das Dokument wird im Anschluss an der Storeserver weitergereicht

Der Crawler spielt dabei ganz eng mit dem Scheduler zusammen, der ihm mitteilt, welche URL aufgerufen werden soll.

Visuell dargestellt sieht das vereinfacht wie folgt aus:

Scheduler

Scheduler kommt vom Englisch „schedule“ und bedeutet so viel wie „Zeitplan“. Hauptsächlich handelt es sich beim Suchmaschinen-Scheduler um einen Prozess-Scheduler, der „die zeitliche Ausführung mehrerer Prozesse in Betriebssystemen regelt.“

Aus SEO-Sicht ist die Hauptaufgabe des Schedulers dem Crawler URLs, die gecrawlt werden müssen, mitzuteilen. Ganz wichtig ist dabei die Ermittlung der Crawling-Intervalle. Denn: Inhalte auf URLs können sich ändern und der Suchmaschinen-Index muss dementsprechend aktualisiert werden. Wenn sich der Inhalt oft ändert, so werden die Crawling-Intervalle verkürzt. Umgekehrt werden die Crawling-Intervalle verlängert, wenn sich kaum oder selten was auf dem Dokument ändert. Ziel ist es, Ressourcen zu sparen:

  • URLs wie Impressum, die Datenschutzerklärung oder andere Seiten, die sich kaum ändern, müssen dadurch nicht so oft gecrawlt werden.
  • Seiten, deren Inhalte oft aktualisiert werden, können dadurch schneller besucht werden, was den Index aktuell hält.

Der Scheduler kommuniziert auch ständig mit den Crawlern, die gerade im Web unterwegs sind. Durch diese Verbindung kann der Scheduler auch die einzelnen Crawler steuern, um die Auslastung optimal zu verteilen.

Beim Scheduler spielt zudem die genaue Berechnung der Intervalle und der Priorität einzelner URLs eine zentrale Rolle. Bei dieser Aufgabe hilft ihm der Storeserver.

Grob gesagt macht der Scheduler folgendes:

  • Vom Storeserver bekommt er eine „saubere“ URL-Liste
  • Diese URLs werden an der Crawler weitergegeben

Demnach haben wir nun folgendes Bild:

Storeserver

Nachdem der Crawler die Dokumente an den Storeserver (auch URL-Server genannt) weitergereicht hat, passiert folgendes:

  • Auswertung HTTP-Response-Header: Diese Informationen bekommt er vom Crawler. Hier spielt vor allem der Status Code eine wichtige Rolle. Bekommt der Storeserver einen Fehlercode (z.b. 404 oder 500), wird dies vermerkt. Diese Informationen werden an den Scheduler gegeben, der dann den wiederholten Zugriff steuern kann (Berechnung Crawling-Intervalle). Werden hier Redirect-Codes zurückgegeben, dann entscheidet der Storeserver, ob und wann der Dokumentenindex aktualsiert wird.
  • Index-Aktualisierung: Dies betrifft hauptsächlich Seiten, die im Dokumentenindex schon existieren. Siehe hierzu den vorherigen Punkt, wo auf Basis der Informationen aus dem HTTP-Response-Header der Dokumentenindex aktualisiert wird.
  • Aufnahmeprüfung: Dies betrifft hauptsächlich Seiten, die noch nicht im Dokumentenindex und dem System neu sind. Der Storeserver führt dabei Blacklists und Filter. In den Blacklists werden unerwünschte Webseiten geführt. Dies kann aus rechtlichen Gründen sein. Oder bestimmte Begriffe und Inhalte sind in einigen Ländern nicht erlaubt. Hier erfolgt dann eine Prüfung. Anhand von Filtern werden aber hier auch Duplicate Content Seiten erkannt. Erst wenn die URL diese Aufnahmeprüfung besteht, kommt es zur Weitergabe an den Dokumentenindex und das Repository.

Hauptaufgabe des Storeservers ist also die Koordination der gecrawlten Seiten zur Weiterverarbeitung. Dabei existiert grob der folgende Prozess:

  • Der Storeserver bekommt die URLs vom Crawler
  • Informationen zur Berechnung der Crawling-Intervalle werden dem Scheduler zur Verfügung gestellt
  • Weitergabe Informationen zum Dokumentenindex, um Einträge ggf. zu aktualisieren
  • Weitergabe der Seite an das Repository

Dokumentenindex

Der Dokumentenindex ist ein Datenspeicherungsmodul. Wurde eine URL vom Storeserver erfolgreich an den Dokumentenindex überreicht, bekommt sie zunächst eine eindeutige DocID zugewiesen. Zu der DocID werden unter anderem folgende Informationen mitgespeichert:

  • Dokumentenstatus
  • Dokumenttyp
  • IP-Adresse
  • Erstellungsdatum inkl. Aktualisierungszeitpunkte
  • Dokumentenlänge

Um Ressourcen zu sparen werden hier keine direkten Informationen als Text gespeichert. Dies wird alles in Ziffern umgewandelt. So steht bspw. die 2 für den Status Code 404. Über Hexadezimalcodes kann die Suchmaschine jedoch die Informationen auslesen.

Mit dem Dokumentenindex lassen sich einzelne URLs abgleichen. Im Gesamtkonstrukt ist der Dokumentenindex wie folgt aufgehoben:

  • Der Dokumentenindex bekommt Seiten vom Storeserver
  • Es existiert eine Verbindung zum Repository, um bei Änderungen URLs abgleichen zu können
  • Der Dokumentenindex reicht Seiten an den Such-Index weiter

Repository

Das Repository (englisch für Lager oder Depot) ist ebenfalls ein Datenspeicherungsmodul (laut Wikipedia: „Ein Repository […] ist ein verwaltetes Verzeichnis zur Speicherung und Beschreibung von digitalen Objekten für ein digitales Archiv.“). Auch hier funktioniert es ähnlich wie beim Dokumentenindex: Wurde eine URL vom Storeserver erfolgreich an das Repository überreicht, bekommt sie zunächst eine eindeutige DocID zugewiesen. Die DocID ist die gleiche wie im Dokumentenindex, um eine Verbindung herzustellen. Die URL im Repository ist eine Art Kopie der URL aus dem Dokumentenindex. Jedoch wird hier das gesamte HTML inkl. den Informationen aus dem Dokumentenindex komprimiert abgespeichert. Sobald nun das gleiche Dokument in einer aktualisierten Version geliefert wird, erfolgt eine Aktualisierung des Eintrags. Der alte Eintrag wird archiviert. Wie viele Archiv-Versionen einer einzelnen URL existieren und wie lange diese aufbewahrt werden, ist nicht bekannt.

Das Repository ist wie folgt in die Architektur eingebunden:

  • Das Repository bekommt Seiten vom Storeserver
  • Es existiert eine Verbindung zum Dokumentenindex, um bei Änderungen URLs abgleichen zu können
  • Das Repository reicht Seiten an den Indexer und Parser weiter

Indexer und Parser

Der Indexer ist zuständig für die Informationsverarbeitung. Im ersten Schritt holt er sich das Dokument aus dem Repository und dekomprimiert es, um es weiter verarbeiten zu können. Danach kommen verschiedene Filter zum Einsatz:

  • Normalisierung
  • Tokenizing
  • Lower-Case-Convert
  • Language Detection
  • Word Stemming
  • Stoppwort-Analyse
  • Keyword-Extraktion und -Analyse
  • Vergabe einer WordID

Schauen wir uns die einzelnen Aufgaben etwas näher an.

Normalisierung
Im ersten Schritt muss der Indexer alle notwendigen und relevanten Informationen aus dem Quellcode extrahieren. Dabei werden alle Anweisungen, die der Formatierung oder Programmierung dienen, entfernt. Hauptsächlich werden hier HTML-Tags entfernt.

Tokenizing
Liegt der reine Text vor, muss der Tokenizer Wörter sinnvoll erfassen. Das ist gar nicht so einfach. Ein paar Beispiele:

  • Beim Satz „Ich binein Textabschnitt“ wird zwischen „bin“ und „ein“ kein Leerzeichen gesetzt.
  • Bei „Ich bin ein Text Abschnitt“ muss die Suchmaschine „Text Abschnitt“ so verstehen, da dies keine 2 einzelne Wörter in diesem Sinne sind, sondern dass es sich um 1 Wort handelt.

Auf einfache Regeln wie „ein Leerzeichen ist immer als Wort-Trenner zu sehen“ können sich Suchmaschinen nicht verlassen. Bei „Los Angeles“ existiert zwar ein Leerzeichen, aber die 2 Wörter gehören stark zusammen. Hier setzen Suchmaschinen diverse, komplexe Systeme zur Identifizierung von Wörtern ein.

Lower-Case-Convert
Liegen die einzelnen Wörter vor, werden alle in Kleinschreibung umgestellt. Dadurch lässt sich einfacher weiterarbeiten, analysieren und Vergleiche aufstellen.

Language Detection
Nun müssen Suchmaschinen erkennen, um welche Sprache es sich handelt, da dies für den weiteren Prozess von großer Bedeutung ist. Auch hier setzen Suchmaschinen unterschiedliche Systeme ein, um die Sprache zu erkennen. Durch einen Abgleich mit Wörterbüchern und anderen Dokumenten kann die Sprache identifiziert werden. Auch werden hier Meta-Angaben wie das Language-Tag oder Hreflang-Tag herangezogen. Da dies jedoch nicht alle Seiten anwenden, kann sich die Suchmaschine nicht allein auf die Angaben verlassen.

Word Stemming
Hier wird jedes Wort auf seine Grundform zurückgeführt. Wörter wie z.B. „optimieren“, „optimiertes“ und „optimierend“ werden zu „Optimierung“ hinzugerechnet. Es wird also die Wort-Grundform gespeichert und alle anderen Formen liegen darunter. Dadurch kann die Suchmaschine auch Dokumente zu Suchanfragen wie „Optimierung“ ausliefern, die nicht „Optimierung“ im Text stehen haben, sondern nur „optimieren“.

Stoppwort-Analyse
Danach werden alle Stoppwörter herausgefiltert, da diese meist eher uninteressant für die Relevanzbewertung sind. Es werden jedoch auch Systeme eingesetzt, die überprüfen, ob es Sinn macht Stoppwörter mit einzubeziehen. Stoppwörter sind bspw. und, aber, du, er, etc. Dies reduziert die Anzahl der zu analysierenden Wörter erheblich.

Keyword-Extraktion und -Analyse
Jetzt verbleiben nur noch die relevanten Begriffe für die Suche. Hier wird noch folgendes gemacht:

  • Die Rechtschreibung wird überprüft. Dabei erfolgt ein Abgleich der vorliegenden Wörtern mit Wörterbüchern.
  • Synonyme werden identifiziert und miteinander in Verbindung gebracht.
  • Homonyme werden identifiziert und verarbeitet.
  • Zudem findet ein Begriffsverständnis statt: „Berlin“ ist eine Stadt und „Deutschland“ ist ein Land.

WordID
Als letzten Schritt bekommen die Begriffe eine eindeutige ID, die sog. WordID. So wird aus „autofachwerkstätte“ einfach „#2222“. Der Vorteil wird hier ersichtlich: Das System spart sich hier Platz und Größe, da die WordID deutlich kürzer ist.

An diesen Punkt haben wir folgenden Stand:

Such-Index

Nach dem nun Indexer und Parser ihre Arbeit getan haben ist der letzte Schritt – bevor der Such-Index die Arbeit übernimmt – die Übergabe der Schlüsselbegriffe in eine Liste (die sog. Hit-List). Im Anschluss gehen die Informationen in den direkten Index, um weiter im Anschluss in den invertierten Index überzugehen. Der Such-Index besteht also aus 3 Teilen:

  • Hit-List
  • Direkter Index
  • Invertierter Index

Hit-List
Die gelieferten Keywords vom Indexer und Parser landen nun zunächst in der Hit-List. Dabei wird für jedes Keywords diese Hit-List erstellt. Die Begriffe werden nun mit weiteren Informationen versehen. Die hier gespeicherten Informationen beantworten diverse Fragen:

  • Kommt das Keyword in der H1 vor?
  • Kommt das Keyword im Title vor?
  • Kommt das Keyword im Fließtext vor?
  • und so weiter

Jedes Keyword eines Dokuments wird so in die Hit-List abgelegt. Das Dokument ist durch die DocID mit dem Dokumentenindex verknüpft. Die Hit-List könnte so aussehen:

KriteriumGewichtungKeyword 1Keyword 2Keyword 3
H18XX
Title8XX
Fließtext4X
Summe81612

Wie man sehen kann existieren verschiedene Kriterien, die auch als Ranking-Faktoren genannt werden. Jeder dieser Kriterien bekommt eine Gewichtung. Je höher diese ist, desto mehr Einfluss hat es auf das Endergebnis. Wenn ein Keyword auf ein Kriterium zutrifft wird es hier gespeichert. Am Ende bekommt jedes Keyword eine Summe, welche die Grundlage für eine Relevanzbestimmung des Keywords für das jeweilige Dokument darstellt.

Direkter Index
Nachdem jedes Keyword in der Hit-List berechnet wurde, werden diese Informationen im direkten Index abgespeichert. Man kann es sich als eine Art „komprimierte Hit-List“ vorstellen. So könnte diese aussehen:

DocIDKeywordWert
#1111keyword 18
#1111keyword 216
#1111keyword 312

Ziel ist hierbei die notwendigen Informationen möglichst effizient und komprimiert abzulegen, damit ein schneller Zugriff darauf erfolgen kann. Deshalb wird hier nicht die komplette URL des Dokuments abgelegt, sondern nur die DocID. Auch wird in der obigen Tabelle das Wort nicht so abgelegt, sondern als WordID, was weiter zur Speicherplatz-Optimierung führt. Somit existiert auch eine Verknüpfung zum Parser. Die fast endgültige Tabelle könnte so aussehen:

DocIDWordIDWert
#1111#22228
#1111#222116
#1111#222312

Nun muss das nicht das Ende sein, denn so eine Tabelle lässt sich nur schwer in einer kodierten Datei direkt so abbilden. Daher wird in der direkten Datei (deshalb „direkter Index“), die später abgerufen wird die obige Tabelle wie folgt durch Codes dargestellt:

  • 0111102222080
  • 01111022210160
  • 01111022230120

Durch die Komprimierungen gehen jedoch keine Verknüpfungen verloren. Anhand der Codes bzw. Kennzahlen kann der Index zwischen Query-Prozessor (kommen wir gleich) und dem Dokumentenindex und Repository direkt vermitteln, was einen schnellen Zugriff ermöglicht.

An diesem Zeitpunkt kann der Nutzer alle Keywords zu einem bestimmten Dokument erfahren. Jedoch ist dies aus Sicht des Suchenden irrelevant. An dieser Stelle müsste der Nutzer – wenn es nach dem direkten Index geht – ein Dokument als Suchanfrage angeben und bekommt dazu die Keywords des Dokuments.

Invertierter Index
Es braucht also ein System, welches nicht nach Dokumenten, sondern nach Keywords ausgerichtet ist. Hier kommt der invertierte Index ins Spiel, mit dem man auch den eigentlichen „Index“ meint. Die aus Sicht von SEOs stattfindende Indexierung findet hier statt. Dabei kommt zunächst ein sog. „Sorter“ zum Einsatz, der einen nach DocID sortierten Index in einen nach WordID sortierten Index umwandelt. Zu beachten ist hier, dass der direkte Index hier nicht gelöscht wird. Dieser bleibt besteht, damit der Prozess – wenn der Nutzer eine Suchanfrage abgibt – auch von hinten durchgespielt werden kann, um sich so wieder bis zum Dokumentenindex zurückarbeiten zu können. Oben beim direkten Index haben wir gesehen, dass die Tabelle nach DocID sortiert wurde. Beim invertierten Index wird der Spieß umgedreht und schaut in etwa so aus:

WordIDDocID
#2222#1111, #1112, #1234, #9584, …
#2221#2342, #1112, #6587, #5555, …
#2223#1111, #7859, #1234, #3652, …

Startpunkt sind nun nicht mehr die Dokumente, sondern die Keywords (WordID). Bei einer Suchanfrage wird das Keyword im invertierten Index gesucht, um die entsprechenden Dokumente zu finden. Anhand dieser Information kann dann der Query-Prozessor die Dokumente in der jeweiligen Reihenfolge (Ranking-Position auf Basis der Bewertung in der Hit-List) dem Nutzer ausspielen. Durch die DocID kann der invertierte Index wieder auf den direkten Index zugreifen. Wie die Verknüpfungen hier im Detail aussehen und welche Verknüpfungen im Detail existieren ist von Suchmaschine zu Suchmaschine verschieden und meist nicht bekannt. Fest steht: Anhand dieser Verbindungen entsteht bei den Suchmaschinen eine komplexe Systemarchitektur.

Bisher konnte man aber deutlich sehen, wie wichtig diese einzelnen Komponenten sind, damit eine Suchmaschine effizient Ergebnisse ausspielen kann, um so nicht jedes Mal auf das ursprüngliche Dokument zuzugreifen, was deutlich langsamer stattfinden würde.

Status Quo:

Query-Prozessor

Der Query-Prozessor beantwortet Fragen der Nutzer. Klingt einfach, ist es aber nicht ganz so. Bisher haben wir gesehen, was alles geschehen muss, damit eine Suchmaschine Ergebnisse ausspielen kann. Den Nutzer interessiert das alles nicht so sehr. Wichtig für den Nutzer ist es, dass die Ergebnisse schnell da sind. Dabei geht der Prozessor wie folgt vor:

  • Der Nutzer gibt eine Suchanfrage in den Suchschlitz ein
  • Wie beim Indexer muss die Suchangabe auf das wesentliche heruntergebrochen werden
  • Aus „wie ist das wetter in münchen aktuell“ wird „wetter münchen“
  • Der Query-Prozessor greift auf den invertierten Index zurück
  • Im invertierten Index werden passend zum Suchbegriff die Dokumente dem Query-Prozessor zur Verfügung gestellt
  • Die Suchergebnisse sind für die Anzeige bereit

Bevor die Suchergebnisse aber endgültig angezeigt werden, müssen noch diverse Faktoren und (individuelle) Such-Einstellungen blitzschnell berücksichtigt werden:

  • Standort des Nutzers
  • Eingestellte Sprache des Nutzers
  • Gerät (Desktop, Mobile, Tablet)
  • Platzierung von Featured oder Rich Snippets
  • und vieles mehr

Diese Aspekte dienen dazu ein generisches Suchergebnis auszuspielen. Es gibt jedoch auch personalisierte Suchergebnisse, die im eingeloggten Zustand ausgespielt werden. Hier müssen weitere Aspekte vom Query-Prozessor berücksichtigt werden:

  • Such-Verlauf
  • SafeSearch-Filter
  • Ergebnisse pro Seite
  • Private Ergebnisse
  • Regionseinstellungen
  • Spracheinstellungen

Wenn das alles erfolgt ist, kommen wir an den Punkt, wo die Suchergebnisse ausgespielt werden können:

Mit dem Ausspielen des Suchergebnisses kommen wir auch schon ans Ende. Wie erwähnt ist der Prozess und das System deutlich komplexer als hier dargestellt. Viele Vorgehensweisen halten die Suchmaschinen zudem geheim. Hinzu kommen diverse Techniken, die an verschiedenen Meilensteinen im Bearbeitungsprozess wie oben dargestellt ansetzen und die Ergebnisse weiter verfeinern, was das System noch komplexer macht. Welche weiteren Techniken zum Einsatz kommen kannst du nachfolgend lesen. Dies ist jedoch keine vollständige Liste aller möglichen Anwendungen, die zum Einsatz kommen.

Weitere Techniken

Die vorgestellte Vorgehensweise wie Suchmaschinen Antworten liefern ist nur ein Bruchteil dessen, was alles im Hintergrund tatsächlich passiert. In Wirklichkeit sind die Systeme und Mechanismen deutlich komplexer. Zum Schluss möchte ich aber dennoch ein paar weitere Techniken vorstellen, die in einer gewissen Art und Weise vorkommen.

  • Semantische Interpretationen einer Suchanfrage: In einem im Jahr 2016 veröffentlichten Patent mit dem Titel „Evaluating semantic interpretations of a search query“ hat Google den Prozess beschrieben, wie die Suchmaschine mit einer Suchanfrage mit mehreren möglichen Bedeutungen und Suchabsichten umgeht. So könnte die Suchanfrage „Wie lang ist Harry Potter?“ mehrere Bedeutungen haben: Wie viele Seiten hat das Buch von Harry Potter? Wie lang ist der Film von Harry Potter? Wie groß ist Harry Potter? Um das korrekte Suchergebnis auszuspielen werden hier für alle möglichen Bedeutungen die Suchergebnisse zunächst analysiert. Wenn die Ergebnisse für „Wie lang ist Harry Potter?“ am ehesten mit „Wie lang ist der Film von Harry Potter?“ übereinstimmt, dann werden diese Ergebnisse für die uneindeutige Suchanfrage herangezogen. Ob der Algorithmus richtig lag und das Bedürfnis des Nutzer abgedeckt hat, wird dann mittels Metriken wie Klickdaten gemessen.
  • Triplestore: Hier handelt es sich um Datenbanken (Triplestore-Datenbanken). Informationen werden darin als „Triple“ abgespeichert, die aus 2 Knoten bestehen. Die 2 Knoten werden mit einer Kante verbunden, damit eine Beziehung hergestellt werden kann. So können Begriffe und Informationen in Beziehung zueinander gestellt werden und ergeben dann auch aus Suchmaschinen-Sicht logische Aussagen. Dadurch entsteht ein semantisches Netz. Suchmaschinen sind dann in der Lage zu wissen, dass Berlin die Hauptstadt von Deutschland ist oder dass das Oktoberfest in München stattfindet.
  • WDF*IDF: WDF steht für „Within Document Frequency“ und IDF für „Inverse Document Frequency“. WDF misst die Häufigkeit eines Keywords in einem Dokument im Verhältnis zu allen anderen Keywords im jeweiligen Dokument. IDF misst die Häufigkeit eines Keywords in einem Dokument im Verhältnis zum gleichen Keyword in allen anderen Dokumenten (im Such-Index). Mit dem Ergebnis lässt sich dann bestimmen, ob ein Begriff öfter oder weniger oft im Dokument erwähnt werden soll.
  • N-Gramm: „N-Gramme sind das Ergebnis der Zerlegung eines Textes in Fragmente.“. Die Fragmente können Wörter oder auch Buchstaben sein. In der Analyse (N-Gramm-Analyse) kann man z.B. die Frage beantworten, wie wahrscheinlich nach einem Wort ein bestimmtes Wort folgen wird. Mit solchen Analysen sind Suchmaschinen in der Lage Spam-Texte zu erkennen, die automatisiert erstellt wurden.
  • Neural Matching: Neural Matching basiert auf künstlicher Intelligenz und ist eine Methode, um Begriffe besser miteinander zu verbinden. Hier steht das Verständnis von Synonymen im Vordergrund. Bei der Anfrage „Ich finde keinen Supermarkt in der Nähe“ muss hier das System in der Lage sein, dies als Anfrage „Wo ist der nähste Supermarkt?“ zu verstehen.
  • RankBrain: Google selbst sagt, dass etwa 15 % aller Suchanfragen noch nie gestellt worden sind. Genau damit beschäftigt sich Googles RankBrain-Algorithmus, der auf einer künstlichen Intelligenz basiert.
  • JavaScript: Bei JavaScript-lastigen Inhalten und Webseiten muss Google deutlich mehr Arbeit leisten. Hier wird mit einer sog. „Two-wave Indexierung“ vorgegangen. Nach der initialen Indexierung des HTML muss der Bot zunächst ausrechnen, ob genug Rechenleistung für die Interpretation von clientseitigen Code zur Verfügung steht. Erst dann werden JavaScript-Inhalte indexiert. Dies kann unter Umständen dazu führen, dass JS-Inhalte mit einer zeitlichen Verzögerung im Index vorzufinden sind. Mehr zu diesem Thema findest du in meinem Beitrag „JavaScript und SEO“.

Last modified: 13. August 2019

Diese Webseite verwendet Cookies um den vollen Funktionsumfang der Webseite und damit ein besseres Online-Erlebnis bieten zu können. Es werden auch Cookies verwendet, um Zugriffe auf die Webseite zu analysieren. Außerdem gibt die Webseite Informationen zu Deiner Verwendung dieser Webseite an Partner für Analysen weiter. Technisch nicht notwendige Cookies und Tracking-Cookies werden erst aktiviert, nachdem die Einwilligung erteilt wurde.
Alle zulassen
Alle ablehnen
Cookie-Einstellungen
Diese Webseite verwendet Cookies um den vollen Funktionsumfang der Webseite und damit ein besseres Online-Erlebnis bieten zu können. Es werden auch Cookies verwendet, um Zugriffe auf die Webseite zu analysieren. Außerdem gibt die Webseite Informationen zu Deiner Verwendung dieser Webseite an Partner für Analysen weiter. Technisch nicht notwendige Cookies und Tracking-Cookies werden erst aktiviert, nachdem die Einwilligung erteilt wurde.
Alle zulassen
Alle ablehnen
Cookie-Einstellungen
Impressum
Datenschutz