Dienstag, 31. März 2026
Wenn ihr euch Folge 105 des Podcasts „Search Off the Record“ angehört habt, wisst ihr vielleicht, dass wir uns dort ausführlich mit einem Thema beschäftigt haben, das uns (und unseren Servern) sehr am Herzen liegt: der Funktionsweise des Googlebots.
Lange Zeit hat der Name „Googlebot“ das Bild eines einzelnen, unermüdlichen Roboters hervorgerufen, der das Internet systematisch durchforstet. Die Realität ist jedoch etwas komplexer – und viel interessanter. Heute möchten wir einen Blick unter die Haube unserer Crawling-Infrastruktur werfen und uns dabei insbesondere auf etwas konzentrieren, das uns selbst Kopfzerbrechen bereitet: die Byte-Größenbeschränkungen.
Der Googlebot ist kein einzelnes Programm
Zuerst möchten wir mit einem historischen Irrtum aufräumen. Anfang der 2000er-Jahre hatte Google nur ein Produkt und daher auch nur einen Crawler. Der Name „Googlebot“ hat sich durchgesetzt. Heute ist der Googlebot jedoch nur ein Nutzer von etwas, das einer zentralisierten Crawling-Plattform ähnelt.
Wenn ihr den Googlebot in euren Server-Logs seht, beziehen sich die Daten nur auf die Google Suche. Dutzende anderer Clients wie Google Shopping und AdSense leiten ihre Crawling-Anfragen über dieselbe zugrunde liegende Infrastruktur unter anderen Crawler-Namen. Die größeren Crawler sind auf der Website zur Google-Crawler-Infrastruktur dokumentiert.
Das Limit von 2 MB: Was passiert mit euren Bytes?
An dieser Stelle wird es etwas verwirrend. Jeder Client der Crawler-Infrastruktur muss einige Einstellungen für seine Abrufe festlegen. Diese Einstellungen umfassen den User-Agent-String, die User-Agent-Tokens, nach denen gesucht wird, und die Anzahl der Bytes, die von einer einzelnen URL abgerufen werden.
Der Googlebot ruft derzeit bis zu 2 MB für jede einzelne URL ab (mit Ausnahme von PDFs). Das bedeutet, dass nur die ersten 2 MB einer Ressource gecrawlt werden, einschließlich des HTTP-Headers. Für PDF-Dateien gilt ein Limit von 64 MB.
Bild- und Video-Crawler haben in der Regel eine Vielzahl von Grenzwerten, die weitgehend vom Produkt abhängen, für das sie Daten abrufen. Das Abrufen eines Favicons kann beispielsweise ein sehr niedriges Limit haben, im Gegensatz zur Bildersuche.
Für alle anderen Crawler, die kein Limit angeben, gilt unabhängig vom Inhaltstyp ein Standardlimit von 15 MB.
Was bedeutet das für die Bytes, die euer Server über das Netzwerk sendet?
- Teilweises Abrufen: Wenn eure HTML-Datei größer als 2 MB ist, wird die Seite nicht vom Googlebot abgelehnt. Stattdessen wird der Abruf genau bei 2 MB beendet. Das Limit umfasst auch HTTP-Anfrageheader.
- Umgang mit dem Grenzwert: Der heruntergeladene Teil (die ersten 2 MB) wird an unsere Indexierungssysteme und den Web-Renderingdienst (Web Rendering Service, WRS) weitergegeben, als wäre es die vollständige Datei.
- Die nicht sichtbaren Bytes: Alle Bytes, die nach dem Grenzwert von 2 MB vorhanden sind, werden vollständig ignoriert. Sie werden nicht abgerufen, gerendert oder indexiert.
- Ressourcen einbinden: Jede referenzierte Ressource im HTML-Code (mit Ausnahme von Medien, Schriftarten und einigen exotischen Dateien) wird vom WRS mit dem Googlebot wie der übergeordnete HTML-Code abgerufen. Sie haben einen eigenen, separaten Byte-Zähler pro URL und werden nicht auf die Größe der übergeordneten Seite angerechnet.
Für den Großteil des Webs ist eine HTML-Nutzlast von 2 MB enorm und ihr werdet dieses Limit nie erreichen. Wenn eure Seite jedoch aufgeblähte Inline-Base64-Bilder, riesige Blöcke mit Inline-CSS/JavaScript oder Megabytes an Menüs enthält, kann es passieren, dass eure eigentlichen Textinhalte oder wichtigen strukturierten Daten hinter der 2-MB-Marke liegen. Wenn diese wichtigen Bytes nicht abgerufen werden, existieren sie für den Googlebot einfach nicht.
Rendering der Bytes
Sobald der Crawler die Bytes (bis zum Limit) abgerufen hat, übergibt er die Arbeit an den WRS. Der WRS verarbeitet JavaScript-Code und führt clientseitigen Code ähnlich wie ein moderner Browser aus, um den endgültigen visuellen und textlichen Zustand der Seite zu ermitteln. Beim Rendering werden JavaScript- und CSS-Dateien abgerufen und ausgeführt sowie XHR-Anfragen verarbeitet, um den Textinhalt und die Struktur der Seite besser zu verstehen. Bilder oder Videos werden dabei nicht angefordert. Das Limit von 2 MB gilt auch für jede angeforderte Ressource.
Der WRS kann jedoch nur den Code ausführen, den der Crawler tatsächlich abgerufen hat. Außerdem arbeitet der WRS zustandslos – der lokale Speicher und die Sitzungsdaten werden zwischen Anfragen gelöscht. Dies kann sich insbesondere darauf auswirken, wie dynamische, JavaScript-abhängige Elemente von unseren Systemen interpretiert werden.
Best Practices für eure Bytes
Damit der Googlebot eure Inhalte effizient abrufen und verstehen kann, solltet ihr die folgenden Best Practices auf Byte-Ebene beachten:
- HTML-Code schlank halten: Verschiebt umfangreichen CSS- und JavaScript-Code in externe Dateien. Das HTML-Hauptdokument wird bei 2 MB abgeschnitten. Externe Skripts und Stylesheets werden jedoch separat abgerufen und unterliegen eigenen Limits.
-
Reihenfolge ist wichtig: Platziert die wichtigsten Elemente wie Meta-Tags,
<title>-Elemente,<link>-Elemente, kanonische URLs und wichtige strukturierte Daten weiter oben im HTML-Dokument. So ist es unwahrscheinlich, dass sie hinter dem Grenzwert liegen. - Server-Logs im Blick behalten: Achtet auf die Antwortzeiten eures Servers. Wenn euer Server Schwierigkeiten hat, Bytes bereitzustellen, ziehen sich unsere Crawler automatisch zurück, um eure Infrastruktur nicht zu überlasten. Dadurch sinkt die Crawling-Frequenz.
Dieses Limit ist nicht in Stein gemeißelt und kann sich im Laufe der Zeit ändern, wenn sich das Web weiterentwickelt und HTML-Seiten größer werden. (Oder sich verkleinern. Das wäre wünschenswert.)
Das Crawling ist kein magischer Vorgang, sondern ein sehr gut organisierter, skalierter Austausch von Bytes. Wenn ihr wisst, wie unsere zentrale Abrufinfrastruktur diese Bytes abruft und begrenzt, könnt ihr dafür sorgen, dass die wichtigsten Inhalte eurer Website immer berücksichtigt werden.
Viel Erfolg bei der Optimierung!
Möchtet ihr genauer hinter die Kulissen schauen? Seht euch Folge 105 des Podcasts „Search Off the Record“ auf YouTube oder auf anderen Podcast-Plattformen an.