Eine futuristische Maschine zeigt den Unterschied zwischen schnellem HTML-Crawling und langsamer JavaScript-Rendering-Warteschlange.
102 Views
JavaScript SEO ist das wohl am meisten diskutierte Technik-Thema zwischen Webentwicklern und Marketing-Teams. Als Single Page Applications (SPAs) wie React, Vue.js oder Angular den Markt eroberten, war die Aufregung groß: Plötzlich lud die Seite nicht mehr neu, App-ähnliche Erlebnisse im Browser waren möglich.
Doch für Suchmaschinen war das ein Rückschritt in die Steinzeit. Denn bei klassischem "Client-Side Rendering" (CSR) sendet der Server anfangs nur eine leere HTML-Hülle mit einem <script>-Tag. "Aber Google kann doch heutzutage JavaScript ausführen!" – das ist der Standard-Satz vieler Entwickler. Ja, das stimmt. Aber das "Wie" und vor allem das "Wann" machen in der Praxis den Unterschied zwischen Platz 1 und Platz 100 aus. In diesem Guide schauen wir uns an, wie der Crawler Ihre JS-Applikation wirklich verarbeitet.
1. Die Realität: Das "Zwei-Phasen-Crawling"
Googlebot ist nicht ein einzelner Prozess, der Ihre Seite besucht und alles auf einmal sieht. Das System für JavaScript SEO basiert auf dem sogenannten WRS (Web Rendering Service) und läuft in zwei völlig getrennten Phasen ab.
Phase 1: Das initiale HTML-Crawling (Schnell & Billig) Googlebot lädt das reine HTML vom Server herunter. Kein CSS, kein JS. Alles, was in diesem Moment im Quelltext steht (im Browser unter view-source), wird sofort indexiert und für das Ranking genutzt. Hat Ihre React-App hier nur ein <div id="root"></div>, sieht Google in Phase 1: Nichts.
Phase 2: Die Rendering-Queue (Langsam & Teuer) Wenn Googlebot im HTML ein JavaScript-Tag findet, schiebt er die Seite in eine "Rendering Queue" (Warteschlange). Irgendwann später – das können Minuten, aber oft auch Tage oder Wochen sein – startet Google einen echten Headless Chrome-Browser (WRS). Erst jetzt wird das JS ausgeführt, die API-Calls werden gemacht und der finale DOM-Tree wird gerendert.
Warum ist das ein Problem?
Das Ausführen von JS kostet Google massiv Rechenleistung. Bei News-Seiten, Shops oder neuen Blogartikeln können Sie es sich nicht leisten, Tage zu warten, bis der Content indexiert wird.
2. Die Architektur-Lösung: SSR und SSG
Die Lösung für erfolgreiches JavaScript SEO ist nicht, auf JS zu verzichten. Die Lösung ist, dem Crawler die Arbeit abzunehmen. Als Entwickler müssen Sie das Rendering auf Ihren eigenen Server verlagern.
1. Client-Side Rendering (CSR) - Die Standard-SPA
Was passiert? JS wird beim Nutzer (oder Bot) im Browser ausgeführt.
SEO-Status: Kritisch. Nur für Log-in-Bereiche (Dashboards) nutzen, niemals für Public Content.
2. Server-Side Rendering (SSR) - Der Retter
Was passiert? Frameworks wie Next.js (React) oder Nuxt.js (Vue) führen das JavaScript auf dem Node.js-Server aus, bevor die Seite gesendet wird. Der Bot bekommt ein fertiges, voll gerendertes HTML-Dokument.
SEO-Status: Perfekt. Google sieht alles sofort in Phase 1. Danach "hydriert" das JS im Browser des Nutzers, damit die Seite interaktiv bleibt.
3. Static Site Generation (SSG) - Der Turbo
Was passiert? Das HTML wird schon beim "Build-Prozess" (npm run build) statisch generiert (z.B. mit Astro oder Gatsby).
SEO-Status: Optimal für Performance und SEO, perfekt für Blogs und Unternehmensseiten, deren Inhalte sich nicht sekündlich ändern.
3. Der Quick-Fix: Dynamic Rendering
Was tun Sie, wenn Sie eine riesige Legacy-SPA (CSR) haben, der CTO aber kein Budget für ein Rewrite auf Next.js freigibt? Hier hilft "Dynamic Rendering".
Das Prinzip: Ihr Webserver (z.B. NGINX oder Apache) prüft den User-Agent.
Wenn ein menschlicher Nutzer kommt (Chrome, Safari), senden Sie ihm die normale, leere JS-App.
Wenn der Googlebot kommt, leiten Sie die Anfrage an einen eigenen Rendering-Server (z.B. Puppeteer oder Rendertron) weiter. Dieser führt das JS aus und sendet dem Bot ein flaches, statisches HTML (einen Snapshot).
Achtung: Google hat offiziell verkündet, dass Dynamic Rendering nur noch als "Übergangslösung" angesehen wird. Langfristig sollten Applikationen auf natives SSR umgestellt werden.
Fazit: Bauen Sie Hybrid-Apps (Isomorphic)
Beim JavaScript SEO geht es nicht darum, die Technologie zu verteufeln. Es geht um "Isomorphic JavaScript" (oder "Universal JS"). Schreiben Sie Code, der sowohl auf dem Node-Server als auch im Client-Browser laufen kann. Liefern Sie für den "First Paint" und den Crawler sauberes HTML aus, und lassen Sie JavaScript danach die Nutzer-Interaktion (Hydration) übernehmen.
Wir wissen nun, dass der Code für den Bot da sein muss. Doch was passiert, wenn zu viel Code da ist? Wenn Filter und Paginierungen tausende identische URLs erzeugen?
Nein. Googlebot verarbeitet Skripte mit defer und async problemlos. Für die Performance (Core Web Vitals) ist defer sogar essenziell. Wichtig ist nur, dass das JS am Ende den Content in den DOM schreibt.
Das Timeout im WRS ist strenger als im normalen Browser. Googlebot scrollt nicht, klickt keine Buttons und wartet im Schnitt nur etwa 5 Sekunden auf Netzwerk-Responses (API-Calls). Wenn Ihre API langsam ist, sieht Google eine leere Seite.
Ja, aber Vorsicht: Wenn Sie React Helmet in einer reinen CSR-App nutzen, stehen die Meta-Tags (Title, Description) erst nach dem JS-Rendering im DOM. Das ist für Google OK (Phase 2), aber schlecht für Social-Media-Crawler (Facebook, LinkedIn), die oft gar kein JS ausführen. Deshalb: SSR nutzen!
Wenn Sie ein eigenes JS-Skript für Lazy Loading schreiben und der Bot nicht scrollt, sieht er die Bilder nicht. Nutzen Sie daher immer das native HTML-Attribut . Der Browser und der Bot erledigen den Rest automatisch.
Das URL-Chaos in Shops und großen Apps
Sie haben einen Online-Shop mit SSR gebaut. Ein Nutzer filtert nach "Rote Schuhe, Größe 43, Marke Adidas". Die URL ändert sich, der Content ändert sich. Aber was macht der Googlebot? Er klickt auf jeden Filter und generiert Millionen von (fast identischen) URLs. Die Folge: Duplicate Content.
Im nächsten Teil unserer Masterclass tauchen wir in die Welt der URL-Strukturen ein. Wir klären den Unterschied zwischen Canonical-Tags, Noindex und der robots.txt – und wann Entwickler was einsetzen müssen.
Webinteger arbeitet seit vielen Jahren produktiv mit Linux-basierten Entwicklungsumgebungen unter Windows. Der Fokus liegt auf performanten Setups mit WSL 2, Docker, PHP, Node.js und modernen Build-Tools in realen Projekten – nicht auf theoretischen Beispielkonfigurationen.
Die Artikel dieser Serie entstehen direkt aus dem täglichen Einsatz in Kunden- und Eigenprojekten und dokumentieren bewusst auch typische Fehler, Engpässe und bewährte Workarounds.
Webseite besuchen
. Der Browser und der Bot erledigen den Rest automatisch.