Kostenloser Website-Crawl-Test: Ihre Seite ohne JavaScript

Die meisten Crawl-Checker beantworten eine Frage: Darf diese URL indexiert werden? Das ist eine Frage der Freigabe, und beantwortet wird sie von zwei kleinen Textstücken – einer Regel in Ihrer robots.txt und einem meta robots-Tag in Ihrem HTML. Die Prüfung lohnt sich, sie dauert Millisekunden, und sie ist fast nie der Grund, warum eine Seite bei Google fehlt.

Die zweite Frage ist schwieriger und weitaus häufiger die Ursache: Was erhält Googlebot tatsächlich, wenn es Ihre URL anfordert?

Das sind unterschiedliche Fehler mit unterschiedlichen Lösungen. Eine Seite kann einwandfrei freigegeben sein und trotzdem als nahezu leeres Dokument indexiert werden – weil der Inhalt, den Besucher sehen, in deren Browser von JavaScript zusammengesetzt wurde, das die erste Anfrage von Googlebot nie ausgeführt hat. Dieser Test führt beide Prüfungen nebeneinander aus:

• Freigabe – Ihre robots.txt wird nach Googles Longest-Match-Regel ausgewertet und der meta robots-Wert der Seite gelesen. Daraus entstehen getrennte Crawlbar-/Indexierbar-Verdikte für Google und Bing.
• Realität – die URL wird zweimal abgerufen: einmal als rohes HTML mit dem Smartphone-User-Agent von Googlebot und einmal über Headless Chrome mit aktiviertem JavaScript. Dieselben Signale werden in beiden Fassungen gezählt, und der Unterschied wird ausgewiesen.

Alles Folgende dreht sich um die zweite Hälfte – denn dafür fehlt den meisten Menschen schlicht ein Werkzeug.

Google crawlt und rendert nicht in einem Schritt. Es laufen zwei Durchgänge, getrennt durch eine unbekannte Zeitspanne.

Durchgang eins – HTML crawlen und indexieren. Googlebot fordert Ihre URL an und erhält, was Ihr Server sendet. Diese Antwort wird geparst; Text, Überschriften, Links, Meta-Tags und strukturierte Daten werden aus dieser Antwort extrahiert und indexiert. Zugleich wird jeder gefundene Link zum Crawlen eingereiht. Dieser Durchgang ist schnell – und er findet immer statt.

Durchgang zwei – Rendern. Die Seite geht an einen separaten Dienst, der sie in einem Headless-Browser lädt, JavaScript ausführt und ein gerendertes DOM erzeugt. Google indexiert die Seite anschließend aus diesem DOM erneut. Dieser Durchgang ist aufgeschoben: Er steht in einer Warteschlange, hat eigene Timeouts und ein eigenes Ressourcenbudget und wird priorisiert wie jede endliche Ressource.

Bei den meisten Seiten der meisten Websites kommt der zweite Durchgang. Aus der Architektur folgen jedoch drei Dinge – und genau sie machen das rohe HTML so wichtig:

1. Es gibt eine Lücke. Zwischen beiden Durchgängen – Minuten oder deutlich mehr – ist die einzige Fassung Ihrer Seite in Googles Index die aus dem rohen HTML.
2. Die Warteschlange ist nicht garantiert. Seiten, die beim Rendern in ein Timeout laufen, Fehler werfen oder niedrig priorisiert sind, können allein anhand des ersten Durchgangs indexiert werden. Eine Benachrichtigung darüber gibt es nicht.
3. Links, die nur im gerenderten DOM stehen, werden später entdeckt. Existieren die Links einer Kategorieseite zu ihren Produkten erst nach der Hydration, werden diese Produkt-URLs in Durchgang eins nicht eingereiht. Auf einer großen Website summiert sich diese Verzögerung.

Deshalb ist „Google rendert JavaScript" zwar richtig, aber kein Grund zur Entspannung. Das Rendern ist eine zweite Chance – nicht die erste.

Die Vergleichstabelle hat eine Zeile je Signal und eine Spalte je Durchgang. Die linke Spalte zeigt, was Durchgang eins erhält; die rechte, was nach JavaScript existiert. Was die einzelnen Zeilen bedeuten:

Title, Meta-Description, Canonical. Diese drei gehören ausnahmslos ins Server-HTML. Ein per JavaScript gesetzter Title kann im ersten Durchgang übersehen werden, und ein Canonical, das erst nach dem Render existiert, ist eine bekannte Ursache dafür, dass die falsche URL indexiert wird. Steht eines davon rechts und fehlt links, beheben Sie das zuerst – meist ist es eine Änderung von einer Zeile.

H1 und Überschriften. Eine fehlende H1 im rohen HTML bei gleichzeitig vorhandener H1 nach JavaScript ist die klassische Signatur einer Single-Page-App. Ihr Dokument trifft ohne erklärtes Thema ein.

Wörter Text. Die Prozentzahl oben auf dieser Seite stammt aus dieser Zeile: wie viel des gerenderten Seitentextes im rohen HTML fehlt. Kleine Lücken sind normal und kein Handlungsbedarf – ein Cookie-Banner, ein nachgeladenes Testimonial, ein Chat-Widget. Große Lücken bedeuten, dass die Substanz der Seite nicht in der Antwort steht, die Google zuerst indexiert.

Interne Links. Behandeln Sie diese Zeile als die wichtigste nach den Meta-Tags. Text, der spät eintrifft, wird spät indexiert. Links, die spät eintreffen, können bedeuten, dass die dahinterliegenden Seiten nie gefunden werden. Null interne Links im rohen HTML auf einer Seite, die nach dem Rendern Dutzende hat, ist ein Architekturproblem im Rendering-Kostüm.

JSON-LD-Blöcke. Per JavaScript eingefügte strukturierte Daten werden im Render-Durchgang gelesen – sofern er kommt. Eine Rich-Result-Eignung, die davon abhängt, ist eine Wette.

Unter der Tabelle gibt die Textvorschau den sichtbaren Text aus, der tatsächlich aus der Antwort Ihres Servers extrahiert wurde. Das ist die am wenigsten abstrakte Ausgabe dieser Seite: buchstäblich die Fassung Ihrer Seite, die Google zuerst indexiert. Ist sie leer, ist genau das der Befund.

Über die mehr als 100.000 Sites, die unsere Audit-Engine 2026 gecrawlt hat, ist Inhalt, der im gerenderten DOM vorhanden, im rohen HTML aber nicht auffindbar ist, der achthäufigste Fehler, den wir protokollieren – er tritt bei 31,4% der auditierten Sites auf (H1 2026). Er liegt damit auf einer Stufe mit fehlenden Alt-Texten und doppelten Title-Tags: nicht exotisch, nicht auf experimentelle Stacks beschränkt und häufig auf Sites zu finden, deren Teams überzeugt sind, serverseitig zu rendern.

Fünf Muster erklären den Großteil dessen, was wir sehen.

Die Startseite ist in Ordnung – und sonst nichts

Teams rendern die Startseite vor, weil sie die Seite ist, die sie vorführen, testen und die jedes Tool voreinstellt. Paginierte Listen, gefilterte Kategorien, Suchergebnisse und kontonahe Seiten fallen auf Client-Rendering zurück – und dort liegen die meisten indexierbaren URLs einer Website. Testen Sie immer eine tiefe Seite.

Die Navigation besteht aus JavaScript, nicht aus Anchors

Menüs und Paginierungen aus Klick-Handlern und router.push() erzeugen kein href, dem Googlebot in Durchgang eins folgen könnte. Für Menschen sind die Seiten erreichbar, für den ersten Crawl unsichtbar. Die Lösung ist unspektakulär: echte <a href>-Elemente, wobei JavaScript sie ergänzt statt ersetzt.

Ein Framework-Upgrade hat still eine Route umgestellt

Das Rendering-Verhalten ist eine Eigenschaft der Konfiguration, nicht des Frameworks. Ein Major-Upgrade, eine von Server auf Client verschobene Komponente oder eine neue Edge-Caching-Regel können eine Route von serverseitig gerendert auf rein clientseitig umstellen – ohne sichtbare Änderung im Browser. Niemand bemerkt es, weil die Seite für alle, die hinsehen, weiterhin korrekt aussieht.

