Googlebot

Kurzdefinition

Googlebot ist der Sammelname für zwei Web-Crawler der Google-Suche: Googlebot Smartphone und Googlebot Desktop. Sie rufen Seiten und Ressourcen ab, damit nachgelagerte Systeme Inhalte rendern, verarbeiten und gegebenenfalls indexieren können.

Ein Abruf ist nur ein früher Schritt. Er bedeutet nicht, dass die URL indexiert wird, ein Snippet erhält oder für eine Suchanfrage rankt. Google nennt drei technische Mindestbedingungen für die Indexierbarkeit: Googlebot darf nicht blockiert sein, die Seite liefert HTTP-Status 200, und sie enthält indexierbaren Inhalt. Selbst dann ist die Indexierung nicht garantiert.

Googlebot ist kein einzelner Roboter

Der Name wirkt, als würde ein Programm systematisch das gesamte Web durchlaufen. Google beschreibt die heutige Infrastruktur anders: Googlebot nutzt eine zentralisierte Crawling-Plattform, die auch anderen Google-Produkten unter eigenen Crawler-Namen dient.

Für die Google-Suche gibt es zwei Hauptvarianten:

• Googlebot Smartphone simuliert einen Nutzer auf einem mobilen Gerät.
• Googlebot Desktop simuliert einen Nutzer auf einem Desktop-Gerät.

Beide Varianten senden unterschiedliche HTTP-User-Agent-Strings. In robots.txt reagieren sie jedoch auf denselben Produkt-Token Googlebot. Eine Regel kann dort also nicht nur den Smartphone- oder nur den Desktop-Crawler ansprechen.

Warum der Smartphone-Crawler überwiegt

Google verwendet bei den meisten Websites die mobile Fassung für Indexierung und Ranking. Deshalb stammt die Mehrheit der Googlebot-Abrufe vom Smartphone-Crawler, eine kleinere Zahl vom Desktop-Crawler.

Für Responsive Websites wird meist dieselbe URL und dasselbe HTML ausgeliefert. Bei dynamischer Auslieferung oder getrennten mobilen URLs steigt das Fehlerrisiko. Die mobile Version sollte dieselben wesentlichen Inhalte, Überschriften, Metadaten, Robots-Anweisungen, Links und strukturierten Daten enthalten. Inhalte, die erst nach einer Nutzerinteraktion wie einem Klick oder Wischen geladen werden, sieht Google möglicherweise nicht.

Mobile-First bedeutet nicht, dass es einen separaten mobilen Index gibt. Es beschreibt, welche Seitenfassung Google überwiegend zur Verarbeitung und Bewertung verwendet.

Googlebot, Bilder, Videos und News

Eine robots.txt-Regel für Googlebot kann laut Google neben der Websuche auch Discover, Google Images, Google Video und Google News betreffen. Daneben existieren dokumentierte spezialisierte Crawler, etwa Googlebot-Image und Googlebot-Video, mit eigenen Tokens und technischen Eigenschaften.

Für Google News gibt es keinen eigenen Crawler-User-Agent mehr. Google ruft News-Inhalte mit den normalen Googlebot-User-Agents ab, berücksichtigt in robots.txt aber weiterhin den Token Googlebot-News für Regeln, die nur Google News betreffen. Das ist ein historischer Sonderfall, kein allgemeines Muster für beliebig getrennte Googlebot-Regeln.

Wer Bilder oder Videos in der Suche sichtbar machen möchte, muss außerdem die Ressourcen und ihre Einbettungsseiten zugänglich halten. Die bloße Abrufbarkeit einer Mediendatei garantiert jedoch keine Aufnahme in die Bild- oder Videosuche.

Wie Googlebot URLs entdeckt

Googlebot entdeckt neue URLs vor allem über Links in bereits gecrawlten Seiten. Sitemaps und bekannte URLs aus früheren Crawls liefern weitere Hinweise.

