Sprachen

Googlebot und SEO

Was Googlebot tatsächlich ist – Smartphone und Desktop, Rendering mit stets aktuellem Chromium, User-Agent-Zeichenfolgen, Prüfung der IP-Bereiche, Byte-Limits und der Unterschied zwischen Crawling und Ranking.

Erstveröffentlicht: 24. Juni 2026 · Zuletzt aktualisiert: 13. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Googlebot ist Googles Webcrawler – die Software, die Seiten abruft, damit Google sie indexieren und bewerten kann. Es gibt zwei Varianten mit demselben Token in robots.txt: Googlebot Smartphone (primär bei der Mobile-First-Indexierung) und Googlebot Desktop. Googlebot verwendet ein stets aktuelles Chromium und rendert JavaScript später in einer separaten Warteschlange (Crawling ≠ Rendering). Crawling ist kein Ranking-Faktor, und eine Sperre in robots.txt ist keine Deindexierung: Eine blockierte URL kann weiterhin ohne Seiteninhalt indexiert werden. Da sich der User-Agent leicht fälschen lässt, prüfen Sie Reverse- und Forward-DNS oder Googles veröffentlichte IP-Bereiche. Der sichtbare „Googlebot“ ist lediglich der Anteil der Google-Suche an einer viel größeren Crawling-Plattform.

TL;DR – Googlebot ist der Crawler der Google-Suche, aufgeteilt in Smartphone (primär, Mobile-First) und Desktop, die sich ein Googlebot-robots.txt-Token teilen – Sie können sie nicht separat ansprechen. Er verwendet ein stets aktuelles Chromium und rendert JavaScript in einer separaten, späteren Warteschlange (Crawl ≠ Rendering). Crawling ist erforderlich, um am Ranking teilzunehmen, ist aber kein Ranking-Signal. Eine durch robots.txt blockierte URL kann weiterhin ohne Seiteninhalt indexiert werden. Verifizieren Sie den Crawler per Reverse- und Forward-DNS über eine Google-Domain oder gegen die veröffentlichten IP-Bereiche von Google – der User-Agent ist trivial fälschbar. Und „Googlebot“ ist eigentlich nur der suchorientierte Teil einer viel größeren Crawling-Plattform.

Evidence for this claim Googlebot is Google's crawler, with smartphone and desktop crawler types that share the same product token. Scope: Current Googlebot crawler and user-agent documentation. Confidence: high · Verified: Google Search Central: Googlebot Evidence for this claim A claimed Google crawler can be verified using reverse and forward DNS or Google's published IP ranges. Scope: Google's current crawler-verification methods. Confidence: high · Verified: Google Search Central: Verify Googlebot

Was Googlebot tatsächlich ist

Google ist bei der Bezeichnung präzise: “Googlebot is the generic name for two types of web crawlers used by Google Search.” (Übersetzung) „Googlebot ist der Sammelname für zwei Arten von Web-Crawlern, die von der Google-Suche verwendet werden.“ Diese zwei Arten sind Googlebot Smartphone („ein mobiler Crawler, der einen Nutzer auf einem mobilen Gerät simuliert“) und Googlebot Desktop („ein Desktop-Crawler, der einen Nutzer auf dem Desktop simuliert“).

Es ist kein kleines Programm, das auf einer einzelnen Maschine läuft. “Googlebot runs on thousands of machines,” (Übersetzung) „Googlebot läuft auf Tausenden von Maschinen“, wie ich es in meinem Googlebot-Leitfaden beschreibe. Diese Systeme “determine how fast and what to crawl on websites,” (Übersetzung) „bestimmen, wie schnell und welche Inhalte auf Websites gecrawlt werden“, und sind über Rechenzentren weltweit verteilt, wobei der ausgehende Datenverkehr hauptsächlich von US-IP-Adressen stammt. Neue URLs findet Google vor allem “primarily from links embedded in previously crawled pages” (Übersetzung) „über Links, die in zuvor gecrawlten Seiten eingebettet sind“, sowie über Sitemaps. (Das vollständige Bild von Entdeckung und Planung behandelt der Crawling-Hub.)

Smartphone vs. Desktop – und warum es “Smartphone-first” ist

