JavaScript SEO: Was Google rendern kann und was nicht

Googlebot klickt nicht und scrollt nicht. Inhalte müssen im gerenderten HTML stehen, damit sie gesehen werden. Ahrefs fasst das in dem Satz zusammen, dass Inhalte im DOM stehen müssen.

Daraus folgen einige Regeln:

• Links nur als <a href>. Links, die JavaScript erzeugt, werden nur verfolgt, wenn sie als echte Links mit Ziel im HTML stehen. Ahrefs nennt diese Form ausdrücklich.
• Lazy Loading für Bilder, nicht für Text. Bilder dürfen erst beim Scrollen geladen werden. Textinhalte, die erst beim Scrollen erscheinen, können Suchmaschinen verborgen bleiben.
• History API statt Hash-Routen. Adressen mit Raute, etwa /#/leistungen, erschweren das Crawlen. Ahrefs empfiehlt saubere Adressen mit der History API.
• Titel, Meta-Description und noindex nicht erst per JavaScript setzen. Seokratie rät, diese Angaben von Anfang an im HTML zu haben.
• Weiterleitungen per JavaScript sind clientseitig. Ahrefs weist darauf hin, dass sie anders verarbeitet werden als serverseitige Weiterleitungen. Verwenden Sie für dauerhafte Umzüge serverseitige 301-Weiterleitungen.

Eine Website kann auf unterschiedliche Weise erzeugt werden. Die Wahl beeinflusst, was Google beim ersten Abruf sieht.

• Client-Side Rendering: Der Browser baut die Seite aus JavaScript zusammen. Inhalte stehen erst nach dem Rendern zur Verfügung.
• Server-Side Rendering: Der Server liefert das fertige HTML. Inhalte sind sofort lesbar.
• Prerendering: Die Seiten werden vorab als HTML erzeugt und ausgeliefert.
• Dynamic Rendering: Suchmaschinen erhalten eine vorgerenderte Version, Nutzer die normale. Ahrefs nennt diese Option, ohne eine Empfehlung auszusprechen.

Google schreibt, Server-Side Rendering oder Prerendering seien weiterhin eine gute Idee, weil sie die Website für Nutzer und Crawler schneller machen. Für die meisten Projekte ist das der sicherste Weg.

Seokratie nennt in seinem Ratgeber einige wiederkehrende Probleme:

• Fehlende Indexierung von JavaScript-Inhalten. Nachgeladener Text erscheint nicht im Index, wenn er erst nach dem Laden entsteht. Die Lösung ist Server-Side Rendering, damit der Inhalt beim ersten Aufruf vorliegt.
• Langsame Ladezeiten. Zu viel Script bremst die Seite. Kleinere Dateien, Code-Splitting und verzögertes Laden helfen.
• Links, die nur per JavaScript entstehen. Crawler können sie übersehen. Wichtige Links gehören ins HTML.
• Unterschiedliche Inhalte in HTML und gerendertem Stand. Widersprüchliche Signale verwirren Suchmaschinen. Titel, Überschriften, Meta-Angaben und Canonicals sollten im ursprünglichen HTML stehen.

Einige Anzeichen deuten darauf hin, dass JavaScript ein Problem macht:

• Der Haupttext fehlt, wenn JavaScript deaktiviert ist. Dr. Web nennt diesen Test, weil er das Problem sichtbar macht.
• Seiten erscheinen in der Search Console als gecrawlt, aber nicht indexiert. Die Meldungen erklärt der Beitrag Seiten nicht indexiert.
• Links fehlen im Crawl. Seokratie warnt, dass Links, die nur per JavaScript entstehen, von Crawlern übersehen werden können.
• Die Ladezeit ist hoch. Dann bremsen große Skripte die Seite, bevor der Inhalt erscheint.

JavaScript kann die Ladezeit stark beeinflussen. Dr. Web nennt die Grenzwerte von web.dev: für den größten Inhalt (LCP) 2,5 Sekunden, für die Reaktionszeit (INP) 200 Millisekunden und für die Layoutstabilität (CLS) 0,1, jeweils im 75. Perzentil. Schwere Skripte verschlechtern diese Werte. Die Maßnahmen dagegen beschreibt der Beitrag Core Web Vitals verbessern.

Google nennt den Rich Results Test und die URL-Prüfung in der Search Console als Werkzeuge, die das gerenderte HTML zeigen. Beide Werkzeuge prüfen, ob Text, Links und Meta-Angaben bei Google ankommen. Ahrefs unterscheidet dabei den Quelltext, der das rohe HTML zeigt, und den Inspektor, der den gerenderten DOM zeigt. Für JavaScript-Seiten ist der gerenderte Stand entscheidend.

1. Die Seite in der URL-Prüfung öffnen. Die Search Console zeigt die gerenderte Version.
2. Den Haupttext im gerenderten HTML suchen. Fehlt er, ist er für Google nicht sichtbar.
3. Die internen Links im gerenderten HTML zählen. Sie müssen als echte Links vorliegen.
4. Titel und Canonical prüfen. Beide sollten im gerenderten Stand dieselben Angaben enthalten wie im HTML.
5. Mit deaktiviertem JavaScript testen. Was dann fehlt, hängt von der Rendering-Phase ab.

Die wirksamsten Lösungen sind bekannt:

• Inhalte beim ersten Aufruf ausliefern. Server-Side Rendering oder Prerendering sorgt dafür, dass der Haupttext im HTML steht.
• Wichtige Inhalte früh im HTML platzieren. Seokratie empfiehlt, zentrale Inhalte so weit oben wie möglich im HTML anzulegen.
• Crawling zulassen. Ahrefs rät, Googlebot den Zugriff auf JavaScript- und CSS-Dateien in der robots.txt nicht zu sperren.
• Saubere Adressen verwenden. Die History API erzeugt Adressen, die Suchmaschinen verstehen.
• Canonicals im HTML setzen. Doppelte Adressen bei Parametern lassen sich so eindeutig zuordnen. Die Grundlagen erklärt der Beitrag Canonical-Tags.

Prüfen Sie das Rendering vor allem in drei Fällen. Erstens bei einem Relaunch mit neuem Framework, weil dabei die Ausgabe der Seiten wechselt. Zweitens, wenn Seiten in der Search Console als gecrawlt, aber nicht indexiert erscheinen. Die Meldungen erklärt der Beitrag Seiten nicht indexiert. Drittens, wenn Inhalte nur nach einer Interaktion erscheinen.

Die Technik-Prüfung im Ganzen steht im Ratgeber Technische SEO-Checkliste. Eine Gesamtprüfung mit Rendering-Test bietet Technisches SEO.

• Der Haupttext steht im gerenderten HTML.
• Interne Links sind echte Links mit Ziel.
• Titel, Meta-Description und noindex stehen im HTML, nicht nur per Script.
• Crawler dürfen JavaScript- und CSS-Dateien abrufen.
• Adressen sind sauber, ohne Raute als Routing.
• Canonicals zeigen auf die bevorzugte Adresse.
• Die URL-Prüfung zeigt den erwarteten Stand.