Interne Links erfüllen deshalb zwei Aufgaben. Sie helfen Menschen bei der Navigation und geben Crawlern echte Pfade zu neuen oder tiefer liegenden Seiten. Eine URL, die nur in einer Datenbank existiert und keinen crawlbaren Link erhält, kann durch eine Sitemap bekannt werden. Sie bleibt trotzdem schwach in die Website-Struktur eingebettet.

Eine Sitemap ist keine Indexierungsliste mit Annahmegarantie. Sie sollte kanonische, indexierbare URLs enthalten, die tatsächlich für die Suche vorgesehen sind.

robots.txt, noindex und Canonical trennen

Diese drei Mechanismen lösen verschiedene Aufgaben.

robots.txt steuert den Abruf

Eine Disallow-Regel weist konforme Crawler an, die URL nicht abzurufen. Die URL kann trotzdem als Adresse in Suchergebnissen erscheinen, wenn Google sie über andere Links kennt. Ohne Abruf kann Google einen noindex-Hinweis auf der Seite nicht lesen.

noindex steuert die Aufnahme in den Index

Soll eine öffentlich erreichbare Seite nicht indexiert werden, muss Google sie crawlen können und dort ein `noindex` im Robots-Meta-Tag oder HTTP-Header finden. Eine gleichzeitige Sperre in robots.txt kann diese Verarbeitung verhindern.

Canonical hilft bei Duplikaten

Ein Canonical ist ein Hinweis auf die bevorzugte Version ähnlicher oder doppelter Seiten. Es blockiert das Crawling einer URL nicht und ist keine Garantie, dass Google genau diese Auswahl übernimmt.

Stell bei einer Diagnose deshalb drei getrennte Fragen: Darf Googlebot die URL abrufen? Darf der Inhalt indexiert werden? Welche URL betrachtet Google als kanonisch?

Statuscodes und Serverantworten

Eine indexierbare HTML-Seite sollte mit HTTP 200 antworten. Permanente Weiterleitungen führen Googlebot zu einer anderen URL; 404 und 410 kennzeichnen nicht vorhandene Inhalte; 5xx weist auf Serverprobleme hin. Liefert eine Fehlerseite fälschlich 200, kann Google sie als Soft 404 behandeln. Welche Antwort in welchem Fall passt, erklärt der Eintrag zu HTTP-Statuscodes für SEO.

Noch davor zählt das Protokoll. Antworten http:// und https:// oder die Varianten mit und ohne www jeweils eigenständig, trifft Googlebot denselben Inhalt mehrfach an. Wie eine einzige, sichere Host-Variante das verhindert, zeigen die HTTP- und HTTPS-Grundlagen für SEO.

Auch eine langsame oder instabile Infrastruktur beeinflusst das Crawling. Googlebot soll Server nicht überlasten und kann seine Aktivität reduzieren, wenn die Antworten Probleme zeigen. Ein Crawl-Rückgang ist deshalb nicht automatisch ein Qualitätsurteil über den Inhalt.

Das aktuelle Abruflimit

Googles Googlebot-Dokumentation, zuletzt im Februar 2026 überarbeitet, nennt die Grenzen klar: Googlebot crawlt die ersten 2 MB eines unterstützten Dateityps und die ersten 64 MB einer PDF-Datei. Erreicht der Abruf die Grenze, wird der bereits geladene Teil weitergegeben und der Rest ignoriert.

Referenzierte CSS- und JavaScript-Ressourcen werden separat abgerufen und erhalten eigene Limits. Für die meisten HTML-Seiten sind 2 MB sehr viel. Problematisch können aber große Inline-Bilder, umfangreiche Inline-Skripte oder megabytegroße Menüs sein, wenn dadurch Title, Canonical, strukturierte Daten oder Hauptinhalt hinter die Grenze rutschen.

Behandle diese Zahlen als aktuellen Stand der Google-Dokumentation, nicht als feste Konstanten; Google kann sie anpassen. Sie sind eine technische Sicherheitsgrenze, kein Zielwert für normale Seitengröße.

