JavaScript SEO: JS vs No-JS Vergleich

Warum JavaScript-Rendering für SEO wichtig ist

JavaScript SEO scheitert an einer Sache: Google verzögert die JS-Ausführung um Stunden oder Tage, und KI-Crawler wie GPTBot und ClaudeBot führen gar kein JavaScript aus. Wenn deine React- oder Vue-App Content im Browser rendert, sehen diese Bots ein leeres <div id="app"> und ziehen weiter. Dein Content existiert, er ist nur für die Hälfte des Webs unsichtbar.

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 so, wie die meisten Entwickler annehmen. Googlebot crawlt eine URL, stellt die Seite in eine Render-Queue, wartet, bis Googles Render-Service Kapazität hat, und verarbeitet sie dann mit einem Headless Chromium. Die Render-Queue kann auf kleinen Sites Stunden dauern, auf größeren Tage. Bing hat ähnliche Latenz, und KI-Crawler wie GPTBot und ClaudeBot führen JavaScript gar nicht aus. Client-seitiges Rendering funktioniert für Google, nur langsamer.

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 ist eine Website mit 122 Seiten in rund zwanzig Sekunden fertig statt in den zwanzig Minuten, die ein Rendering pro Seite kosten würde.

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