Unter Mobile-First-Indexierung ist der Smartphone-Crawler der primäre. Google formuliert es so: “For most sites Google Search primarily indexes the mobile version of the content. As such the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.” (Übersetzung) „Für die meisten Websites nutzt die Google-Suche vor allem die mobile Inhaltsfassung zur Indexierung. Entsprechend führt der mobile Crawler den Großteil der Googlebot-Abrufe aus; auf den Desktop-Crawler entfällt nur ein kleinerer Anteil.“ Die Mobile-First-Indexierung ist seit Oktober 2023 für alle Websites abgeschlossen. Daher gilt praktisch: Wenn Inhalte für den Smartphone-Agenten nicht sichtbar sind, werden sie nicht indexiert. Halten Sie Inhalte, strukturierte Daten, Metadaten und Robots-Tags auf Mobil- und Desktopversionen konsistent.

Der Haken bei robots.txt: “Both crawler types obey the same product token (user agent token) in robots.txt, and so you cannot selectively target either Googlebot Smartphone or Googlebot Desktop using robots.txt.” (Übersetzung) „Beide Crawler-Typen folgen demselben Produkt-Token (User-Agent-Token) in robots.txt; deshalb können Sie Googlebot Smartphone und Googlebot Desktop dort nicht getrennt ansprechen.“ Unterscheiden lassen sie sich nur über den HTTP-Anforderungsheader user-agent in Ihrer eigenen serverseitigen Logik. (Die Mechanik dieses Header-Formats behandeln Mobile-First-Indexierung und User-Agent.)

Die User-Agent-Strings

Das robots.txt-Produkt-Token für beide ist einfach Googlebot. Die vollständigen UA-Strings unterscheiden sich:

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Googlebot Smartphone:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

W.X.Y.Z ist ein Platzhalter für die aktuelle Chrome-Version, die sich mit dem immergrünen Chromium von Googlebot weiterentwickelt. Verlassen Sie sich jedoch nicht allein auf den String – er ist trivial fälschbar (siehe Verifizierung unten).

Evergreen Chromium und die Rendering-Warteschlange

Diese Unterscheidung verwirrt viele Menschen: Crawling und Rendering sind getrennte Schritte. Googlebot verwendet “an evergreen version of Chromium,” (Übersetzung) „eine stets aktuelle Version von Chromium“, und wurde im Mai 2019 entsprechend umgestellt (Sprung vom alten Chrome 41 auf die jeweils aktuelle stabile Version). Deshalb unterstützt er heute ES6+, IntersectionObserver, Web Components und modernes CSS. Das JavaScript wird jedoch nicht schon beim Abruf des HTML ausgeführt.

Google schreibt: “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that. Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.” (Übersetzung) „Googlebot stellt alle Seiten mit HTTP-Statuscode 200 zum Rendern in eine Warteschlange, sofern kein Robots-Meta-Tag oder -Header Google anweist, die Seite nicht zu indexieren. Die Seite kann dort einige Sekunden bleiben, aber auch länger. Sobald Google genügend Ressourcen hat, rendert ein Headless-Chromium die Seite und führt das JavaScript aus.“ Der Web Rendering Service (WRS) verhält sich wie ein moderner Browser, hat aber wichtige Eigenheiten: Er ist praktisch zustandslos – lokaler Speicher, Sitzungsspeicher und Cookies werden zwischen Seitenaufrufen gelöscht –, ruft zur Bandbreiteneinsparung keine Bilder oder Videos ab, speichert aggressiv im Cache (und kann Ihre Cache-Header ignorieren) und unterstützt weder WebSockets noch WebRTC. Erscheinen Inhalte erst nach einem Klick oder einer JavaScript-gesteuerten Navigation ohne echten <a href>-Link, sind Rendering-Probleme zu erwarten. (Das Schwesterthema Rendering behandelt die Details.)

Bytelimits

Googlebot lädt nicht unbegrenzt viel pro URL. Seit dem Inside Googlebot-Update vom März 2026 ruft es ungefähr die ersten 2 MB einer einzelnen URL (einschließlich des HTTP-Headers) und bis zu 64 MB für eine PDF ab. Die Zahl ist ein bewegliches Ziel – Google selbst formuliert es so: “this limit is not set in stone and may change over time as the web evolves and HTML pages grow in size,” (Übersetzung) „Diese Grenze 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“, und frühere Dokumentationen nannten 15 MB (was sich als der breitere Infrastruktur-Standard herausstellte, nicht die Zahl von Search). Der praktische Punkt bleibt unabhängig davon bestehen: Alles, was über der Grenze liegt, wird einfach nicht abgerufen – “to Googlebot, they simply don’t exist.” (Übersetzung) „Für Googlebot existieren sie einfach nicht.“ Halten Sie kritische Inhalte und Markup oberhalb des Ballasts.

