Was ist Googlebot? Crawling, Rendering und Indexierung erklärt

TL;DR. Googlebot ist nicht ein einzelner Bot, sondern eine ganze Familie von Crawlern. Seit der Standardumstellung auf Mobile-First-Indexing im Jahr 2023 erledigt Googlebot Smartphone den Großteil der Arbeit. Der Ablauf besteht aus drei Phasen (Crawl, Render, Index), die Stunden oder Tage auseinander­liegen können. In der Render-Phase entstehen die meisten „Googlebot sieht meine Seite nicht“-Probleme. In den Support-Tickets, die wir bei SEOJuice von Mitte 2024 bis Anfang 2026 bearbeitet haben, waren ca. 6 von 10 Eskalationen auf Render-Fehler zurückzuführen; nur etwa 2 von 10 betrafen wirklich die Crawl-Phase (der Rest waren noindex-Tags oder Robots-Fehl­konfigurationen). Dieser Leitfaden erklärt die Bot-Familie, die Drei-Phasen-Pipeline, die Verifikation echter Googlebot-Hits, die üblichen Fragen zu Robots und Crawl Budget sowie den Vergleich von Googlebot mit Bingbot, GPTBot, PerplexityBot und ClaudeBot im Jahr 2026.

Aktualisiert Mai 2026. Ergänzt um proprietäre Ticket-Statistiken von SEOJuice, eine namentlich genannte Anekdote zu einem Cloudflare-Bot-Fight-Ausfall sowie einen Querverweis im AI-Crawler-Abschnitt auf die zuvor beschriebenen JS-Render-Fehler.

Ich habe diesen Artikel geschrieben, weil ich in Intercom drei- bis vier­mal pro Woche dieselbe Erklärung verschicke. Der Kunde meint: „Googlebot ist auf meiner Seite blockiert.“ Wir öffnen die Search Console: Die Crawl-Phase ist einwandfrei, die Render-Phase ist vor einer Woche abgestürzt, nachdem ein Entwickler ein Tab-Panel-Refactoring live gestellt hat und dabei übersah, dass sich der Artikel­text erst nach einem Klick lädt. Statt jedes Mal dieselben Absätze neu zu tippen, wollte ich eine URL, die ich einfach ins Ticket kopiere. Das hier ist diese URL.

Was Googlebot eigentlich ist (in Klartext)

Googlebot ist das Programm, mit dem Google Webseiten abruft, um sie in den Index aufzunehmen. Wenn Sie einen neuen Blogpost veröffentlichen und er irgendwann in den Such­ergebnissen auftaucht, beginnt die Reise damit, dass Googlebot die URL anfordert, das HTML herunterlädt, das JavaScript ausführt und das Ergebnis an das Indexierungs­system weitergibt. Ohne Googlebot existiert keine Ihrer Seiten aus Googles Sicht.

Zwei Klarstellungen vorab. Erstens wird „Googlebot“ oft locker als Sammel­begriff für „jeden Google-Crawler“ benutzt. Streng genommen ist Googlebot der Crawler für den Hauptindex der Websuche. Es gibt weitere Google-Crawler (z. B. AdsBot für Landing-Page-Checks, Storebot für Shopping-Listings, Google-Extended für AI-Opt-outs), die eigene Regeln und Zeitpläne haben. Seien Sie beim Debugging präzise, welchen Bot Sie meinen.

Zweitens: Googlebot ist kein Scraper. Er liest Ihre robots.txt vor jedem Crawl, respektiert noindex-Meta-Tags, drosselt sich, wenn Ihr Server langsam wird, und weist sich per Header eindeutig aus, sodass Sie Anfragen verifizieren können. Taucht in den Logs ein „Googlebot“ auf, der Ihre Origin ohne Rücksicht belastet, ist das fast sicher kein echter Googlebot. Prüfen Sie das, bevor Sie Rate Limits setzen.

Googlebot ist eigentlich eine Bot-Familie

Der Bot, über den Sie am meisten nachdenken müssen, ist Googlebot Smartphone. Er crawlt seit Abschluss des Mobile-First-Indexings Mitte 2023 standardmäßig die mobile Version Ihrer Seite. Desktop-Crawls finden weiterhin statt, sind aber nachrangig. Hier die Familien­übersicht mit den von Google veröffentlichten User-Agent-Strings:

Das Platzhalter-Muster W.X.Y.Z in den Smartphone- und Desktop-Strings ist nicht wörtlich; Google setzt dort die aktuelle Chromium-Version ein, die sich an der stabilen Chrome-Version orientiert. Stand heute liegt das Rendering-Engine-Update nur wenige Wochen hinter dem öffentlichen Chrome-Release. (Früher riet ich Kunden, Googlebot wie Chrome 41 zu behandeln – so war es bis zum Evergreen-Update 2019. Noch 2021 erzählte ich diesen veralteten Tipp, bis mich ein Martin-Splitt-Talk bei „Search Off the Record“ zum Lesen der aktuellen Doku zwang.) Verwendet Ihre Site also ein JS-Feature, das Chrome 130+ voraussetzt, unterstützt Googlebot es vermutlich; unbe­released Features dagegen nicht.

Die Drei-Phasen-Pipeline: Crawl, Render, Index

Googlebots Arbeit unterteilt sich in drei separate Phasen. Sie laufen nicht gleichzeitig, und eine Verzögerung oder ein Fehler in einer davon kann Ihre Seite aus den Such­ergebnissen fernhalten. Google beschreibt das schlicht: „Google verarbeitet JavaScript-Web-Apps in drei Haupt­phasen: 1. Crawling 2. Rendering 3. Indexierung.“ Wenn Sie nicht benennen können, in welcher Phase ein Problem auftritt, raten Sie bei der Lösung. Genau dafür existiert dieser Artikel.

Phase 1: Crawling

Googlebot wählt eine URL aus seiner Queue, sendet eine HTTP-Anfrage und erhält das rohe HTML. Mehr passiert hier nicht. Kein JavaScript, kein Rendern. Der Crawler liest den Statuscode, die Header (Caching, X-Robots-Tag, Weiterleitungen) und den unge­filterten Body. URLs stammen aus XML-Sitemaps, internen Links indexierter Seiten, externen Links und manuellen Submits via URL-Prüfung.

Befindet sich der komplette Index-relevante Inhalt schon im HTML (klassisches SSR), reicht das. Ist das HTML hingegen leer und der Content kommt per JavaScript, landet die Seite in Phase 2. Hier prüft Googlebot auch robots.txt; wird eine URL dort disallowed, erfolgt gar kein Fetch.

Phase 2: Rendering

Benötigt eine Seite JavaScript, übergibt Googlebot die URL an den Web Rendering Service (WRS). Ein Headless Chromium lädt die Seite, führt das JS aus und liefert das gerenderte HTML. Google schreibt: „Sobald Google Ressourcen frei­hat, rendert ein Headless Chromium die Seite und führt das JavaScript aus.“

Das „sobald Google Ressourcen frei­hat“ trägt viel Gewicht. Rendering ist teuer, daher wird es gebatcht und in eine Queue gestellt. Seiten warten Sekunden, Stunden oder im Extremfall Tage. (Ich habe einen Screenshot von 2024 mit 96 Stunden Gap zwischen Crawl und Render bei einem Next.js-Shop. Er hängt immer noch in unserem Slack, um die wieder­kehrende Debatte zu gewinnen, ob „Googlebot hat die Seite gecrawlt“ irgendetwas bedeutet.) Google bleibt bewusst vage: „Die Seite kann einige Sekunden in der Queue bleiben, aber es kann länger dauern.“ Wie die Priorisierung funktioniert, bleibt unklar; ähnliche Sites bekommen Renderings teils nach fünf Minuten, teils nach 36 Stunden.

Diese Render-Verzögerung ist das Dauerproblem bei JS-Sites. Ein Blogpost wird binnen Minuten gecrawlt, aber erst 24 Stunden später gerendert – und taucht somit erst am nächsten Tag in den SERPs auf. Reine SSR-Seiten überspringen diese Queue vollständig.

Phase 3: Index

Sobald das finale HTML vorliegt (direkt oder gerendert), analysiert das Indexierungs­system das Dokument, extrahiert Text, bewertet Ranking-Signale und speichert alles im Index. Ab dann kann die Seite ranken. Auch dieser Schritt dauert Minuten oder Stunden, aber Googlebots Job ist damit erledigt; der Rest liegt bei den Ranking-Algorithmen.

