JavaScript-SEO bezeichnet alle Maßnahmen, die dafür sorgen, dass Inhalte einer Website auch dann von Suchmaschinen gefunden, verstanden und indexiert werden, wenn sie erst im Browser durch JavaScript entstehen. Betroffen ist damit fast jede moderne Website: Single-Page-Anwendungen, nachgeladene Produktlisten, Inhalte hinter Tabs sowie alles, was per "Mehr laden" erscheint.

Der Kern des Themas lässt sich in einem Satz zusammenfassen: Eine Suchmaschine sieht zunächst nur den HTML-Code, den der Server ausliefert. Alles, was erst danach durch Skripte entsteht, erfordert einen zusätzlichen und deutlich teureren Arbeitsschritt – das Rendering.

Wie Google JavaScript verarbeitet

Die Verarbeitung läuft in zwei Wellen ab. Diese Zweiteilung ist die Ursache praktisch aller Probleme in diesem Bereich:

1. Crawling: Der Googlebot ruft die URL ab und erhält den HTML-Code vom Server. Enthaltene Links werden verfolgt, enthaltener Text kann sofort in den Index gelangen.
2. Rendering: Reicht das HTML nicht aus, wandert die Seite in eine Warteschlange. Dort wird sie später von einem Dienst mit aktueller Chromium-Engine geöffnet, die Skripte werden ausgeführt und das Ergebnis wird erneut ausgewertet.

Zwischen beiden Schritten liegt Zeit. In vielen Fällen sind es Minuten, es können aber auch Stunden oder mehr werden – Rendering ist rechenintensiv und wird entsprechend priorisiert. Für Inhalte, die schnell im Index stehen sollen (Nachrichten, Angebote, Termine), ist diese Verzögerung ein echtes Problem.

Wichtig ist außerdem: Der Renderer verhält sich nicht wie ein Nutzer. Er klickt nicht, scrollt nicht und wartet nicht beliebig lange. Inhalte, die erst nach einer Interaktion erscheinen, existieren für Suchmaschinen schlicht nicht.

Nicht jeder Crawler rendert

Google rendert JavaScript – daraus wird häufig geschlossen, das Thema sei erledigt. Der Rest des Netzes arbeitet jedoch anders:

• Andere Suchmaschinen rendern in unterschiedlichem Umfang und meist zurückhaltender.
• KI-Crawler wie GPTBot, ClaudeBot oder PerplexityBot führen in der Regel kein JavaScript aus. Was nicht im HTML steht, landet nicht in ihren Quellen – siehe Generative Engine Optimization.
• Vorschau-Bots von Messengern und sozialen Netzwerken lesen ausschließlich den HTML-Kopf. Werden Open-Graph-Angaben erst per JavaScript gesetzt, bleibt die Linkvorschau leer.
• Werbe- und Prüfsysteme arbeiten häufig ebenfalls ohne vollständiges Rendering.

Die Faustregel lautet deshalb unverändert: Alles, was für die Auffindbarkeit zählt, gehört in das ausgelieferte HTML – Titel, Beschreibung, Überschriften, Fließtext, Links und strukturierte Daten.

Typische Fehler

1. Links ohne href. Ein <div onclick="…"> ist für einen Crawler kein Link. Nur <a href="/ziel"> wird verfolgt. Seiten, die nur über Klick-Handler erreichbar sind, hängen ohne interne Verlinkung im Raum.
2. Routing über das Rautezeichen. Adressen der Form example.de/#/produkt/12 gelten als eine einzige URL. Was hinter dem Rautezeichen steht, wird nicht an den Server übertragen und ist als eigene Seite nicht indexierbar.
3. Meta-Angaben per Skript. Titel und Beschreibung, die erst im Browser gesetzt werden, greifen für viele Systeme zu spät.
4. Inhalte hinter Interaktion. Text, der erst nach Klick auf "Mehr anzeigen" oder beim Weiterscrollen nachgeladen wird, wird nicht erfasst. Bereits vorhandener, aber per CSS ausgeblendeter Text ist dagegen unkritisch.
5. Blockierte Ressourcen. Sind Skript- oder Stildateien per robots.txt gesperrt, rendert die Suchmaschine eine kaputte Seite.
6. Fehler beim Datenabruf. Schlägt eine Schnittstelle beim Rendering fehl, bleibt die Seite leer – im Browser des Nutzers funktioniert dieselbe Seite, weil der Abruf dort gelingt.