Fehlgeschlagenes Beispiel: Das Canonical existiert, aber Googlebot erhält es nie

Stellen Sie sich eine Produktvorlage vor, die 2,4 MB HTML zurückgibt. Eine Anwendung serialisiert am Dokumentanfang ein großes Produktzustandsobjekt und umfangreiche Empfehlungsdaten; Canonical, Produktbeschreibung, strukturierte Daten und Links zu verwandten Produkten erscheinen erst ungefähr bei Byte 2 180 000. Ein Browser lädt die gesamte Antwort, sodass der Seitenquelltext korrekt aussieht. Googlebot Search stoppt ungefähr an seiner dokumentierten 2-MB-Grenze; die späteren Signale fehlen daher in der abgerufenen Ressource.

Diagnostizieren Sie die Antwort in Byte-Reihenfolge, nicht nur im gerenderten DOM:

curl -sS -D response-headers.txt -o page.html https://example.com/product
wc -c response-headers.txt page.html
LC_ALL=C grep -abo 'rel="canonical"' page.html
LC_ALL=C grep -abo 'application/ld+json' page.html

Die lokalen Byte-Zahlen sind eine Näherung, da Zustellungs-Intermediäre und Antwortverarbeitung unterschiedlich sein können, aber sie beantworten die nützliche erste Frage: Sind kritische Signale bequem früh vorhanden, oder sitzen sie nahe oder jenseits der Grenze? Die Lösung besteht darin, übermäßig große Inline-Daten zu entfernen oder aufzuschieben und wesentliche Metadaten, primäre Inhalte und crawlbare Links früh auszugeben – nicht darin, denselben Ballast zu verschieben und zu hoffen, dass sich die Grenze ändert.

Wie Googlebot abruft – höflich

  • Die Crawl-Rate ist algorithmisch und selbstregulierend. “For most sites, Googlebot shouldn’t access your site more than once every few seconds on average.” (Übersetzung) „Für die meisten Websites sollte Googlebot Ihre Website im Durchschnitt nicht öfter als einmal alle paar Sekunden aufrufen.“ Es beschleunigt oder verlangsamt sich basierend auf der Gesundheit Ihres Servers.
  • Statuscodes sind der Hebel. Die Rückgabe von 429, 500 oder 503 teilt Googlebot mit, langsamer zu machen – aber das betrifft den gesamten Hostnamen, nicht nur die fehlerhaften URLs, und funktioniert nur ein oder zwei Tage, bevor anhaltende Fehler beginnen, Seiten aus dem Index zu entfernen. John Mueller: “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts,” (Übersetzung) „Ich würde nur erwarten, dass die Crawl-Rate so schnell reagiert, wenn sie 429 / 500 / 503 / Timeouts zurückgeben“, und “404s are generally fine & once discovered, Googlebot will retry them anyway.” (Übersetzung) „404er sind im Allgemeinen in Ordnung und sobald sie entdeckt werden, wird Googlebot sie sowieso erneut versuchen.“
  • crawl-delay wird ignoriert. Google verarbeitet die nicht standardkonforme crawl-delay-robots.txt-Direktive überhaupt nicht. (Bing beachtet sie – eine der echten Googlebot/Bingbot-Abweichungen.)
  • Crawling folgt der Crawl-Nachfrage, nicht einem festen Kontingent – Kapazität (was Ihr Server verkraften kann) plus Nachfrage (Beliebtheit und Veralterung). Für die meisten Websites ist das kein Problem; es wird nur bei echter Größe relevant. Die vollständige Behandlung finden Sie unter Crawl-Budget.

Überprüfen, ob es wirklich Googlebot ist

Der User-Agent-Header wird “often spoofed by other crawlers” (Übersetzung) „oft von anderen Crawlern gefälscht“ – daher beweist er allein nichts. Die Crawler von Google identifizieren sich auf drei Arten: über den User-Agent-Header, die Quell-IP und den Reverse-DNS-Hostnamen dieser IP. Zwei echte Überprüfungsmethoden:

  1. Manuell (einmalig). Reverse-DNS der Quell-IP; bestätigen Sie, dass sie in einen Hostnamen aufgelöst wird, der auf googlebot.com, google.com oder googleusercontent.com endet (die Maske sieht aus wie crawl-***-***-***-***.googlebot.com); dann Forward-DNS dieses Hostnamens und bestätigen Sie, dass er die ursprüngliche IP zurückgibt.
  2. Automatisch (in großem Maßstab). Gleichen Sie die IP mit den veröffentlichten CIDR-Bereichen von Google ab. Google hat diese von der alten einzelnen googlebot.json in mehrere JSON-Dateien nach Crawler-Kategorie aufgeteilt – die Googlebot-Datei ist https://www.gstatic.com/ipranges/common-crawlers.json (die alte googlebot.json-URL leitet weiterhin auf dieselben Daten um).