Was JavaScript-Rendering bricht (und wie man es erkennt)

Hier passieren die Fehler. Die Crawl-Phase klappt fast immer; gerendert wird jedoch nicht, wie der Entwickler dachte. Die sechs häufigsten Fehler­muster, absteigend nach Häufigkeit – Punkte 1 und 2 machen laut Ticket-Sample aus dem TL;DR mehr als die Hälfte aller Render-Eskalationen aus.

1. Inhalte, die Nutzer­interaktion erfordern

Muss man erst auf „Mehr anzeigen“ klicken, sieht Googlebot den Abschnitt nicht. Der WRS klickt nicht und scrollt nicht. Alles Wichtige muss beim initialen Load im DOM sein, auch wenn es per CSS versteckt ist. Klassische Problemzonen: Tab-Panels, Akkordeon-Bodies, „Load more“-Feeds.

2. Lazy-Loading ohne saubere Signale

Lazy-geladene Elemente brauchen native loading="lazy" oder einen Intersection Observer, den der WRS auflöst. Libraries, die auf Scroll-Events warten, scheitern, weil nicht gescrollt wird. Bilder also mit loading="lazy"; Komponenten serverseitig rendern oder ein Framework mit sauberem SSR/Hydration nutzen.

3. JavaScript-Fehler zur Laufzeit

Wirft ein oberes Script eine Exception, laufen folgende Skripte nicht – der Rest der Seite bleibt leer. Die URL-Prüfung zeigt unter „Gerenderte Seite anzeigen“ das HTML und Screenshot exakt wie Googlebot es sah.

4. WAF- und Bot-Schutz-Regeln

CAPTCHAs, zu aggressive Cloudflare-Bot-Fight-Einstellungen und Geo-Blocking liefern 403 oder Challenge-Seiten an Google-IPs. (Cloudflares Bot-Fight-Mode hat bei uns mehr Ausfälle verursacht als jede andere Einstellung – ein B2B-SaaS verlor 2024 in einem Wochenende zwei Drittel seiner indexierten Seiten, nachdem ein Security-Praktikant ihn aktivierte; die Erholung dauerte drei Wochen.) Google-IP-Ranges whitelisten (googlebot.json) und nach Regeländerungen mit der URL-Prüfung testen.

5. In robots.txt blockierte Ressourcen

Sperren Sie /static/ oder /assets/, kann der WRS JS- und CSS-Bundles nicht laden – Ergebnis: ungestylte oder leere Seiten. Statische Assets für Googlebot immer erlauben.

6. Inhalte hinter Auth oder Cookies

Googlebot authentifiziert nicht, akzeptiert Cookies nur eingeschränkt und hält keine Session. Alles hinter Login wird nicht indexiert. Für Paywalls: Indexing API oder strukturierte Daten nutzen und klar zwischen offenem und geschütztem Content trennen.

Die SEO-Debatte 2017–2020 drehte sich darum, ob Googlebot jemals modernen Chrome einholt. Seit dem Evergreen-Switch 2019 ist das erledigt, doch viele Ratschläge stammen noch aus Vor-Evergreen-Zeiten – darum tauchen Fehler 1 und 2 weiter so oft auf.

So prüfen Sie, ob eine Anfrage wirklich von Googlebot stammt

Den User-Agent kann jeder fälschen. Echte Googlebot-Anfragen kommen aus Google-IP-Ranges. Verifizieren geht per Reverse-DNS und anschließendem Forward-DNS:

1. IP aus dem Access-Log nehmen.
2. Reverse DNS: Hostname muss auf .googlebot.com oder .google.com enden.
3. Forward DNS auf diesen Hostname: sollte auf dieselbe IP zeigen.
4. Passen beide Checks, ist es echter Googlebot; sonst Spoof.

Kommandozeile: host 66.249.66.1 gefolgt von host crawl-66-249-66-1.googlebot.com. Auf großen Sites automatisieren; erstaunlich oft ist ein vermeintlicher „Googlebot-Spike“ nur ein Scraper mit gefälschtem UA. Ahrefs hat dazu eine gute Anleitung mit curl-Beispielen.

robots.txt und Crawl Budget – die taktischen Fragen