Der Inhalt ist da, hat aber zu lange gebraucht

Eine Seite, die nach zwölf Sekunden API-Aufrufen korrekt rendert, ist eine Seite, deren Rendern in ein Timeout laufen kann. Googles Renderer gibt – wie unserer – irgendwann auf. Langsames Rendern ist ein Rendering-Fehler mit Verzögerung.

Der Server behandelt Crawler anders

Manche Server weisen Anfragen mit dem User-Agent von Googlebot ab – meist als Bot-Filterung, an deren Aktivierung sich niemand mehr erinnert. Meldet dieser Test, dass der Googlebot-User-Agent abgewiesen wurde, gehen Sie dem sofort nach: Der echte Googlebot weist sich per Reverse-DNS aus, doch eine pauschale Sperre auf den User-Agent-String trifft ihn ebenfalls.

Nach Wirkung geordnet:

1. Verlagern Sie die kritischen Elemente in die Serverantwort. Title, Meta-Description, Canonical, H1 und den Haupttext der Seite. Jedes größere Framework unterstützt dafür Server-Side Rendering, statische Generierung oder Prerendering. Sie müssen nicht die ganze Anwendung umbauen – diese Elemente müssen in der ersten Antwort stehen.
2. Machen Sie interne Links zu echten Anchors. <a href="/produkte/widget"> im HTML, was auch immer das Klickverhalten darüber hinaus tut.
3. Halten Sie strukturierte Daten serverseitig. JSON-LD ist Text in einem Script-Tag; es gibt selten einen Grund, ihn im Browser zusammenzusetzen.
4. Treffen Sie noindex-Entscheidungen in der Serverantwort – und meinen Sie sie ernst. Ein noindex im rohen HTML wird im ersten Durchgang befolgt. Es später per JavaScript zu entfernen, macht das nicht rückgängig: Die Entscheidung fiel, bevor die Render-Warteschlange erreicht wurde.
5. Testen Sie genau die URLs erneut, die Sie geändert haben. Nicht die Startseite. Die Routen, die Sie angefasst haben.

Das rohe HTML zu reparieren ist dauerhafter, als den Render-Durchgang beschleunigen zu wollen – es beseitigt die Abhängigkeit, statt gegen sie anzutreten.

Drei ehrliche Einschränkungen gehören dazu.

Unser Renderer ist nicht Googles. Dieser Test nutzt Headless Chrome und wartet, bis das Netzwerk ruhig ist, bevor er die Momentaufnahme erstellt. Googles Web Rendering Service hat eigene Timeouts, ein eigenes Ressourcenbudget und eine Warteschlange, die niemand außerhalb von Google beobachten kann. Eine große Lücke hier ist ein starkes Indiz dafür, dass eine Seite gefährdet ist – kein Beweis, dass eine bestimmte URL nicht indexiert ist.

Er kann nicht sagen, was Google tatsächlich gespeichert hat. Das kann nur die URL-Prüfung in der Search Console, und auch nur für Properties, die Sie verifiziert haben. Zeigt dieser Test eine große Lücke, die Search Console die Seite aber als indexiert mit vollständigem Inhalt, dann hat der Render-Durchgang sie erreicht – Sie hatten Glück statt Sicherheit, aber die Seite ist heute in Ordnung.

Er prüft eine URL. Ein einzelnes Ergebnis lässt sich auf Templates verallgemeinern, nicht auf eine ganze Website. Fällt eine Produktseite durch, nehmen Sie an, dass alle Produktseiten durchfallen – bestätigen Sie es aber mit einem vollständigen Site-Audit, statt es vorauszusetzen.

Für die angrenzenden Prüfungen: Der robots.txt-Tester erklärt ein blockiertes Verdikt im Detail, der Sitemap-Finder zeigt, was Sie tatsächlich zum Crawlen einreichen, und der Mobile-Friendly-Test deckt die andere Hälfte der Mobile-First-Indexierung ab. Zeigt die Search Console das Symptom bereits, ist „Gecrawlt – zurzeit nicht indexiert" der Bericht, der am häufigsten auf das zurückführt, was dieser Test misst.