Manchmal überrascht es mich, wie sehr Google seine Dokumentationen im Detail pflegt. Kaum eine Woche vergeht, ohne dass irgendwo in den Entwicklerseiten eine kleine Änderung auftaucht, die Nerd-Herzen höher schlagen lässt. Kürzlich hat Google seine Unterlagen zu den Dateigrößenbeschränkungen des Googlebots überarbeitet – nichts Revolutionäres, aber trotzdem interessant, wenn du dich mit **technischem SEO** oder Crawling-Optimierung beschäftigst. Man könnte sagen: Es sind diese kleinen Details, die bei der großen Menge an Seiten den Unterschied machen, ob etwas indexiert wird oder nicht.
Die Anpassung im Überblick
Im Wesentlichen hat Google die Stelle geändert, an der die **Standardlimits für Dateigrößen** dokumentiert sind. Bisher fand man diese Angaben auf der Googlebot-Seite selbst, wo beschrieben wird, wie der Suchcrawler Webseiten abruft und welche Dateitypen unterstützt werden. Jetzt sind sie in die allgemeinen Dokumentationen zur gesamten Google-Crawling-Infrastruktur verschoben worden. Der Grund dafür leuchtet ein: Diese Grenzen gelten eben nicht nur für Googlebot, sondern auch für andere Crawler wie die von **Google Shopping, News, AdSense oder Gemini**.
Wenn du jemals versucht hast zu verstehen, warum Google eine Seite oder Ressource nicht vollständig verarbeitet, weißt du, dass solche vermeintlich kleinen Hinweise Gold wert sind. Google hat außerdem die Informationen auf der Googlebot-Seite angepasst, damit klar wird, welche Einschränkungen speziell für den **Suchcrawler** gelten.
Was sich konkret geändert hat
In der neuen Version der Dokumentation steht nun zweigeteilt, was gilt:
1. In den übergreifenden „Crawling Infrastructure“-Dokumenten findest du den **Standardgrenzwert von 15 MB**, der für alle Google-Crawler und Fetcher gilt.
2. Auf der eigentlichen Googlebot-Seite sind jetzt zwei spezifische Werte hinterlegt: **2 MB** als Maximalgröße für unterstützte Text-Dateiformate (etwa HTML, CSS oder JS) und **64 MB** speziell für PDF-Dateien.
Das heißt praktisch: Wenn du beispielsweise eine extrem umfangreiche HTML-Seite mit massig eingebetteten Skripten oder Inline-Styling betreibst, zieht Googlebot nur die ersten 2 MB dieses Dokuments in Betracht. Alles, was darüber hinausgeht, wird einfach abgeschnitten – zumindest beim normalen Crawlprozess für die Websuche. Ressourcen wie JavaScript oder CSS lädt Google wie gehabt separat nach. PDFs dürfen gesammelt allerdings bis zu 64 MB groß sein, bevor sie abgewiesen oder abgebrochen werden.
Warum diese Klärung wichtig ist
Google selbst betont, dass es sich hier weniger um eine Verhaltensänderung als um eine **Präzisierung** handelt. Das Crawling funktioniert also genauso wie bisher, aber nun ist klarer, wo die Grenzen liegen. Diese prägnante Trennung der Informationen hat vor allem organisatorischen Zweck. Seit Ende 2025 verfolgt Google nämlich eine Strategie zur **Neustrukturierung seiner Entwicklerdokumentation**, um das Crawling-Wissen von Search Central zu entkoppeln.
Im November 2025 hat Google seine Kerninformationen zum Crawling auf eine eigene Plattform verschoben. Das war ein überfälliger Schritt, denn Crawling betrifft eben nicht nur die Websuche. Dienste wie Google News oder der Gemini-Index greifen auf dieselbe technische Infrastruktur zu. Im Dezember folgten dann weitere Dokumentationsbausteine – etwa über Facettennavigation oder Guidance zur Optimierung des Crawl-Budgets. Mit dem jetzigen Update wird dieser Weg konsequent fortgesetzt.
Ein kurzer Rückblick
Falls du dich erinnerst: Der **15-MB-Limitwert** für Googlebot wurde offiziell erstmals **2022** publiziert – damals auf der Googlebot-Hilfeseite. John Mueller bestätigte damals, dass diese Grenze schon längst existierte, Google sie aber bisher nie öffentlich dokumentiert hatte. Es handelt sich also nicht um eine neue technische Schwelle, sondern lediglich um Transparenz im Umgang mit Entwicklern.
Jetzt trennt Google also systematisch zwischen allgemeinen Infrastruktureinstellungen (15 MB) und den „Produkt-spezifischen“ Grenzen – also den Limits für die Websuche selbst. Deine Seite wird also nicht plötzlich weniger gecrawlt als bisher, aber du hast endlich einen klaren Anhaltspunkt, wo die Grenze liegt, wenn du etwa **lange HTML-Dateien produzieren oder komplexe Single-Page-Apps** optimieren willst.
Was das für dich als SEO bedeutet
Das Wissen um solche Limits ist besonders nützlich, wenn du regelmäßig mit **Indexierungsproblemen** zu kämpfen hast – etwa bei großen, textreichen Landingpages, automatisch generierten Produktbeschreibungen oder aufgeblähten Blog-Artikeln mit viel eingebettetem Code. Wenn Google Teile deiner Seite abgeschnitten indexiert, kann es schlicht daran liegen, dass der 2-MB-Cutoff erreicht wurde. Ab diesem Punkt wertet der Crawler nur noch, was geladen wurde – der Rest existiert für den Algorithmus quasi nicht.
Interessanterweise bleibt offen, wie sich der allgemeine 15-MB-Wert zum 2-MB-Wert verhält. Google sagt in seinen neu organisierten Docs nichts Genaues dazu. Vielleicht hängt diese Diskrepanz mit **internen Crawler-Prozessen** oder unterschiedlichen Dateiformatbehandlungen zusammen. Persönlich vermute ich, dass die 15 MB ein globaler Standardpuffer für die gesamte Infrastruktur sind, während die 2 MB eine optimierte Begrenzung für das Parsing der HTML-Dateien in der Websuche darstellen.
Für uns Praktiker heißt das:
1. Achte darauf, dass das Haupt-HTML deiner Seite effizient bleibt.
2. Nutze **Lazy Loading**, externe Ressourcen und serverseitige Kompression.
3. Und überprüfe bei Analyseproblemen, ob deine Seitenstruktur eventuell „zu schwer“ ist.
Ein Blick auf Googles größere Strategie
Seit Ende 2025 zeichnet sich ein klarer Trend ab: Google konsolidiert seine technische Dokumentation. Statt alles unter „Search Central“ zu bündeln, entstehen mehrere spezialisierte Hubs – einer für Crawling, einer für Indexierung, einer für Rendering, und so weiter. Für dich als SEO bedeutet das zunächst etwas Umgewöhnung, weil du künftig an mehreren Orten suchen musst. Aber langfristig bringt das Vorteile: Die Informationen werden klarer, breiter gefasst, und Google kann so eigene Dienste wie „Crawlers and Fetchers“ dokumentieren, die über die Suchfunktion hinausgehen.
Ich habe das Gefühl, dass das auch Hinweis auf **neue Crawler-Typen** ist, die Google in Zukunft ausrollen könnte. Eventuell Maschinen, die speziell für KI-gestützte Suchfunktionen zuständig sind. Indem Google allgemeine Standardwerte definiert, schafft es ein gemeinsames Dach für alle seine Web-Abrufmechanismen. Dass Dokumente wie die zu den Dateigrößen zuerst angepasst werden, ist logisch – sie gelten als fundamentale Basiskriterien.
Was man daraus lernen kann
Auf einer Metaebene zeigt diese Änderung sehr gut, wie Google denkt: **Redundanz vermeiden, Klarheit schaffen, interne Strukturen angleichen.** Für uns Außenstehende ist das zwar trockene Kost, aber genau diese Transparenz hilft beim Verständnis komplexer Prozesse wie Indexierung oder der Crawl-Budget-Steuerung. Google macht es so leichter, dedizierte Hinweise für einzelne Produkte zu geben, ohne laufend Querverweise zu pflegen.
Wenn du selbst technische SEO-Dokumentationen verfasst oder ein internes Wiki pflegst, kannst du dir dieses Prinzip abschauen. Ich mache das genauso: Basiswissen trenne ich konsequent von spezifischen Sonderfällen – sonst entsteht nur Chaos. Dabei hilft mir der kleine Trick, an jede Info den „Scope“ dranzuschreiben: Gilt sie systemweit oder nur in einem bestimmten Modul? Genau das hat Google jetzt auch getan.
Der Ausblick – was als Nächstes kommt
Mich würde es nicht wundern, wenn Google in den nächsten Monaten die Seite zum Thema **„Crawling Infrastructure“** noch deutlich ausbaut. Gerade durch den wachsenden Anteil verschiedener Produkte, die eigene Fetcher nutzen, braucht Google ein flexibles und sauberes Organisationssystem. Denkbar ist, dass künftig Module dokumentiert werden, die z. B. spezielle Limits für APIs, für Bildcrawler oder für AI-Training-Crawler enthalten. Auch das Zusammenspiel zwischen **Rendering-Service und Fetch-Service** könnte bald eigenständig beschrieben werden.
Für dich als SEO-Profi oder Entwickler heißt das: Die Fragmentierung der Dokumentation ist kein Chaos, sondern eine Form der **Modularisierung**. Es zeigt, dass Google seine Crawler wie eigene Softwareprojekte behandelt – jedes mit eigenem Scope, eigener Aufgabe und eigenen Parametern. Wenn du langfristig mit Google-Ökosystemen arbeitest, ist das Know-how über solche Grundlagen schlicht ein Wettbewerbsvorteil.
Mein persönliches Fazit
Auch wenn diese Dokumentationsänderung auf den ersten Blick banal wirkt, steckt doch ein Muster dahinter. Aus meiner Sicht möchte Google drei Dinge erreichen:
1. **Transparenz** – Entwickler sollen genau wissen, wo technische Limits liegen.
2. **Trennung von Verantwortlichkeiten** – Suchcrawler sind nicht gleich Produktcrawler.
3. **Vorbereitung auf Zukunftstechnologien**, etwa KI-getriebene Indexierungsverfahren.
Wenn du also das nächste Mal im Debugging-Prozess Rätselraten betreibst, warum eine bestimmte Ressource oder ein Teil deiner Seite nicht indexiert wird, denk an diese Grenzwerte. Manchmal ist es kein Problem deines CMS oder Renderings, sondern einfach ein zu großes HTML-Konstrukt. Diese 2 MB sind schneller erreicht, als du denkst – besonders bei komplexen Themes oder dynamisch eingerollten Skripten.
Am Ende bleibt: Kein großes Drama, aber ein wichtiges Puzzleteil. Google ordnet auf, zieht Grenzen, und wir bekommen etwas mehr Orientierung. Und ehrlich gesagt – das ist in der Welt des **SEO-Crawlings** schon ein kleiner Luxus.
Zusammenfassung der Kernpunkte
- Google trennt Standard- von Produktspezifischen Regeln: 15 MB ist jetzt der allgemeine Grenzwert für alle Crawler, 2 MB für HTML-Dateien im Such-Crawl, 64 MB für PDFs.
- Keine funktionale Neuerung, sondern Dokumentationspflege: Verhalten bleibt gleich – Google präzisiert lediglich die internen Spielregeln.
- Teil einer größeren Reorganisation: Seit 2025 baut Google eine zentrale Plattform für Crawling-Informationen auf, losgelöst von Search Central.
- Relevanz für SEOs: Zu große Seiten könnten teilweise ignoriert werden; effiziente Seitenstruktur bleibt entscheidend.
Ich mag solche Updates, weil sie zeigen, dass selbst im Maschinenraum der Suchtechnologie die Details zählen. Wer diese versteht, hat beim Optimieren schlicht einen Vorsprung. Und seien wir ehrlich – genau darum geht’s doch in unserem Job.