Crawling, Rendering und Indexierung

Bei einer JavaScript-Anwendung lassen sich drei Phasen unterscheiden:

1. Googlebot nimmt eine URL aus der Crawl-Warteschlange, prüft robots.txt und ruft sie ab.
2. Google kann eine erfolgreiche Seite in die Rendering-Warteschlange stellen. Der Web Rendering Service führt JavaScript mit einem aktuellen Chromium aus und erzeugt gerendertes HTML.
3. Verarbeitungssysteme können Inhalt und Links aus dem gerenderten Ergebnis für Index und weitere Crawls verwenden.

Das Rendering kann verzögert sein. Google kann JavaScript ausführen, doch wichtige Informationen sollten nicht von fragilen, nutzergesteuerten oder dauerhaft fehlschlagenden Requests abhängen. Server Rendering oder statische Ausgabe ist kein Muss für Google, kann aber Seiten für Nutzer und verschiedene Crawler robuster und schneller machen.

Wenn du eine JavaScript-Seite prüfst, vergleiche Ausgangs-HTML und gerendertes HTML. Entscheidend ist, ob Hauptinhalt, crawlbare <a href>-Links, Metadaten und strukturierte Daten im gerenderten Ergebnis vorhanden sind.

Echten Googlebot im Log verifizieren

Der HTTP-User-Agent lässt sich leicht fälschen. Eine Anfrage mit dem Namen Googlebot stammt daher nicht automatisch von Google.

Google nennt zwei belastbare Prüfwege:

• Die Quell-IP wird mit den von Google veröffentlichten IP-Bereichen für Crawler abgeglichen.
• Bei einer DNS-Prüfung wird zuerst ein Reverse Lookup ausgeführt. Der zurückgegebene Hostname muss je nach Crawler-Typ zu googlebot.com, google.com oder googleusercontent.com gehören. Anschließend bestätigt ein Forward Lookup, dass dieser Hostname wieder zur ursprünglichen IP führt.

Erst nach dieser Prüfung sollte eine Anfrage in Zugriffsanalysen als echter Googlebot gewertet oder eine Blockierregel angepasst werden.

Was Serverlogs und Search Console jeweils zeigen

Serverlogs belegen konkrete Requests an die eigene Infrastruktur. Sie zeigen Zeitpunkt, URL, User-Agent, Statuscode, übertragene Daten und oft Antwortzeit. Nach der Bot-Verifikation lässt sich damit untersuchen, welche URL-Muster Googlebot tatsächlich abruft und welche Fehler er erhält.

Search Console liefert eine andere Sicht. Crawl Stats zeigen aggregierte Crawl-Aktivität, Page Indexing gruppiert bekannte URLs nach Indexierungsstatus, und die URL-Prüfung hilft bei einer einzelnen Seite. Keiner dieser Berichte ersetzt Rohlogs vollständig; Rohlogs wiederum erklären nicht, ob eine gecrawlte Seite indexiert oder für relevante Queries angezeigt wurde.

Diagnose in sinnvoller Reihenfolge

1. Ist die betroffene URL öffentlich erreichbar und intern crawlbar verlinkt?
2. Erlaubt robots.txt den Abruf der Seite und notwendiger Ressourcen?
3. Liefert die URL den beabsichtigten Statuscode und eine stabile Antwort?
4. Befinden sich wichtige Angaben innerhalb der Abrufgrenze?
5. Sind Hauptinhalt und Links im gerenderten HTML sichtbar?
6. Stimmen mobile Inhalte, Metadaten und strukturierte Daten mit der beabsichtigten Fassung überein?
7. Erlaubt die Seite Indexierung, und ist der Canonical plausibel?
8. Was melden Page Indexing, URL-Prüfung und Crawl Stats?
9. Bestätigen verifizierte Logdaten den Abruf durch Googlebot?
10. Erst danach: Deckt der Inhalt die Suchintention ab und besitzt er ausreichenden eigenständigen Wert?

