Mehr als die Hälfte der Seitenaufrufe im Netz stammt nicht mehr von Menschen, sondern von Crawlern, Scrapern und KI-Agenten. Der wichtigste dieser Besucher bleibt der Googlebot, denn er entscheidet, was in der Google Suche überhaupt sichtbar wird. Gleichzeitig hat Google 2026 seine Dokumentation zum Crawling an mehreren Stellen präzisiert: Dateigrößen, Crawl-Budget, IP-Adressen. Wer sein Crawling-Wissen aus 2021 bezieht, arbeitet mit veralteten Annahmen.
In diesem Beitrag erkläre ich Ihnen, wie der Googlebot crawlt und rendert, welche Limits gelten, wie Sie Ihr Crawl-Budget schonen, wie Sie echte Google-Zugriffe von Fälschungen unterscheiden und was die wachsende Zahl an KI-Crawlern für Ihre Website bedeutet. Die Zahlen zum Bot-Traffic halte ich über Fakten-Karten aktuell. Stand: 4. September 2026.
Was ist der Googlebot?
Der Googlebot ist der Web-Crawler der Google Suche: ein Programm, das Webseiten automatisch abruft, ihre Links verfolgt und die Inhalte an die Indexierung übergibt. Er tritt in zwei Varianten auf, Googlebot Smartphone und Googlebot Desktop, und kündigt sich über seinen User-Agent-String an. Ohne einen Besuch des Googlebot kann eine Seite nicht in den Suchergebnissen erscheinen.
Technisch ist der Googlebot nur ein Produkt einer gemeinsamen Crawling-Infrastruktur, die Google auch für andere Dienste nutzt, etwa für Ads oder Discover. Laut Google-Dokumentation greift der Googlebot im Durchschnitt höchstens alle paar Sekunden auf eine Website zu und arbeitet die Zeitpläne in Pacific Time ab. Der Ablauf danach ist immer gleich: abrufen, bei Bedarf rendern, bewerten, indexieren. Die Grundlagen des Crawlings erkläre ich im Glossar; hier geht es um die Details, die 2026 den Unterschied machen.
Wie viel liest der Googlebot von einer Seite?
Der Googlebot liest von jeder unterstützten Datei die ersten 2 MB, bei PDFs die ersten 64 MB; gemessen wird die unkomprimierte Größe. Ist das Limit erreicht, bricht er den Abruf ab und übergibt nur den bereits geladenen Teil an die Indexierung. Alles, was im HTML dahinter steht, existiert für die Google Suche nicht.
So steht es seit dem 3. Februar 2026 in der Dokumentation des Crawlers. Bis dahin nannte die Doku für Googles Crawler pauschal 15 MB, ein Wert, der für die übrigen Google-Crawler weiterhin als Standard gilt. Google beschreibt die Änderung im Changelog als Präzisierung, nicht als Absenkung; John Mueller ergänzte laut Search Engine Roundtable, dass sich an den Limits selbst nichts geändert habe und die meisten Websites keine Bytes zählen müssten.
Für die Praxis zählt weniger die Frage, ob das Limit neu ist, sondern ob Ihre Seiten darunter bleiben. Kritisch sind Seiten, deren HTML durch Inline-CSS, eingebettete SVGs, Tracking-Snippets oder Page-Builder-Markup anschwillt. Ich prüfe das mit einer einfachen Sortierung des Crawls nach unkomprimierter HTML-Größe. Was der Googlebot innerhalb der 2 MB findet, entscheidet über die Indexierung; Hauptinhalt, Überschriften und strukturierte Daten gehören deshalb in den Anfang des Dokuments, nicht ans Ende.
In fast jedem Audit finde ich Seiten, deren HTML durch Page-Builder-Markup auf ein Vielfaches des Inhalts angewachsen ist. Ob sie unter 2 MB bleiben, wusste vorher niemand im Team, weil es nie jemand gemessen hat.
Wie oft crawlt Google eine Website?
Wie oft der Googlebot eine Website crawlt, ergibt sich aus zwei Größen: dem Crawl-Kapazitätslimit, also dem, was Ihr Server verträgt, und dem Crawl-Bedarf, also dem, was Google an Aktualität und Relevanz erwartet. Beides zusammen bildet das Crawl-Budget. Kleine Websites mit wenigen tausend URLs stoßen an dieses Budget praktisch nie, große Websites mit Filtern, Parametern oder Archiven sehr wohl.
Jede Website startet mit demselben Kapazitätslimit
Seit der Überarbeitung vom 22. Juli 2026 sagt der Crawl-Budget-Leitfaden ausdrücklich, dass jede Website mit demselben konservativen Default-Kapazitätslimit beginnt. Besteht Bedarf an mehr Crawling und bleibt der Server stabil, hebt Google das Limit über die Zeit automatisch an. Eine neue Domain bekommt also keinen Vertrauensvorschuss, sie muss ihn sich durch Antwortzeiten und Fehlerquoten verdienen.
Häufiges Crawling ist ein gutes Zeichen
Google stellt in der im März 2026 neu angelegten Übersicht zum Crawling klar: Besucht der Googlebot eine Website häufig, deutet das auf frische oder besonders relevante Inhalte hin, die gefragt sind. Hohe Crawl-Raten sind deshalb kein Problem, das Sie eindämmen sollten, solange der Server sie trägt.
Mark Williams-Cook leitet aus den Unterlagen des US-Kartellverfahrens gegen Google drei Faktoren ab, die die Crawl-Frequenz bestimmen: Backlinks nach PageRank-ähnlichen Regeln, bei denen Qualität mehr zählt als Menge, die Änderungsfrequenz der Inhalte und reale Nutzerdaten. Das ist seine Lesart der Prozessdokumente, keine Google-Aussage, deckt sich aber mit dem, was ich in Logfiles großer Websites sehe.
Weniger Crawling kann ein Qualitätssignal sein
Die Gegenrichtung gilt ebenfalls. In Episode 112 des Google-Podcasts Search Off the Record erklärte John Mueller im Juli 2026, dass der Googlebot eine Website insgesamt weniger crawlt und Google weniger indexiert, wenn die Systeme ernsthafte Zweifel an ihrer Qualität haben. In der Search Console zeigt sich das als „Gecrawlt, zurzeit nicht indexiert“ oder „Gefunden, zurzeit nicht indexiert“. Mueller betonte laut Search Engine Roundtable, dass das manchmal, nicht immer der Grund ist, und dass Google dabei die komplette Seitenerfahrung bewertet: Anzeigen, Interstitials und Füllmaterial zählen mit, nicht nur der Haupttext. Ein wachsender Bestand nicht indexierter URLs ist deshalb ein Anlass, die Indexierung als Qualitätsfrage zu lesen, nicht als technischen Fehler.
Ein Detail aus derselben Logik betrifft das Meta-Tag unavailable_after: Nach dem angegebenen Datum senkt Google laut Dokumentation die Crawl-Rate der URL erheblich. Wer das Datum später ändert, muss laut Gary Illyes (via Search Engine Roundtable) damit rechnen, dass Google die Änderung erst beim nächsten Crawl sieht, und der kann lange ausbleiben.
Wie schonen Sie das Crawl-Budget?
Das Crawl-Budget schonen Sie am wirksamsten, indem Ihr Server unveränderte Seiten mit dem HTTP-Statuscode 304 Not Modified beantwortet und indem Sie Ressourcen wie CSS und JavaScript nicht per robots.txt sperren. Beides reduziert die Arbeit, die Google pro Seite leisten muss, ohne dass Inhalte verloren gehen.
HTTP-Caching mit 304 Not Modified
Der Crawl-Budget-Leitfaden empfiehlt seit seiner Überarbeitung 2026 ausdrücklich HTTP-Caching: Fragt der Googlebot mit If-Modified-Since oder If-None-Match nach, und die Seite hat sich nicht geändert, antwortet der Server mit 304 statt mit der vollen Seite. Google nutzt dann die gecachte Version, Ihr Server spart Bandbreite, und das Budget fließt in Seiten, die sich tatsächlich geändert haben. Bei WordPress-Websites hinter einem Caching-Plugin oder CDN ist das oft nur eine Konfigurationsfrage; ob es funktioniert, sehen Sie im Crawling-Statistik-Bericht der Search Console an der Verteilung der Statuscodes.
CSS und JavaScript nicht blockieren
Google braucht Zugriff auf Stylesheets und Skripte, um eine Seite so zu rendern, wie Nutzer sie sehen. Die Dokumentation zur robots.txt rät davon ab, Ressourcen zu sperren, wenn ihr Fehlen die Seite für den Crawler schwerer verständlich macht; unwichtige Ressourcen dürfen Sie weiterhin ausschließen. Mark Williams-Cook empfiehlt als Praxisregel, Theme- und CSS-Dateien grundsätzlich freizugeben, was ich teile: Der Nutzen einer gesperrten CSS-Datei ist null, das Risiko einer falsch gerenderten Seite real. Wie Sie die robots.txt sauber aufbauen, steht im Glossar.
Rendert Google JavaScript wirklich?
Ja, Google rendert jede Seite, die dem Googlebot mit Statuscode 200 antwortet, in einer Rendering-Warteschlange mit einem Headless-Chromium, unabhängig davon, ob sie JavaScript enthält. Eine feste Zeitgrenze von fünf Sekunden für die Ausführung gibt es nicht. Was Sie als Betreiber beeinflussen, ist, wie viel Arbeit dieses Rendering kostet und ob der Inhalt am Ende im gerenderten HTML steht.
Die JavaScript-SEO-Grundlagen beschreiben den Ablauf: Crawlen, in die Rendering-Warteschlange stellen, rendern, sobald Ressourcen frei sind, dann indexieren. Mark Williams-Cook fasst das unter Berufung auf Martin Splitt als „es gibt kein Rendering-Budget“ zusammen; Google selbst verwendet den Begriff nicht, die Doku spricht nur von Ressourcen, die frei werden müssen. Für Sie heißt das: Rendering ist kein Nadelöhr mehr, das Sie umgehen müssen, aber schweres JavaScript verzögert, wann Google den Inhalt sieht.
Hartnäckig hält sich die Behauptung, Google breche das Rendering nach fünf Sekunden ab. Dave Smart hat das bei Tame the Bots im Juli 2026 mit einer Testseite widerlegt, die fortlaufend Requests absetzt: Das Ende des Renderings richtet sich danach, wann die Seite keine offenen Aufgaben mehr hat, nicht nach einer Stoppuhr. Wie lange Google im Test durchgehalten hat, zeigt die Fakten-Karte unter diesem Absatz. Wichtig ist die Einschränkung, die Smart selbst macht: Der Live-Test der URL-Prüfung hält länger durch als das echte Rendering für die Indexierung.
Zwei Praxishinweise dazu. Erstens: Der Screenshot im Live-Test der Search Console ist laut Williams-Cook unwichtig; solange der Inhalt im gerenderten HTML steht, ist die Seite in Ordnung, auch wenn das Bild leer bleibt. Zweitens: Requests, die ein Service Worker selbst absetzt, etwa beim Vorab-Cachen, erscheinen nicht im Network-Tab der Seite, sondern nur in der DevTools-Instanz des Workers, die Sie über chrome://serviceworker-internals öffnen. Wer Rendering-Probleme nur im normalen Network-Tab sucht, übersieht diesen Teil.
Die einfachste Regel bleibt die, die Martin Splitt schon 2024 in seinem Vortrag „Maybe it isn’t JavaScript“ vertreten hat: Wenn eine Seite ohne JavaScript auskommt, verwenden Sie keins. Serverseitig gerendertes HTML ist für den Googlebot der günstigste Weg und für Ihre Nutzer der schnellste.
Die Frage, die ich am häufigsten höre: „Müssen wir wegen Google auf Server-Side-Rendering umbauen?“ Meine Antwort ist meistens Nein. Die Frage, die ich stattdessen stelle: „Steht der Inhalt im gerenderten HTML, und wie lange braucht die Seite, bis er da ist?“
So erkennen Sie den echten Googlebot
Ob ein Zugriff wirklich von Google stammt, prüfen Sie über einen Reverse-DNS-Lookup der IP-Adresse oder über den Abgleich mit den offiziellen IP-Bereichen. Der User-Agent allein beweist nichts, denn ihn kann jeder Scraper setzen. Google beschreibt beide Verfahren in der Anleitung zur Verifizierung.
Wer die IP-Listen automatisiert abgleicht, sollte 2026 seine Pfade prüfen: Google hat die JSON-Dateien mit den Crawler-IP-Bereichen laut Blogbeitrag vom 31. März 2026 von /search/apis/ipranges/ nach /crawling/ipranges/ verschoben. Die alten Adressen bleiben vorübergehend erreichbar und sollen innerhalb von sechs Monaten auf die neuen weiterleiten; ein Skript, das noch auf den alten Pfad zeigt, läuft also bald ins Leere. Dabei ist auch ein Dateiname gewandert: Die frühere googlebot.json heißt jetzt common-crawlers.json.
Wenn Sie den Googlebot selbst simulieren, etwa mit einem Crawler und dem Googlebot-User-Agent, rät Mark Williams-Cook dazu, den Crawl aus den USA zu starten. Googlebot crawlt in der Regel von US-Adressen aus, und nur so decken Sie automatische Geo-Redirects oder länderabhängige Inhalte auf, die Google anders sieht als Ihre Besucher in Deutschland.
Ein Fall aus derselben Podcast-Episode 112 zeigt, wie schnell Bot-Abwehr zum Indexierungsproblem wird: Liefert Ihre Website dem Googlebot eine „Sind Sie ein Roboter?“-Seite mit Statuscode 200 aus, kann Google laut John Mueller (dokumentiert bei Search Engine Journal) genau diese Seite indexieren, statt des eigentlichen Inhalts. Weil dieselbe Seite auf vielen Websites gleich aussieht, kann Google sie als Duplikat werten und eine fremde Website als Original wählen. Prüfen Sie deshalb, ob Ihr Bot-Schutz verifizierte Google-Zugriffe durchlässt.
Wer crawlt sonst noch? KI-Crawler und Bot-Traffic
Neben dem Googlebot fragen inzwischen Dutzende KI-Crawler, Such-Agenten und Scraper Ihre Website ab, und in Summe erzeugen Bots mehr Requests als Menschen. Das ist kein Randphänomen großer Portale mehr, sondern der Normalzustand im Netz.
Bots überholen die Menschen
Cloudflare misst den Anteil menschlicher und automatisierter HTML-Requests über sein gesamtes Netz. Wo dieser Anteil zuletzt lag, zeigt die Fakten-Karte unter diesem Absatz. Anfang Juni 2026 meldete Cloudflare-Chef Matthew Prince laut NBC News, dass Bots erstmals in der Geschichte des Internets mehr Requests erzeugen als Menschen. Zu den Bots zählen dabei Suchmaschinen-Crawler, KI-Crawler, Monitoring-Tools, agentische Browser und Scraper gleichermaßen.
Wie schnell der automatisierte Anteil wächst, beziffert der Benchmark-Report von HUMAN Security für das Jahr 2025: KI-getriebener Traffic wuchs von Januar bis Dezember um 187 Prozent, der Traffic autonomer Agenten sogar um 7.851 Prozent, und mehr als 95 Prozent davon konzentrierten sich auf drei Branchen: Handel, Streaming und Medien sowie Reise und Gastgewerbe. Dieselben Zahlen zitiert Microsoft in seinem Werbe-Blog; sie stammen aus einer Quelle und beschreiben eine andere Messgröße als der Cloudflare-Anteil, deshalb lassen sie sich nicht zu einer Verlaufslinie verbinden.
Wie extrem das im Einzelfall aussehen kann, beschreibt der Betreiber von Patronview, einer Website mit 1,5 Millionen Seiten: In einer Woche Serverlogs standen knapp 6.000 menschliche Seitenaufrufe 1,28 Millionen ausgelieferten Seiten gegenüber. Das ist eine Anekdote, keine Marktstatistik, aber sie zeigt, was Bots bei großen, offenen Datenbeständen anrichten.
OpenAI crawlt inzwischen 4 Prozent des Google-Volumens
Wie stark die KI-Crawler zulegen, zeigt eine Logfile-Analyse von Botify über rund sieben Milliarden Logzeilen: Seit dem Start von GPT-5 im August 2025 stieg die Aktivität des OAI-SearchBot um den Faktor 3,5 und die des GPTBot um den Faktor 2,9. Am stärksten gecrawlt wurden Healthcare mit rund plus 741 Prozent und Medien mit rund plus 702 Prozent. Im Frühjahr 2026 kam OpenAI damit auf rund 4 Prozent des Google-Crawl-Volumens, im gleichen Zeitraum 2025 waren es 1,38 Prozent. Die Verschiebung von Trainingsdaten hin zu Echtzeit-Abrufen für die Suche ist an den Bot-Namen ablesbar: Der Suchbot wächst schneller als der Trainingsbot.
Training oder Referral: Was von den Bots zurückkommt
Der Zweck der Zugriffe unterscheidet sich stark, und anders als der Googlebot schicken KI-Crawler kaum Besucher zurück. Laut Cloudflare entfielen im Juli 2025 fast 80 Prozent des KI-Crawlings auf das Sammeln von Trainingsdaten. Das Verhältnis von Abrufen zu weitergeleiteten Besuchern ist entsprechend schief: Anthropic crawlte im Juli 2025 laut Cloudflare 38.000 Seiten je einem vermittelten Besuch, mehr als jeder andere große KI-Anbieter. Der Googlebot bleibt dabei laut Cloudflares Jahresrückblick 2025 der Crawler mit dem höchsten Request-Volumen im Netz.
Steuern statt sperren
Pauschale Sperren sind für die meisten Websites die falsche Antwort. Amanda King brachte es in ihrem Vortrag auf der SMX München 2026 auf die Formel, den Bots den Weg freizuräumen: keine unnötigen robots.txt-Sperren, möglichst Statuscode 200, keine Captchas für Crawler, Barrierefreiheit ernst nehmen, sonst tauche man weder in der klassischen Suche noch in KI-Antworten auf. Dem schließe ich mich an. Welche Bots ChatGPT einsetzt und wie Sie sie in der robots.txt behandeln, beschreibe ich im Beitrag zu ChatGPT und seinen Crawlern.
Ein Sonderfall ist der CCBot von Common Crawl, dessen offener Datensatz vielen Modellen als Trainingsbasis und vielen RAG-Systemen als Backbone dient. Common Crawl hat dafür im Juni 2026 einen AI Visibility Audit veröffentlicht. Mark Williams-Cook rät seinen Kunden derzeit ausdrücklich davon ab, den CCBot zu blockieren; wer ihn aussperrt, verschwindet aus einem Datensatz, den er nicht ersetzen kann. Ob Ihre Website enthalten ist, zeigt ein Abgleich mit dem Common-Crawl-Index; er ersetzt nicht den Googlebot, ergänzt ihn aber als zweite Sichtbarkeitsquelle.
Taugen Logfiles für die KI-Sichtbarkeit?
Logfiles zeigen zuverlässig, welche KI-Bots und ob der Googlebot Ihre Website abrufen und wie oft, aber sie zeigen nicht, wie oft Ihre Inhalte in KI-Antworten erscheinen. Für die Sichtbarkeit in Sprachmodellen sind sie deshalb ein notwendiger, kein hinreichender Datenpunkt. Diese Einschätzung ist in der Branche umstritten, und beide Seiten haben ein Argument.
Amanda King hält Logfiles für ungeeignet, um die eigene Präsenz in Sprachmodellen zu messen: KI-Bots crawlen selten in Echtzeit und laden oft Ressourcen statt Inhalte, ein Abruf sagt also wenig über eine Nennung. Juliane Bettinga von SEOSOON widerspricht: Logfiles seien das einzig valide Bild der eigenen LLM-Sichtbarkeit, weil sich Grounding-Abrufe, etwa der ChatGPT-User-Bot, der beim Beantworten einer Frage HTML-Dokumente lädt, am User-Agent erkennen lassen und sehr wohl in Echtzeit stattfinden.
Aus meiner Sicht reden beide über verschiedene Bots. Für Trainings-Crawler hat King recht, ein Abruf ist dort nur ein Abruf. Für die Abrufe, die Modelle während einer Antwort auslösen, hat Bettinga recht, denn sie korrelieren direkt mit einer Nennung. Wer seine Logfiles nach User-Agent trennt, bekommt beides: den Trainings-Anteil als Rauschen und die Grounding-Abrufe als Signal. Was die Modelle dann tatsächlich zitieren, gehört in die Messung der Generative Engine Optimization.
Ein typischer Einwand aus Marketing-Teams lautet: „Wir haben doch Analytics, wozu Logfiles?“ Analytics sieht nur Besucher, die JavaScript ausführen. Die Hälfte des Traffics, um die es hier geht, tut genau das nicht.
Was kommt von den Bots zurück? KI-Referral-Traffic
Für Shopify-Shops wuchsen die aus KI-Diensten verwiesenen Sitzungen im zweiten Quartal 2026 laut Shopify um 197 Prozent gegenüber dem Vorjahr, die Bestellungen daraus verdreifachten sich. Die organische Suche legte im selben Zeitraum um 12 Prozent zu, auf einer viel größeren Basis, und brachte den Händlern weiterhin mehr Sitzungen als alle KI-Plattformen zusammen. Die Wachstumsrate ist beeindruckend, die Größenordnung nicht.
Für Software-Anbieter zeichnet eine Analyse von Previsible über 774.331 LLM-Sitzungen auf SaaS-Websites zwischen November 2024 und Dezember 2025, veröffentlicht bei Search Engine Land, ein differenzierteres Bild: Vom Juli-Hoch bis zum Jahresende fiel der KI-Traffic um 53 Prozent, während in Arbeitsplatz-Software eingebettete KI um das Zwanzigfache wuchs. Copilot startete Ende 2024 mit 148 Sitzungen und war ein Jahr später der zweitgrößte KI-Referrer. Eric vom Newsletter Dofollow Digest deutet den Rückgang als Saisonalität entlang der B2B-Kaufzyklen, weil alle Plattformen synchron fielen; das ist eine plausible Lesart, aber eine Deutung.
Zwei Zahlen aus derselben Analyse sind für die Website-Struktur relevanter als der Trend: 41,4 Prozent der KI-Besucher landeten auf internen Suchseiten, weil die Modelle auf die Suchfunktion ausweichen, wenn sie keine direkte Antwort finden; Blog-Beiträge mit strukturierten Vergleichen brachten mit 16,4 Prozent den zweitgrößten Anteil. Wer seine interne Suche per noindex vom Crawling ausschließt, sollte wissen, dass er damit auch den Einstiegspunkt vieler KI-Verweise verändert.
Ein verwandtes Muster beschreibt Similarweb im Report The 2026 Generative AI Landscape: Ein Großteil der Besuche aus ChatGPT landet auf der Startseite, obwohl die zitierten Seiten tief in der Website liegen, und dieser Anteil ist nach dem Such-Update von ChatGPT im Mai 2026 deutlich gestiegen. Zitierte Seiten und Einstiegsseiten sind damit zwei verschiedene Dinge, die Sie getrennt messen sollten; die Zahlen dazu trägt die Fakten-Karte unter diesem Absatz. Was dieses Update in der SERP verändert hat, behandle ich dort.
Was Sie jetzt tun sollten
Sechs Prüfschritte, die ich in jedem technischen Audit zum Crawling abarbeite, unabhängig von der Größe der Website:
- HTML-Größe prüfen: Sortieren Sie einen Crawl nach unkomprimierter Größe; Seiten nahe 2 MB verschlanken, Hauptinhalt nach oben.
- 304-Antworten aktivieren: Prüfen Sie im Crawling-Statistik-Bericht der Search Console, ob unveränderte Seiten als 304 beantwortet werden.
- robots.txt auditieren: keine Sperren für CSS und JavaScript; KI-Bots bewusst je Zweck erlauben oder ausschließen, den CCBot nicht pauschal sperren.
- Logfiles nach User-Agent trennen: Googlebot verifizieren, Trainings-Crawler von Grounding-Abrufen unterscheiden, Anteile monatlich festhalten.
- Bot-Schutz testen: Verifizierte Google-Zugriffe dürfen keine Captcha-Seite mit Statuscode 200 sehen.
- Indexierungsbericht lesen: Wächst „Gecrawlt, zurzeit nicht indexiert“, prüfen Sie Qualität und Seitenerfahrung, nicht nur Technik.
Fazit
Der Googlebot ist berechenbar: Er liest 2 MB, rendert alles mit Statuscode 200 und passt sein Budget an das an, was Ihr Server hergibt. Unberechenbar ist die Menge an anderen Bots, die inzwischen die Mehrheit der Zugriffe stellen und die Sie ohne Logfiles nicht sehen. Wer beides im Blick hat, entscheidet selbst, welche Maschinen seine Inhalte lesen dürfen, statt es dem Zufall zu überlassen. Wenn Sie wissen wollen, wie Ihre Website heute gecrawlt wird und wo Budget verloren geht, sprechen Sie mich an.
Häufige Fragen zum Googlebot
Wie oft kommt der Googlebot auf meine Website?
Das hängt vom Crawl-Budget ab: Jede Website startet mit demselben konservativen Kapazitätslimit, das Google bei stabilem Server und Bedarf an frischen Inhalten über die Zeit anhebt. Kleine Websites werden im Zweifel häufiger gecrawlt, als sie Änderungen haben; bei großen Websites entscheidet die Serverleistung. Den tatsächlichen Verlauf zeigt der Crawling-Statistik-Bericht der Search Console.
Wie prüfe ich, ob ein Zugriff wirklich vom Googlebot stammt?
Über einen Reverse-DNS-Lookup der IP-Adresse (die Antwort muss auf eine Google-Domain wie googlebot.com enden) oder über den Abgleich mit den offiziellen IP-Bereichen, die Google seit 2026 unter /crawling/ipranges/ bereitstellt. Der User-Agent allein ist kein Beweis, weil ihn jeder Scraper setzen kann.
Blockiert das 2-MB-Limit meine Seite?
Nur, wenn das unkomprimierte HTML einer Seite größer als 2 MB ist. Dann bricht der Googlebot den Abruf ab und indexiert nur den bereits geladenen Teil. Die meisten Seiten liegen weit darunter; kritisch sind Seiten mit viel Inline-CSS, eingebetteten SVGs oder aufgeblähtem Page-Builder-Markup. Ein Crawl, sortiert nach HTML-Größe, zeigt Ihnen die Kandidaten.
Rendert Google JavaScript?
Ja. Jede Seite mit Statuscode 200 wandert in die Rendering-Warteschlange und wird mit einem Headless-Chromium gerendert, sobald Ressourcen frei sind. Eine feste Zeitgrenze von fünf Sekunden gibt es nicht. Entscheidend ist, ob der Inhalt im gerenderten HTML steht; schweres JavaScript verzögert nur, wann Google ihn sieht.
Soll ich KI-Crawler blockieren?
Pauschal nein. Trennen Sie nach Zweck: Trainings-Crawler dürfen Sie je nach Geschäftsmodell ausschließen, Such- und Grounding-Bots wie den OAI-SearchBot sollten Sie zulassen, wenn Sie in KI-Antworten erscheinen wollen. Den CCBot von Common Crawl sperren Sie nur mit gutem Grund, weil sein Datensatz vielen Modellen und RAG-Systemen zugrunde liegt.