Rendering-Strategien im Vergleich

Das früher verbreitete Dynamic Rendering – Crawler bekommen eine vorgerenderte Fassung, Nutzer die Anwendung – gilt inzwischen als Übergangslösung und wird nicht mehr empfohlen. Zwei getrennte Auslieferungswege bedeuten dauerhaft zwei Fehlerquellen.

Prüfen, was die Suchmaschine wirklich sieht

1. Seitenquelltext ansehen. Über die Tastenkombination Strg+U erscheint das ausgelieferte HTML – nicht das, was die Entwicklerwerkzeuge zeigen. Was hier fehlt, muss gerendert werden.
2. JavaScript abschalten und die Seite neu laden. Was verschwindet, hängt am Rendering.
3. URL-Prüfung in der Google Search Console. Sie zeigt das gerenderte HTML, einen Screenshot und aufgetretene Ladefehler – das aussagekräftigste Werkzeug für diese Frage.
4. Nach Textstellen suchen. Ein wörtliches Zitat aus dem Fließtext in die Google-Suche eingeben: Wird die eigene Seite nicht gefunden, ist der Text nicht im Index.

Warum Statistiken bei JavaScript auseinanderlaufen

Dieselbe Technik erklärt eine Frage, die bei jeder Kampagne aufkommt: Warum zeigen drei Systeme drei verschiedene Zahlen? Weil sie an unterschiedlichen Stellen zählen:

• Das Serverlog zählt jede Anfrage, auch die von Bots.
• Analytics-Werkzeuge zählen erst, wenn ihr JavaScript ausgeführt wurde – also nur Besucher, die lange genug bleiben, keinen Blocker einsetzen und der Messung zugestimmt haben.
• Die Kampagnenstatistik zählt die ausgelieferten Aufrufe.

Alle drei Zahlen sind richtig, sie messen nur Unterschiedliches. Wer Webseiten Traffic aus mehreren Quellen vergleicht, sollte das im Kopf behalten: Abweichungen im zweistelligen Prozentbereich sind normal. Wer bei einer eBesucher-Kampagne die Zahlen abgleicht, sollte deshalb zuerst prüfen, ob das eigene Zählskript früh genug lädt – ein Skript, das erst nach mehreren Sekunden startet, verliert planmäßig einen Teil der Besuche.

Ein zweiter Punkt kommt hinzu: eBesucher überträgt grundsätzlich keinen Referrer. Besucher aus einer Kampagne erscheinen in Analytics daher unter "Direkt". Sauber trennen lässt sich das über UTM-Parameter in der Ziel-URL – diese stehen in der Adresse und funktionieren unabhängig davon, wie viel JavaScript im Spiel ist.

Checkliste

• Steht der zentrale Text im ausgelieferten HTML?
• Sind alle wichtigen Seiten über <a href> erreichbar?
• Hat jede Ansicht eine eigene, serverseitig aufrufbare URL ohne Rautezeichen?
• Werden Titel, Beschreibung, Canonical und Open-Graph-Angaben serverseitig gesetzt?
• Sind Skripte und Stildateien in der robots.txt freigegeben?
• Lädt die Messung früh genug, um Besucher nicht zu verlieren?

Zusammenfassung

• Suchmaschinen sehen zuerst nur das HTML vom Server; alles Weitere erfordert Rendering.
• Google rendert in einer zweiten Welle mit zeitlichem Abstand – viele andere Crawler rendern gar nicht.
• Links brauchen ein href, Ansichten brauchen eigene URLs ohne Rautezeichen.
• Server-Side Rendering und statische Erzeugung sind die zuverlässigsten Wege, Dynamic Rendering ist überholt.
• Die URL-Prüfung der Search Console zeigt, was tatsächlich ankommt.
• Abweichende Besucherzahlen zwischen Log, Analytics und Kampagnenstatistik sind eine Folge derselben Technik.