Beispiel: eine Kategorieseite, die nur im Browser funktioniert

Nimm eine hypothetische Shop-Kategorieseite, die als clientseitige App gebaut ist. Der Server antwortet mit 200 und einer fast leeren HTML-Hülle. Die Produktkacheln kommen erst später über einen API-Aufruf, und die Paginierung besteht aus Buttons mit Klick-Handlern statt aus Links.

Im Browser sieht alles gut aus. Für Googlebot können drei Dinge schiefgehen. Der Abruf gelingt, aber der Hauptinhalt existiert erst nach dem Rendering. Scheitert der API-Aufruf oder ist er für Crawler gesperrt, bleibt die gerenderte Seite dünn. Und weil Kacheln und Paginierung keine <a href>-Links sind, findet Googlebot die Produkt-URLs höchstens über die XML-Sitemap.

Die Lösung ist keine Spezialeinstellung für Googlebot. Rendere die Produktliste serverseitig oder stelle sicher, dass sie zuverlässig im gerenderten HTML steht, mach Kacheln und Paginierung zu crawlbaren Links und prüfe das Ergebnis mit der URL-Prüfung in der Search Console. Danach zeigen verifizierte Serverlogs, ob Googlebot die Produkt-URLs tatsächlich abruft.

Häufige Fehler

• jeden Googlebot-Abruf als Indexierungsnachweis lesen
• Smartphone und Desktop in robots.txt getrennt steuern wollen
• robots.txt als zuverlässige Deindexierung verwenden
• noindex auf einer gleichzeitig blockierten URL erwarten
• Canonical als Crawling-Sperre behandeln
• einen bloßen User-Agent-String als echten Googlebot akzeptieren
• JavaScript-Fähigkeit mit garantiertem Rendering gleichsetzen
• jede niedrige Crawl-Frequenz als Crawl-Budget-Problem bezeichnen
• aus Site-Audit-Daten auf echte Googlebot-Requests schließen

Crawl-Foundry-Perspektive

Der Site Audit von Crawl Foundry crawlt eine Website mit eigenem Crawler und führt einen Crawl-Verlauf. Er prüft das gerenderte HTML und erfasst Statuscodes, Weiterleitungen, Canonical- und Robots-Angaben sowie die Indexierbarkeit. Interne Links siehst du so, wie der Crawler sie im DOM gefunden hat, mit Quelle, Ziel, Ankertext und Position. Weil sich Läufe vergleichen lassen, erkennst du, ob eine Korrektur das Ergebnis tatsächlich verändert hat.

Das ist reproduzierbare Evidenz zum technischen Zustand der Website, aber kein Googlebot-Log und keine Bestätigung, dass Google eine URL auf dieselbe Weise abgerufen hat. Für Google-spezifische Belege bleiben Search Console und verifizierte Serverlogs maßgeblich. Site Audit hilft, eine Ursache auf URL-Gruppen zurückzuführen und die Reparatur zu prüfen. Googles Indexierungsentscheidung oder Crawl-Priorität sagt er nicht voraus.

Verwandte Begriffe

• Crawling
• Indexierung
• Crawl-Budget
• robots.txt
• XML-Sitemap
• Google Search Console
• Fortgeschrittene technische SEO
• JavaScript-Rendering für SEO
• Mobile-First-Indexierung
• Server-Side Rendering
• Strukturierte Daten
• Seitengeschwindigkeit

Quellen für den Review

• Google Search Central: Was ist Googlebot?
• Google Search Central: Technische Anforderungen
• Google Search Central: Grundlagen zu JavaScript-SEO
• Google Search Central: Best Practices für die Mobile-First-Indexierung
• Google Crawling Infrastructure: Anfragen von Google-Crawlern verifizieren
• Google Crawling Infrastructure: Liste der allgemeinen Google-Crawler
• Google Search Central: Inside Googlebot, demystifying crawling, fetching, and the bytes we process
• IETF: RFC 9309, Robots Exclusion Protocol