JavaScript SEO: JS vs No-JS Vergleich

Warum JavaScript-Rendering für SEO wichtig ist

Das eigentliche JavaScript-SEO-Problem ist nicht Google. Google stellt die Seite in eine Warteschlange und rendert sie; in Googles eigener Doku dauert das „ein paar Sekunden, kann aber auch länger dauern“. Verloren geht Content bei den Crawlern, die nie rendern. Vercel hat im Dezember 2024 gemessen: Die Bots von OpenAI und Anthropic laden deine JavaScript-Dateien herunter, führen sie aber nicht aus. Wenn deine React- oder Vue-App ihren Inhalt also erst im Browser zusammenbaut, sehen diese Bots ein leeres <div id="app"> und ziehen weiter. Dein Content existiert. Er ist nur für jeden Crawler unsichtbar, der keinen Browser startet.

Dieser JavaScript-Rendering-Checker ruft deine Seite auf zwei Arten ab: rohes HTML und volles Browser-Rendering. Er vergleicht Überschriften, Links und den kompletten Text zwischen beiden Versionen, damit du genau siehst, was ohne JS verschwindet. Wenn dein Hauptcontent erst nach Client-Side Rendering auftaucht, hast du ein Indexierungsproblem. Und jetzt kannst du es beweisen.

Eine Seite nach der anderen ist die richtige Tiefe für eine Diagnose und die falsche Form für ein Audit. Wechsel auf Ganze Website, dann liest das Tool jede URL deiner Sitemap als rohes HTML und meldet pro Seite, was ein Crawler ohne JavaScript bekommt: wie viele Wörter, ob es ein H1 gibt, ob JSON-LD überlebt und ob die Seite ein leerer Framework-Container ist, dessen Inhalt noch als JSON-Payload daneben liegt.

Wie rendert Google JavaScript?

Google rendert JavaScript, aber nicht in einem Durchgang. Googlebot crawlt eine URL, legt sie in eine Render-Queue, und ein Headless Chromium führt das JavaScript aus, sobald Googles Ressourcen es zulassen. Googles eigene Formulierung für diese Wartezeit lautet „ein paar Sekunden, kann aber auch länger dauern“. Keine Stunden, keine Tage, und kein veröffentlichter Worst Case, egal was SEO-Artikel behaupten. Bing rendert ebenfalls, mit der Evergreen-Chromium-Engine hinter Microsoft Edge, warnt aber selbst, dass JavaScript in der Breite auf jeder Seite jeder Website schwer zu verarbeiten ist. Gar nicht gerendert wird bei den KI-Crawlern. Client-seitiges Rendering funktioniert für Google. Der Rest des Feldes verliert.

SSR vs. CSR für SEO

Server-Side Rendering gewinnt bei SEO, ohne Wenn und Aber. SSR bedeutet, dein Server liefert fertig gerendertes HTML an den Browser und jeden Crawler, unabhängig davon, ob sie JavaScript ausführen. CSR baut das HTML im Browser zusammen, was bedeutet: alles, was vor dem JS-Lauf passiert, ist eine leere Hülle. SSR ist mehr Aufwand für deine Entwickler, aber der einzige Weg, zu garantieren, dass KI-Crawler deinen echten Content sehen.

Häufige JavaScript-SEO-Probleme

Dieselben Muster tauchen in jedem JS-SEO-Audit auf. Content, der nur in useEffect-Hooks existiert und für Bots niemals rendert. Client-seitiges Routing, das Meta-Tags oder die kanonische URL nicht updatet. Infinite Scroll ohne Fallback, das alles auf einmal lädt. Loading-States, die einen Spinner als sichtbaren Text zurückgeben. Buttons, die per Route-Change ohne echtes href-Attribut navigieren. Jedes dieser Probleme ist für KI-Crawler unsichtbar und macht deine Seite für Google schwer korrekt zu indexieren.

Was ein Website-Scan zeigt und was nicht

Der Website-Modus liest nur rohes HTML. Kein Browser, kein Rendering, eine ungezählte Anfrage pro Seite, deshalb brauchte der Scan dieser Website (130 Seiten) am 17. September 2026 gemessene 12 Sekunden. Ein gerenderter Abruf einer einzelnen Seite über denselben Worker dauerte zwei bis drei Sekunden, ein Rendering aller Seiten läge also im Minutenbereich.

Dieser Tausch kauft Genauigkeit bei der einen Frage und gibt die andere auf. Er sagt dir exakt, was ein Crawler ohne Rendering bekommt, denn das sind buchstäblich die Bytes, die er geladen hat. Er kann dir nicht sagen, was JavaScript ergänzt hätte, weil nie welches lief. Eine Seite mit 40 Wörtern kann eine kaputte React-Shell sein oder ein Kontaktformular, das tatsächlich aus 40 Wörtern besteht.

Deshalb ist das Urteil bewusst eng gefasst. Hülle heißt: Es gibt Framework-Hinweise und fast keinen Text, also einen leeren #root- oder #__next-Container oder eine Hydration-Payload neben weniger als 150 Wörtern. Dünn heißt wenig Text und gar kein Framework, das ist eine Aussage über den Inhalt und kein Rendering-Fehler. Wenn eine Zeile falsch aussieht, öffne die URL im Vergleichsmodus und lass sie rendern.

Weitere Tools entdecken

FAQ