Beide befinden sich im Tab Skripte, für macOS/Linux und Windows. Warum der Aufwand? Viele Zugriffe geben vor, Googlebot zu sein, daher können Protokolle, die „Googlebot“ zeigen, weitgehend aus Hochstaplern bestehen – überprüfen Sie, bevor Sie vertrauen.

Googlebot ist ein Bot in einer Flotte

„Googlebot“ ist tatsächlich ein wenig irreführend. Gary Illyes sagte im März 2026: “I mean, calling it Googlebot, that’s a misnomer,” (Übersetzung) „Ich meine, die Bezeichnung Googlebot ist eigentlich unzutreffend“, und “Googlebot is not our crawler infrastructure.” (Übersetzung) „Googlebot ist nicht unsere Crawler-Infrastruktur.“ Die darunterliegende Infrastruktur ist, in seinen Worten, “software as a service, if you like. SaaS” (Übersetzung) „Software as a Service, wenn man so will – SaaS“ – eine gemeinsame Plattform, aus der viele Google-Produkte schöpfen. Was Sie in Ihren Protokollen sehen, ist der Suchanteil davon: “When you see Googlebot in your server logs, you are just looking at Google Search.” (Übersetzung) „Wenn Sie Googlebot in Ihren Serverprotokollen sehen, betrachten Sie lediglich die Google-Suche.“ Er merkt auch an, dass es “dozens, if not hundreds of different crawlers,” (Übersetzung) „Dutzende, wenn nicht Hunderte verschiedener Crawler“ gibt, von denen die meisten zu klein für eine eigene Dokumentation sind.

Zu den benannten Crawlern neben Googlebot gehören Googlebot-Image, Googlebot-Video und Googlebot-News (sie teilen dessen Zeichenfolgen und Tokens), Storebot-Google sowie Google-InspectionTool für URL-Prüfung und Rich-Results-Tests. Zwei verhalten sich ungewöhnlich: AdsBot ignoriert die globale *-Regel in robots.txt (selbst Disallow: / unter User-agent: * stoppt ihn nicht), und Google-Safety ignoriert robots.txt vollständig. Hinzu kommen die KI-bezogenen Crawler Google-Extended (steuert das Gemini-Training; kein Ranking-Signal) und GoogleOther (von Googlebot ausgelagerte F&E-Crawls). Das Schwesterthema AI-Crawler behandelt sie ausführlich, weshalb ich hier nicht alles wiederhole.

So steuern Sie Googlebot

Drei Steuerungen, drei verschiedene Wirkungen:

  • robots.txt stoppt das Crawlen, nicht das Indexieren. Verwenden Sie es, um Bots von URL-Bereichen mit geringem Wert fernzuhalten – niemals als Deindexierungs-Tool.
  • noindex stoppt das Indexieren – aber Googlebot muss die Seite crawlen dürfen, um das Tag überhaupt zu sehen.
  • Passwortschutz blockiert den Zugriff vollständig.

Das bringt uns zu der am meisten missverstandenen Googlebot-Tatsache: “There’s a difference between crawling and indexing; blocking Googlebot from crawling a page doesn’t prevent the URL of the page from appearing in search results.” (Übersetzung) „Crawling und Indexierung sind nicht dasselbe; wenn Googlebot eine Seite nicht crawlen darf, kann ihre URL trotzdem in den Suchergebnissen erscheinen.“ Eine durch robots.txt blockierte URL kann dennoch ausschließlich als URL indexiert werden, wenn etwas darauf verlinkt. Um eine Seite tatsächlich zu entfernen, erlauben Sie das Crawlen und fügen Sie noindex hinzu. Ich habe dies ausführlich in Indexed, though blocked by robots.txt beschrieben.

Für die breitere Pipeline, in der Googlebot lebt – URL-Entdeckung, der Crawl-Scheduler, Rendering und die Unterscheidungen zwischen Crawl, Index und Rank – siehe den Hub Crawling und How Search Works.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.