Wie viel crawlt Googlebot meine Site?

Google nennt das Crawl Budget. Bei Sites unter ca. 10 000 URLs ist es selten ein Limit. Erst bei Millionen-Sites, facettierten Shops oder massiv duplizierten URLs wird es kritisch. Einflussfaktoren: Crawl-Rate (Server­leistung) und Crawl-Demand (Popularität + Änderungs­häufigkeit). Details liefert der Semrush-Beitrag Googlebot Explained.

Sollte ich Low-Value-URLs blockieren?

Ja, wenn sie Crawl Budget auf großen Sites fressen. Übliche Muster: Facetten-Filter, interne Suchergebnisse, Paginierungen ab Seite 5, Session-Parameter-Varianten, Admin-Endpoints. Für Crawl-Block robots.txt, für Index-Block noindex-Tag. Unterschied: Robots verhindert den Crawl, Noindex erlaubt ihn, blockiert aber die Indexierung.

Wie beschleunige ich die Indexierung neuer Seiten?

Über die URL-Prüfung in Search Console einreichen. Das löst einen Extra-Crawl mit Google-InspectionTool aus und geht schneller als die reguläre Queue. Außerdem von einer bereits indexierten, starken Seite verlinken.

Warum crawlt Googlebot meine Dev-Umgebung?

Weil eine URL Ihrer Staging-Domain öffentlich verlinkt wurde. Ganze Staging-Domain in robots.txt mit Disallow: / sperren und ggf. per Basic Auth schützen.

„Googlebot sieht die Seite nicht“ – Debug-Workflow

Systematisches Debugging in vier Schritten, bis einer trifft.

Check 1: URL-Prüfung. URL einfügen. Tool zeigt Crawl-/Index-Status, „Gerenderte Seite anzeigen“ liefert HTML + Screenshot. Fehlt dort Inhalt → Render-Problem. Nicht-200-Status → Crawl-Problem. Dieser Schritt löst etwa zwei Drittel aller Tickets.

Check 2: curl mit Googlebot-UA. curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://site.com/pfad. Liefert der Server anderes HTML an Googlebot, sehen Sie es hier. Cloaking ist eine häufige Ursache.

Check 3: robots.txt und Meta-Tags. https://site.com/robots.txt prüfen, dann Quell­text auf noindex durchsuchen. Oft liegt nur ein vergessenes Tag aus dem Staging-Deploy vor.

Check 4: Server-Logs. Letzte 30 Tage nach verifizierten Googlebot-Hits filtern. Taucht die URL nie auf → Discoverability-Problem: In Sitemap aufnehmen und intern verlinken. Taucht sie mit 4xx/5xx auf → Fehler beheben und neu crawlen lassen. SEOJuice analysiert verifizierte Googlebot-Logs automatisch und warnt, wenn Kern-URLs verschwinden.

Googlebot vs. Bingbot vs. AI-Crawler

Früher dachte man nur an Googlebot; das hat sich geändert. So stehen die großen Crawler 2026 da:

Beachten Sie: Die Render-Fehler 1, 2 und 5 – Interaktions-Gating, Lazy-Load, blockierte Assets – treffen AI-Crawler noch stärker, weil deren Renderer schwächer sind. Gleiches Check­listen-Vorgehen hilft also auch bei Perplexity-Zitationsproblemen; die Stakes sind nur (noch) geringer.

Zwei Konsequenzen: Erstens sind AI-Crawler schwächere JS-Renderer. Wenn Ihr Content client-seitig gerendert wird, ranken Sie vielleicht bei Google, sind aber für ChatGPT, Perplexity und Claude „unsichtbar“. Lösung: SSR oder Pre-Rendering. Unser kostenloser AI-Visibility-Checker zeigt in unter einer Minute, ob die großen AI-Engines Ihre Inhalte sehen. Zweitens haben AI-Crawler eigene robots.txt-Direktiven. User-agent: GPTBot blockiert OpenAI-Training; User-agent: Google-Extended blockiert Gemini-Training. User-agent: Googlebot steuert weiter die Websuche. Sie können also Googlebot zulassen und GPTBot sperren – getrennte Regeln.

