Was ein Google-Crawler-Simulator tatsächlich tut
Ein Crawler-Simulator sendet eine HTTP-Anfrage an deine URL mit einem User-Agent-String, der dem ausgewählten Bot entspricht, lädt die Antwort herunter und erfasst den Statuscode, die Header und das rohe HTML. Dann lädt er die Seite in einem Headless-Browser—Chrome mit aktiviertem JavaScript—wartet darauf, dass sich das DOM stabilisiert, erfasst das letzte gerenderte HTML und vergleicht es mit dem initialen HTML, um zu zeigen, was JavaScript geändert hat.
Er extrahiert den sichtbaren Text—das, was ein Bot nach dem Entfernen von HTML-Tags, CSS und Skripten sieht—weil das der Inhalt ist, den Google indexiert. Er kennzeichnet Ressourcen, die nicht geladen werden konnten: Bilder, Schriftarten, CSS-Dateien oder JavaScript-Bundles, die von CORS, 404ern oder Serverfehlern blockiert wurden. Er prüft auf Robots-Meta-Tags, X-Robots-Tag-Header und Canonical-Tags, die Indexierung verhindern können, selbst wenn die Seite erfolgreich geladen wurde.
Drei Problemkategorien treten bei jedem Crawl-Test auf. Die erste ist Inhalt, der aus dem rohen HTML fehlt und nur nach dem Ausführen von JavaScript erscheint. Falls deine Hero-Überschrift oder Produktbeschreibung client-seitig gerendert wird, sieht Googlebot sie möglicherweise während des initialen Abrufs nicht. Die zweite ist Render-Timeout. Falls JavaScript länger als fünf Sekunden dauert, kann Googlebot die unvollständige Seite indexieren. Die dritte sind blockierte Ressourcen. Falls deine CSS- oder kritischen JavaScript-Dateien 403 oder 404 zurückgeben, rendert die Seite beschädigt, und Googlebot sieht ein beschädigtes Layout.
So nutzt du diesen Google-Crawler-Simulator
- Füge die Seiten-URL in Page URL ein. Nutze die kanonische Version—https, www falls zutreffend, keine UTM-Parameter, es sei denn, du testest, wie Parameter das Rendering beeinflussen.
- Wähle einen User-agent aus dem Dropdown. Googlebot Desktop ist der Standard. Googlebot Mobile simuliert mobil-zuerst-Indexierung mit einem mobilen Viewport. Googlebot-Image testet Image-spezifisches Crawling. Bingbot testet Bings Crawler. GPTBot simuliert OpenAIs Training-Crawler.
- Klicke auf Simulate crawler. Du erhältst vier Abschnitte: rohe HTML, gerenderte HTML, sichtbarer Text und ein Ressourcen-Log, das zeigt, welche Dateien geladen oder fehlgeschlagen sind.
- Vergleiche die Raw HTML- und Rendered HTML-Reiter. Falls die gerenderte Version Inhalt hat, der im rohen HTML fehlt, ist dieser Inhalt JavaScript-injiziert. Falls die Render-Zeit fünf Sekunden überschreitet, zeigen wir eine Warnung an.
- Überprüfe die Blocked resources-Liste. Jede Ressource, die einen Status ungleich 200 zurückgegeben hat, wird gekennzeichnet. Falls kritisches CSS oder JavaScript blockiert ist, rendert die Seite wahrscheinlich beschädigt für Googlebot.
- Scrolle zu Visible text. Das ist das, was Google indexiert. Falls dein Ziel-Keyword hier erscheint, kann Google die Seite dafür ranken. Falls nicht, ist das Keyword unsichtbar.
Versuche, eine Single-Page-App zu simulieren, die mit React oder Vue gebaut wurde. Das rohe HTML enthält oft ein leeres <div id="root"></div> und ein Script-Tag. Das gerenderte HTML zeigt die vollständige Seite nach der JavaScript-Ausführung. Falls das Rendering acht Sekunden dauert, weil langsame API-Aufrufe vorhanden sind, warnen wir, dass Googlebot möglicherweise eine Zeitüberschreitung erleben könnte und die leere Shell indexiert.
Warum rohe HTML vs. gerenderte HTML wichtig ist
Googles Indexierungs-Pipeline hat zwei Phasen. Die erste ist der initiale Abruf, bei dem Googlebot das rohe HTML herunterlädt. Die zweite ist das Rendering, bei dem Googlebot JavaScript in einer Headless-Chrome-Instanz ausführt und das letzte DOM erfasst. Das Rendering findet Stunden oder Tage nach dem initialen Abruf statt, und nicht jede Seite wird gerendert. Seiten mit schnellen Ladezeiten, starken internen Links und keinen JavaScript-Fehlern werden priorisiert.
Drei praktische Konsequenzen.
Inhalt im rohen HTML indexiert schneller. Falls deine H1, Meta-Beschreibung und erster Absatz im initialen HTML sind, kann Googlebot sie sofort indexieren. Falls sie nur nach der JavaScript-Ausführung erscheinen, wartet die Indexierung auf die Render-Warteschlange. Auf einer Site mit 10.000 Seiten kann diese Verzögerung Tage oder Wochen dauern.
JavaScript-Fehler blockieren Indexierung. Falls deine Seite während des Renderings einen Konsolenfehler auslöst, sieht Googlebot möglicherweise eine leere Seite. Unser Simulator führt die Seite aus und erfasst Konsolenprotokolle. Ein Fehler wie „Uncaught TypeError: Cannot read property 'map' of undefined" kann verhindern, dass die gesamte Seite rendert.
Das Render-Budget ist endlich. Google ordnet pro Site ein Crawl-Budget und ein Render-Budget zu. Falls das Rendering deiner Homepage 10 Sekunden dauert, könnte Google sie weniger oft rendern als Konkurrenten, deren Seiten in zwei Sekunden rendern. Wir berichten die Render-Zeit, damit du weißt, ob du über Budget bist.
Blockierte Ressourcen und Indexierungs-Auswirkungen
Eine blockierte Ressource ist jede Datei—CSS, JavaScript, Bild, Schriftart—die die Seite laden wollte, aber einen 4xx- oder 5xx-Statuscode erhielt, oder die von robots.txt oder CORS-Richtlinie blockiert wurde. Googlebot ignoriert die Datei und setzt das Rendering fort, aber die fehlende Datei kann Layout oder Funktionalität beschädigen.
Kritische CSS-Dateien steuern das Layout. Falls styles.css von robots.txt blockiert ist, rendert Googlebot die Seite ohne Stile, was bedeutet, dass Inhalt durch Standard-CSS-Status ausgeblendet sein könnte—Akkordeons zusammengeklappt, Reiter versteckt, Modals off-screen. Der Inhalt existiert im DOM, ist aber nicht sichtbar, daher könnte Google ihn nicht indexieren.
Kritische JavaScript-Dateien steuern Interaktivität und Datenabruf. Falls app.js blockiert ist, bricht das Client-seitiges Routing zusammen, und Links innerhalb der App funktionieren nicht. Falls api-client.js blockiert ist, kann deine Produktseite keine Produktdaten abrufen, daher sieht Googlebot einen Loading-Spinner statt Produktdetails.
Bilder und Schriftarten sind weniger kritisch. Ein fehlendes Bild beschädigt die Indexierung nicht, könnte aber Benutzererlebnis-Signale verletzen, falls sich das Seiten-Layout verschiebt oder Platzhalter erscheinen. Eine fehlende Schriftart fällt auf Systemschriftarten zurück, was für die Indexierung normalerweise in Ordnung ist.
Unser Simulator listet jede Ressource, ihre URL, den Statuscode und den Typ auf. Falls eine Ressource fehlgeschlagen ist, zeigen wir den Fehler. Falls sie von robots.txt blockiert wurde, kennzeichnen wir sie. Nutze diese Liste, um Blockaden auf Serverebene oder in deiner robots.txt-Datei zu beheben.
Mobile-First-Indexierung und Viewport
Im Jahr 2026 nutzt Google Mobile-First-Indexierung für alle Sites. Das bedeutet, dass Googlebot Mobile der primäre Crawler ist, und die mobile Version deiner Seite bestimmt Rankings auch für Desktop-Suchen. Falls deine mobile Seite Inhalte hinter einem „Read more"-Toggle versteckt oder Sidebar-Widgets entfernt, sieht Googlebot diesen Inhalt nicht, und er zählt nicht zu Rankings.
Das Testen mit Googlebot Mobile als User-Agent zeigt, was der Mobile-Crawler sieht. Wir rendern die Seite mit einem 375px-Viewport—iPhone SE-Breite—damit du das Mobile-Layout siehst. Falls dein CSS Elemente bei mobilen Breiten verbirgt, fehlen sie dem gerenderten HTML. Falls dein JavaScript Bilder oder Text lazy-loaded, während der Nutzer scrollt, und Googlebot nicht scrollt, ist dieser Inhalt unsichtbar.
Zwei Fixes sind verbreitet. Der erste ist Server-seitiges Rendering oder Static Site Generation, wobei der volle Inhalt im rohen HTML ist, unabhängig vom Viewport. Der zweite ist sicherzustellen, dass mobiles CSS nicht display: none bei wichtigem Inhalt setzt. Nutze opacity: 0 oder position: absolute; left: -9999px für Accessibility, aber selbst diese können der Indexierung schaden, falls übernutzt.
Robots-Meta-Tags und X-Robots-Tag-Header
Selbst wenn eine Seite erfolgreich lädt, sagen ein <meta name="robots" content="noindex">-Tag oder ein X-Robots-Tag: noindex-HTTP-Header Googlebot, sie nicht zu indexieren. Unser Simulator prüft beide und meldet sie in der Zusammenfassung.
Häufige Werte sind noindex (nicht zu Suchergebnissen hinzufügen), nofollow (Links auf dieser Seite nicht folgen), noarchive (nicht cachen), nosnippet (keinen Snippet in Ergebnissen zeigen) und none (äquivalent zu noindex, nofollow). Falls deine Staging-Site versehentlich mit noch vorhanden noindex-Tags live geht, verlierst du all deinen Such-Traffic. Überprüfung vor dem Launch fängt das auf.
Der HTTP-Header hat Vorrang vor dem HTML-Tag, falls beide vorhanden und unterschiedlich sind. Eine Seite mit <meta name="robots" content="index"> aber X-Robots-Tag: noindex wird nicht indexiert. Unser Simulator zeigt beide, damit du Konflikte erkennen kannst.
Häufige Fehler
- Die gesamte Seite Client-seitig rendern. Falls das rohe HTML leer ist und alles nach JavaScript erscheint, ist die Indexierung langsam und fragil. Verschiebe kritischen Inhalt ins initiale HTML via Server-seitiges Rendering oder Prerendering.
- JavaScript oder CSS in robots.txt blockieren. Google benötigt diese Dateien, um die Seite zu rendern.
Disallow: *.jsoderDisallow: *.cssbeschädigt das Rendering. Blockiere diese nur, falls du einen starken Grund hast, und überprüfe mit dem Simulator danach erneut. - Konsolenfehler ignorieren. Eine einzelne unabgefangene Exception kann das Rendering anhalten. Überprüfe das Konsolenprotokoll in der Simulator-Ausgabe und behebe Fehler vor dem Deployment.
- Nur mit einem Browser testen, nicht mit Googlebot. Browser sind nachsichtiger als Googlebot. Eine Seite, die in Chrome funktioniert, könnte in Headless Chrome fehlschlagen wegen fehlender Polyfills oder User-Agent-Checks. Simuliere Googlebot, um das echte Erlebnis zu sehen.
- Annehmen, dass Googlebot scrollt. Das tut er nicht. Lazy-loaded-Inhalt, der von Scroll-Events ausgelöst wird, ist unsichtbar, wenn du nicht Intersection Observer implementierst oder alles beim initialen Render lädst.
- Nicht nach Framework-Updates testen. Ein Next.js- oder Gatsby-Versions-Bump kann ändern, wie Static Generation funktioniert. Überprüfe das Rendering nach Updates, um zu bestätigen, dass Inhalt noch im rohen HTML ist.
Fortgeschrittene Tipps
- Teste die gleiche URL mit Googlebot Desktop und Googlebot Mobile. Falls sich der Inhalt unterscheidet, könnte Mobile-First-Indexierung die Seite anders ranken, als du erwartest.
- Vergleiche die Render-Zeit seiten-übergreifend. Falls deine Homepage in 2 Sekunden rendert, aber Produktseiten 8 Sekunden dauern, identifiziere den langsamen API-Aufruf oder schweres Skript und optimiere es.
- Überprüfe den Visible text-Abschnitt auf Keyword-Präsenz. Falls dein Ziel-Keyword in der HTML-Quelle ist, aber nicht im sichtbaren Text, könnte es von CSS oder JavaScript verborgen sein, was bedeutet, dass es nicht zu Rankings zählt.
- Nutze den Simulator nach dem Deployment eines neuen Features. Ein Checkout-Ablauf, Live-Chat-Widget oder Analytics-Skript kann das Rendering beschädigen, falls es Fehler auslöst. Das Erkennen nach dem Deployment verhindert Indexierungs-Rückgänge.
- Falls blockierte Ressourcen gefunden werden, überprüfe mit dem robots.txt checker die Gegenprüfung, ob robots.txt die Ursache ist. Falls nicht, überprüfe Server-Logs auf 403- oder CORS-Fehler.
- Kombiniere dieses Tool mit dem website metadata checker, um zu bestätigen, dass Title, Meta und Schema im gerenderten HTML vorhanden sind, nicht nur in der rohen Quelle.
Nach der Simulation, falls du feststellst, dass JavaScript für kritischen Inhalt erforderlich ist, erwäge den Wechsel zu Server-seitigem Rendering oder Static Generation. Falls blockierte Ressourcen das Problem sind, aktualisiere deine robots.txt mit dem robots.txt file generator. Falls du sehen möchtest, wie alle On-Page-SEO-Faktoren—Rendering, Metadata, Canonicals, interne Links—zusammenpassen, nutze die SEO checklist für eine 20-Punkte-Prüfung.