Google verarbeitet JavaScript-Seiten in drei Phasen: Crawling, Rendering und Indexierung. Alle Seiten mit Statuscode 200 kommen in eine Render-Warteschlange, in der sie laut Google Sekunden, aber auch länger bleiben können. Erst das gerenderte HTML wird indexiert – Inhalte, die erst nach einem Klick nachgeladen werden, erscheinen nie darin.
Website & Technik
JavaScript-SEO: Wenn Inhalte erst im Browser entstehen
Das Wichtigste in Kürze
- Googlebot klickt nicht, scrollt nicht und füllt keine Formulare aus.
- Navigation per onclick oder Knopf wird nicht verfolgt – Links brauchen ein echtes href.
- Routing über URL-Fragmente verhindert laut Google, dass Adressen zuverlässig entdeckt werden.
- Der Live-Test der URL-Prüfung zeigt im gerenderten HTML, was Google tatsächlich bekommt.
Warum das ein eigenes Thema ist
Bei einer klassischen Website steht der Inhalt im HTML, das der Server ausliefert. Googlebot lädt die Datei, liest den Text, fertig.
Bei modernen Anwendungen ist das anders: Der Server liefert ein weitgehend leeres Gerüst, und der eigentliche Inhalt entsteht erst, wenn JavaScript im Browser ausgeführt wird. Google kommt damit zurecht – aber anders, langsamer und fehleranfälliger als im einfachen Fall.
Wer das nicht weiß, sucht Indexierungsprobleme an den falschen Stellen.
Die drei Phasen
Google beschreibt die Verarbeitung in drei aufeinanderfolgenden Schritten:
| Phase | Was passiert |
|---|---|
| 1. Crawling | Googlebot ruft die URL ab, prüft die robots.txt und liest im HTML nach Links |
| 2. Rendering | Die Seite kommt in eine Warteschlange und wird von einem Chromium ohne Oberfläche ausgeführt |
| 3. Indexierung | Erst das fertig gerenderte HTML wird ausgewertet und nach weiteren Links durchsucht |
Zwei Aussagen aus Googles Dokumentation sind dabei entscheidend.
Erstens: Alle Seiten mit dem Statuscode 200 kommen in die Render-Warteschlange – unabhängig davon, ob überhaupt JavaScript vorhanden ist.
Zweitens: Eine Seite könne dort einige Sekunden bleiben, es könne aber auch länger dauern.
Die zweite Aussage ist der praktische Kern. Zwischen Crawling und Indexierung liegt eine Verzögerung, die Google selbst nicht beziffert. Für eine Nachrichtenseite ist das relevant, für eine Unternehmenswebsite mit monatlichen Änderungen meist nicht.
Die vier Fehler, die tatsächlich vorkommen
Links, die keine Links sind
Googlebot findet Links im HTML. Ein <div onclick="..."> oder ein Knopf, der per JavaScript zur nächsten Seite navigiert, ist kein Link – er wird nicht verfolgt.
Die Regel ist unspektakulär: Navigation gehört in <a href="..."> mit einer echten Adresse. Das gilt besonders für „Mehr laden“-Knöpfe in Listen und Archiven, hinter denen sonst der halbe Seitenbestand verschwindet.
Adressen mit Raute
Google nennt das ausdrücklich als Problem: Routing über URL-Fragmente verhindert, dass Adressen zuverlässig entdeckt werden. /#/produkte/schrauben ist für Google dieselbe Seite wie /.
Die Empfehlung lautet, stattdessen die History-API zu verwenden – also echte Pfade wie /produkte/schrauben.
Soft 404 in Einzelseiten-Anwendungen
Ein klassisches Muster: Eine nicht existierende Adresse liefert trotzdem 200, und erst JavaScript zeigt „Seite nicht gefunden“ an. Für Google sieht das aus wie eine gültige Seite mit dünnem Inhalt.
Googles Empfehlung: entweder einen ehrlichen Statuscode liefern oder per JavaScript ein noindex setzen. Siehe auch Indexierung.
Inhalte, die erst nach einer Handlung erscheinen
Googlebot klickt nicht, scrollt nicht und füllt keine Formulare aus. Was erst nach einem Klick nachgeladen wird, existiert für die Suche nicht. Das gilt genauso für die mobile Fassung – siehe Mobile Optimierung.
Der Unterschied ist wichtig: Ein zugeklappter Abschnitt, dessen Text im ausgelieferten HTML steht, wird indexiert. Ein Abschnitt, dessen Text erst beim Aufklappen vom Server geholt wird, nicht.
Was Google empfiehlt
Die wirksamste Maßnahme steht in der Dokumentation als Empfehlung: serverseitiges Rendern oder Vorab-Rendern – und zwar mit dem Hinweis, dass es die Geschwindigkeit für Nutzer und Crawler verbessert.
| Ansatz | Wie es funktioniert | Geeignet für |
|---|---|---|
| Serverseitiges Rendern | Der Server liefert fertiges HTML aus | Der Regelfall für öffentliche Inhalte |
| Statisches Vorab-Rendern | Seiten werden beim Bauen erzeugt | Inhalte, die sich selten ändern |
| Rein clientseitig | Alles entsteht im Browser | Angemeldete Bereiche, Anwendungen |
Die Unterscheidung in der letzten Zeile ist die entscheidende: Für einen internen Kundenbereich ist clientseitiges Rendern völlig in Ordnung – der soll gar nicht in den Index. Für Leistungsseiten und Artikel ist es ein vermeidbares Risiko.
Wie du prüfst, was Google wirklich sieht
Der einzige verlässliche Weg führt über die Search Console:
- URL-Prüfung öffnen, Adresse eingeben.
- „Live-Test“ ausführen.
- „Gerendertes HTML“ ansehen – nicht den Screenshot.
- Im gerenderten HTML nach einem charakteristischen Satz aus deinem Text suchen.
Fehlt er dort, fehlt er auch im Index. Das ist die Prüfung, die Vermutungen beendet.
Eine schnelle Gegenprobe ohne Werkzeug: JavaScript im Browser abschalten und die Seite neu laden. Was dann noch dasteht, kommt sicher aus dem HTML. Was verschwindet, hängt am Rendering – und damit an der Warteschlange.
Wann du dir darüber keine Gedanken machen musst
Eine normale WordPress-Website liefert ihren Inhalt serverseitig aus. Dort ist JavaScript-SEO kein Thema – abgesehen von einzelnen Bausteinen wie nachgeladenen Bewertungen, Buchungskalendern oder Produktkonfiguratoren.
Relevant wird es bei Anwendungen auf Basis moderner Frontend-Bibliotheken, bei Shops mit clientseitiger Filterung und bei Seiten, deren Inhalt über eine Schnittstelle nachgeladen wird.
Fazit
Google führt JavaScript aus – aber in einem zweiten Durchgang, mit unbestimmter Verzögerung und ohne zu klicken oder zu scrollen. Wer das berücksichtigt, hat die Hälfte der typischen Probleme nicht.
Die drei Punkte, die den Unterschied machen: echte Links mit href, echte Pfade statt Rauten, und die wichtigen Inhalte im ausgelieferten HTML. Alles andere darf ruhig im Browser entstehen.
Häufige Fragen
Ja. Google rendert Seiten mit einem Chromium ohne Oberfläche und indexiert das Ergebnis. Das geschieht allerdings in einem zweiten Durchgang nach dem Crawling, mit einer Verzögerung, die Google selbst nicht beziffert.
Nein. Googlebot klickt nicht und scrollt nicht. Ein zugeklappter Abschnitt, dessen Text bereits im ausgelieferten HTML steht, wird indexiert – ein Abschnitt, dessen Inhalt erst beim Aufklappen vom Server geholt wird, nicht.
Der Server liefert fertiges HTML statt eines leeren Gerüsts. Google empfiehlt es ausdrücklich, weil es Geschwindigkeit für Nutzer und Crawler verbessert. Für öffentliche Inhalte ist es der Regelfall, für angemeldete Bereiche unnötig.
Über die URL-Prüfung in der Search Console: Live-Test ausführen und „Gerendertes HTML" ansehen, nicht den Screenshot. Dort nach einem charakteristischen Satz aus deinem Text suchen – fehlt er, fehlt er auch im Index.
Quellen
- Google Search Central: Understand JavaScript SEO basics (abgerufen am 23.09.2026)
- Google Search Console-Hilfe: URL-Prüfung (abgerufen am 23.09.2026)
Lass uns dreißig Minuten über deine Sichtbarkeit sprechen
Kostenlos, unverbindlich, und mit einer ehrlichen Einschätzung - auch wenn die lautet, dass du mich gerade nicht brauchst.
Erstgespräch vereinbaren