„Das meistübersehene Detail bei Googlebot ist, dass Crawling und Rendering nicht derselbe Schritt sind. Eine URL kann gecrawlt sein, aber Stunden kein gerendertes Ergebnis haben.“ — Martin Splitt, Google Search Relations, sinngemäß in Search Off the Record

Häufig gestellte Fragen

Was ist Googlebot?

Googlebot ist der Webcrawler von Google, der Seiten entdeckt und herunterlädt, damit sie indexiert und in der Suche angezeigt werden können. Es handelt sich um eine Bot-Familie (Smartphone, Desktop, Image, Video, News) mit unterschiedlichen User-Agents; gemeint ist meist Googlebot Smartphone, der seit 2023 der Haupt-Crawler ist.

Führt Googlebot JavaScript aus?

Ja. Der Web Rendering Service (WRS) ist ein Headless Chromium, der JS ausführt. Die Chromium-Version folgt dem stabilen Chrome, moderne JS-Features funktionieren also. Der Haken ist die Render-Queue: Zwischen Crawl und Render können Sekunden bis Tage liegen. SSR-Seiten umgehen die Queue.

Wie prüfe ich, ob eine Anfrage echt ist?

Reverse DNS auf die IP → Hostname muss auf .googlebot.com oder .google.com enden. Forward DNS zurück auf dieselbe IP. Besteht einer der Tests nicht, ist der UA gefälscht. Der User-Agent-Header allein beweist nichts.

Kann ich Googlebot blockieren?

Ja. In robots.txt: User-agent: Googlebot gefolgt von Disallow: /. Das verhindert den Crawl und damit die Indexierung. Granularer geht es mit noindex-Meta-Tags (Crawl ja, Index nein) oder Pfad-Sperren in robots.txt. CSS-/JS-Bundles dürfen Sie nicht blocken, sonst scheitert das Rendering.

Ist Googlebot dasselbe wie GPTBot oder PerplexityBot?

Nein. Verschiedene Betreiber, verschiedene Zwecke. Googlebot indexiert fürs Google-Ranking, GPTBot sammelt Trainings­daten für ChatGPT, PerplexityBot für Perplexity. Jeder Bot hat eigenen UA und beachtet eigene robots.txt-Regeln. Sie können Googlebot erlauben und GPTBot sperren – oder umgekehrt.

Warum hat Googlebot meine neue Seite noch nicht indexiert?

Meistens: Seite ist von keiner indexierten URL verlinkt, liefert keinen 200-Status, hat ein noindex, wird durch robots.txt blockiert oder hängt in der Render-Queue wegen Client-Side-JS. URL-Prüfung zeigt sofort, welcher Fall vorliegt. Neue Seiten brauchen typischerweise Stunden bis Tage, bei geringer Crawl-Frequenz länger.

Was das praktisch für Ihre Site bedeutet

Auf den Punkt gebracht: Wenn Ihre Sicht­barkeits-Checks sich nur auf Google-Rankings stützen, optimieren Sie für den stärksten Renderer und ignorieren schwächere AI-Crawler, deren Anteil am Referral-Traffic jedoch quartals­weise steigt. Server-Side-Rendering ist kein Google-Optimierungs-Nice-to-have mehr, sondern Grund­voraussetzung für AI-Sichtbarkeit. Diese Neu­einordnung ist die wichtigste Erkenntnis.

Wenn Sie schnell prüfen wollen, welche Crawler Ihre Site tatsächlich sehen, testet unser kostenloser AI-Visibility-Checker Ihre URL mit denselben Limits wie Googlebot, GPTBot, PerplexityBot und ClaudeBot und zeigt, wo eine leere Seite ankommt. In den meisten Audits finden wir mindestens ein kritisches Template (meist Produkt- oder Blog-Template), das bei Google funktioniert, bei Perplexity jedoch leer ist.

Offen bleibt für mich: die Logik der Render-Queue-Priorisierung. Die Doku spricht nur von Ressourcen, doch die Varianz ähnlicher Sites deutet auf weitere Faktoren. Wenn Sie dazu saubere Before/After-Daten haben, schicken Sie sie gern rüber.

Weiterführende Artikel:

• SEO für Single-Page-Applications
• Answer Engine Optimization (AEO)
• Kostenloses SEO-Audit-Tool
• Kostenloser AI-Visibility-Checker