Was Rendering bedeutet
Rendern heißt, aus dem Quellcode einer Seite das darzustellende Ergebnis zu erzeugen. Der Browser liest HTML, lädt CSS und JavaScript, führt Skripte aus, baut das Document Object Model (DOM) auf und zeichnet daraus die sichtbare Seite. Bei einfachen HTML-Seiten verändert das Rendering den Inhalt kaum. Bei modernen Websites, die Inhalte per JavaScript erzeugen oder nachladen, entsteht der eigentliche Inhalt erst in diesem Schritt.
Ursprüngliches HTML und gerendertes HTML
Für die Suchmaschinenoptimierung ist die Unterscheidung zwischen zwei Zuständen wichtig:
| Ursprüngliches HTML | Gerendertes HTML | |
|---|---|---|
| Entstehung | Antwort des Servers | nach Ausführung von JavaScript |
| Sichtbar im Browser über | Quelltext anzeigen (Strg+U) | Elemente-Ansicht der Entwicklertools |
| Sichtbar für Google | sofort beim Crawling | nach dem Rendering |
| Sichtbar für viele andere Crawler | ja | oft nicht |
Idealerweise enthalten beide Zustände dieselben wesentlichen Inhalte: Hauptüberschrift, Text, Links, Metadaten und strukturierte Daten. Große Abweichungen sind ein Risiko.
Der Web Rendering Service von Google
Google rendert Seiten mit dem Web Rendering Service (WRS), der seit 2019 immer auf einer aktuellen Version von Chromium basiert, man spricht vom „Evergreen Googlebot“. Moderne JavaScript-Funktionen werden dadurch unterstützt. Einige Besonderheiten sollten Sie aber kennen:
- Kein Nutzerverhalten: Der WRS klickt nicht, scrollt nicht wie ein Mensch und gibt nichts ein.
- Zustandslos: Cookies, lokaler Speicher und Sitzungsdaten werden zwischen Seitenabrufen nicht beibehalten.
- Begrenzte Ressourcen: Der WRS wartet nicht beliebig lange auf Skripte und Netzwerkanfragen. Er optimiert, etwa indem er Timer beschleunigt, aber sehr langsame Inhalte können fehlen.
- Großer Viewport: Für das Rendering nutzt Google einen hohen Viewport, sodass Inhalte, die per Lazy Loading beim Erreichen des sichtbaren Bereichs laden, oft erfasst werden – aber nur, wenn sie korrekt über die Intersection Observer API oder natives Lazy Loading umgesetzt sind.
- Berechtigungen werden abgelehnt: Anfragen nach Standort, Kamera oder Benachrichtigungen werden verweigert. Inhalte, die davon abhängen, erscheinen nicht.
- Caching: Google speichert Ressourcen wie JavaScript und CSS teils aggressiv zwischen. Dateinamen mit Versionskennung helfen, dass Änderungen erkannt werden.
Rendering-Arten im Überblick
| Art | Beschreibung | Vorteile | Nachteile |
|---|---|---|---|
| Statisches HTML | fertige Seiten auf dem Server | schnell, robust, für alle Crawler lesbar | wenig dynamisch ohne zusätzliche Technik |
| Server-Side Rendering (SSR) | Server erzeugt HTML pro Anfrage | aktuelle Inhalte, sofort lesbar | Serverlast, Komplexität |
| Static Site Generation (SSG) | HTML wird beim Build erzeugt | sehr schnell, günstig im Betrieb | Build-Zeiten bei vielen Seiten |
| Client-Side Rendering (CSR) | Browser erzeugt Inhalt | flüssige App-Erlebnisse | abhängig vom Rendering, langsamer erster Inhalt |
| Hydration | SSR/SSG-HTML wird im Browser „belebt“ | kombiniert Lesbarkeit und Interaktivität | viel JavaScript kann INP verschlechtern |
| Partial Hydration, Islands | nur interaktive Teile werden belebt | wenig JavaScript, gute Performance | Architektur muss darauf ausgelegt sein |
| Streaming SSR | HTML wird in Teilen gesendet | schneller erster Inhalt | technisch anspruchsvoll |
Mehr zur Auswahl bei JavaScript-Frameworks im Beitrag JavaScript-SEO.
Rendering-Probleme erkennen
Mit der URL-Prüfung
Die URL-Prüfung in der Search Console zeigt nach einem Live-Test das gerenderte HTML, einen Screenshot und die geladenen Ressourcen. Prüfen Sie:
- Ist der Hauptinhalt im gerenderten HTML vorhanden?
- Stimmen Title, Canonical und Robots-Anweisungen?
- Gibt es Ressourcen, die nicht geladen werden konnten?
- Gibt es JavaScript-Fehler in der Konsole?
Mit einem Vergleich
Crawler wie Screaming Frog oder Sitebulb können jede Seite zweimal erfassen – ohne und mit JavaScript-Rendering. Der Vergleich zeigt, welche Inhalte, Links oder Metadaten erst durch JavaScript entstehen oder sich verändern. Bei vielen Abweichungen lohnt sich ein genauer Blick.
Mit Textsuchen
Eine Suche nach einem Satz aus dem Hauptinhalt in Anführungszeichen, eingeschränkt auf Ihre Domain, zeigt, ob Google diesen Text indexiert hat.
Typische Rendering-Probleme und ihre Lösungen
| Problem | Ursache | Lösung |
|---|---|---|
| Hauptinhalt fehlt im gerenderten HTML | API-Anfrage zu langsam oder fehlerhaft | SSR/SSG, Inhalte direkt ins HTML |
| Seite wird unvollständig dargestellt | CSS oder JavaScript per robots.txt blockiert | Ressourcen freigeben |
| Links werden nicht gefunden | Navigation ohne href |
echte Links verwenden |
| Metadaten falsch | JavaScript überschreibt Title oder Canonical | serverseitig setzen |
| Lazy-Loading-Inhalte fehlen | Laden nur bei Scroll-Ereignis | natives Lazy Loading oder Intersection Observer |
| Consent-Banner verdeckt Inhalte | Inhalte erst nach Zustimmung geladen | Inhalte unabhängig vom Banner laden |
| Personalisierte Inhalte | Inhalte abhängig von Cookies oder Standort | Standardinhalt für Erstbesucher bereitstellen |
| Fehlerseiten mit Code 200 | Single-Page-App ohne Serverstatus | echte 404 vom Server |
Manche Consent-Lösungen laden Teile des Seiteninhalts oder wichtige Skripte erst, nachdem der Nutzer zugestimmt hat. Der Googlebot stimmt nie zu. Wenn dadurch Inhalte, eingebettete Karten oder strukturierte Daten fehlen, sieht Google eine unvollständige Seite. Prüfen Sie das gerenderte HTML nach jeder Änderung an der Consent-Lösung.
Rendering und Performance
Rendering betrifft nicht nur Suchmaschinen, sondern auch die Geschwindigkeit für Nutzer. Je mehr die Seite im Browser berechnen muss, bevor sie nutzbar ist, desto schlechter fallen die Core Web Vitals aus. Serverseitig erzeugtes HTML verbessert meist den Largest Contentful Paint. Weniger JavaScript und eine schlanke Hydration verbessern Interaction to Next Paint. Mehr in den Beiträgen Core Web Vitals und Interaction to Next Paint.
Kurz beantwortet
Rendert Google jede Seite?
Google gibt an, grundsätzlich alle Seiten mit Statuscode 200 zu rendern, sofern sie nicht per noindex oder robots.txt ausgeschlossen sind. Das Rendering kann aber verzögert stattfinden oder Ressourcen auslassen.
Wie erkenne ich, ob meine Website stark von JavaScript abhängt?
Deaktivieren Sie JavaScript im Browser und laden Sie die Seite neu. Bleibt sie weitgehend leer, hängen Inhalte vom Rendering ab.
Beeinflusst Rendering das Crawl-Budget?
Ja. Jede Ressource, die für das Rendering geladen werden muss, verbraucht Crawling-Kapazität. Bei großen Websites mit viel JavaScript kann das spürbar werden.