JavaScript SEO ist derzeit eines der spannendsten Themen der SEO-Branche, da immer mehr Websites auf JavaScript-basierten Anwendungen wie React oder AngularJS basieren. Dies erhöht allerdings die Komplexität von SEO, da sichergestellt werden muss, dass Google JavaScript effektiv rendern kann, damit die Seiten indexiert und richtig gerankt werden können. Dies kann durch Server-Side Rendering erreicht werden – allerdings nicht ohne Fallstricke. Fünf Fehler beim serverseitigen Rendering für JavaScript-Websites stelle ich euch am Beispiel in diesem Blogpost vor und erkläre, wie ihr diese vermeiden könnt.
Ihr wollt mehr Beratung zu den Grundlagen von JavaScript SEO? Unsere Experten von der Digital Strategies Group sind mit Herz und SEO-Verstand für eure Anfrage gerüstet. Vereinbart einfach einen Kennenlern-Termin!
Welche verschiedenen Arten von Server-Side Rendering gibt es?
Server-Side Rendering, kurz SSR, bezeichnet das Vorrendern eurer Website für Google auf dem Server. Damit soll sichergestellt werden, dass eure JavaScript-Website auch wirklich Googlbot-freundlich ist. Auf diese Weise könnt ihr die vorgerenderte HTML-Version eurer Website an Google übermitteln, während der Nutzer die normale – noch nicht gerenderte – Browserversion erhält.
Beim serverseitigen Rendern gibt es jedoch auch verschiedene Möglichkeiten, wie die folgende Abbildung zeigt, die von Google ,mit einigen nützlichen Ergänzungen von Jan-Willem Bobbink, bereitgestellt wurde.
Es gibt drei Hauptmethoden zum Einrichten und Ausführen des serverseitigen Renderns:
- Serverseitiges Rendern mit dynamischem HTML: Beim serverseitigen Rendern wird eine gerenderte HTML-Version jeder URL bei Bedarf erstellt.
- Statisches Rendering mit statischem HTML: Grundsätzlich wird eine vorgerenderte (statische) HTML-Version einer URL erstellt und im Cache gespeichert.
- Serverseitiges Rendering mit (Re-) Hydration mit dynamischem HTML und JS / DOMs: Der Server stellt eine statische HTML-Version der URL und des Clients (Browser usw.) bereit, die bereits eine strukturierte DOM-Markierung (Document Object Model) enthält. Der Client nimmt dies und verwandelt es in ein dynamisches DOM, das auf clientseitige Änderungen reagieren und es interaktiver gestalten kann.
Google hat eine gute Übersicht über das Website-Rendern mit allen Vor- und Nachteilen sowie eine ausführlichere Erklärung veröffentlicht. Wenn ihr eine Beratung zum Thema JavaScript SEO und Server-Side Rendering wünscht, meldet euch einfach zum Kennenlern-Termin hier bei der Searchmetrics Digital Strategies Group:
Fallstricke beim Rendern von JavaScript-Websites über den Server
Wir sind kürzlich auf einige SSR-Probleme mit einem unserer Kunden gestoßen, der seine Website auf Basis von Angular JS betreibt und mittels Rendertron über ein Headless Chrome rendert.
Dabei wird ein statischer SSR-Render-Ansatz verwendet, d.h., der Kunde rendert eine Seite und speichern den gerenderten HTML-Code im Voraus auf dem Server. Das zwischengespeicherte HTML wird nicht automatisch ersetzt, sondern basiert auf der Einstllung in der Renderlogik. Im Folgenden sind fünf Probleme aufgeführt, auf die wir bei der Arbeit an dieser Website gestoßen sind. Damit möchte ich euch eineige Lösungsansätze aufzeigen, falls ihr vor ähnlichen Schwierigkeiten steht.
1. Wie Google im Worst Case eure Website sieht
Wenn ihr nicht darauf achtet, wie Google eure Seite rendert, dann sieht das Ergebnis des Google-Renderings eurer Website im Worst Case so aus wie auf dem folgenden Screenshot. Er basiert auf einer Website, die auf einer Single-Page-Anwendung (SPA) unter Verwendung eines JavaScript-Frameworks ohne serverseitiges Rendering erstellt wurde:
Nun, das Beispiel sieht nicht wirklich vielversprechend aus, oder? Deshalb ist es wichtig, SSR zu verwenden, denn dann sieht es so aus:
2. Paginierungen
Wie gehe ich beim Rendern mit Seiten-Paginierungen um? Insbesondere für Publisher können paginierte Seiten immer noch eine gute Lösung sein, um Google die neuesten Artikel während des Crawlings durch den Google-Bot zu übermitteln. Wenn ihr auf eure Log-Files schaut, werdet ihr feststellen, wie Google auf eure Paginierung zugreift. Damit wisst ihr also, wo es sinnvoll ist, eine vorgerenderte Version bereitzustellen. (Spoiler: Ihr müsst keine 399 URLs mit einer gerenderten Version versehen…)
Da unser Kunde im Beispiel mit einem statischen SSR-Ansatz rendert, hat er nur die erste Seite gerendert und die zwischengespeicherte Version von Seite 1 bis Seite 10 gespiegelt – ab Seite 11 gibt es also keine gerenderte Version mehr. Hier sind zwei Screenshots, die das Problem recht gut zeigen – mit genau demselben Inhalt von Seite 1, der auch auf den Seiten 2-10 bereitgestellt wird:
Ihr seht: Die Lösung würde bedeuten, dass ihr Google zehn Seiten mit identischem Inhalt und den gleichen Artikeln gebt. Idealerweise möchte Google natürlich aber, dass alle Seiten mit korrekt paginierten Artikeln als einzigartig dargestellt werden.
3. Gerenderte Kategorieseite aktualisieren, nachdem neue Artikel-URL veröffentlicht wurde
Unser Kunde hat sein Ranking in fast allen Google-News-Properties wie AMP-Karusell und der Google-News-Box am Desktop und Mobile erheblich verbessert – mit Ausnahme des Publisher-Karussells. Wie sich herausstellte, hatte der Kunde seine vorgerendert und dann gecachte Version nicht aktualisiert, wenn ein neuer Artikel veröffentlicht wurde. Stattdessen wurde die zwischengespeicherte Version der Hauptkategorie erst eine Woche später aktualsiert:
Sub-Kategorien wurden sogar erst einen Monat später aktualisiert:
Dies führte dazu, dass sie in der vorgerenderten Version etwa noch alte Artikel zum Brexit enthalten waren – aber nicht die neuen Artikel zum Thema. Ich denke, dass Google also zu wenig aktuelle Artikel zum Thema vorfand, um ein Publisher-Karussell zu erstellen.
4. Das Rendern führt zu Duplicate Content und falschen Canonicals
Werden Google vorab gerenderte URL-Versionen bereitgestellt, kann dies zu systembasierten Problemen führen. Als unser Kunde vorgerenderte Seiten mit einer eigenen URL auslieferte, die von der Renderlogik erstellt wurden, hatten diese URLs den Parameter ?p=1;render=1 und waren vollständig indexierbar.
Es gab sogar eine neue kanonische URL-Version, die vom SSR eingerichtet wurde und in der Search Console nachprüfbar war:
Idealerweise sollten solche Parameter vom Google-Crawling ausgeschlossen sein.
5. Änderung des Page Titles beim Rendern
Uns ist zudem aufgefallen, dass die aktuellen Page Titles mit JavaScript gerendert wurden. Dabei enthielt der HTML Meta Title immer den Markennamen, wenn JavaScript deaktiviert war. Wenn der User Agent kein Googlebot ist, wird nur der HTML-Seitentitel gerendert. Dazu gibt’s im Folgenden zwei Beispiele – der erste Screenshot zeigt die URL mit deaktiviertem JavaScript – der zweite dieselbe URL, jedoch mit aktiviertem JavaScript.
Um also sicherzustellen, dass Metadaten immer korrekt gerendert bzw. angezeigt werden, sollten ihr sie bereits in die nicht gerenderte JavaScript-Version der URL mit aufnehmen.
5. Fazit
Das serverseitige Rendern ist per se kein Allheilmittel für das rendern von Single Page Applications. Auch hier gibt es Herausforderungen, die sich vorab genau angeschaut werden sollten. Besondere Aufmerksamkeit ist beim statischen Rendering erforderlich, weil immer nur eine Momentaufnahme der Website bereitgestellt wird. Wie ihr am Beispiel unseres Kunden seht, müsst ihr sicherstellen, dass die SSR-Engine immer eine aktuelle Version der URL bereitstellt, da Google sonst eure neuesten Artikel nicht erfassen kann und euch wertvoller Traffic entgeht
Stellt vor dem Relaunch einer HTML-basierten Website in ein JavaScript-basiertes Framework sicher, dass das serverseitige Rendering enthalten ist und immer dynamisch bereitgestellt wird!
Wenn ihr JavaScript-Probleme habt oder anderweitig Unterstützung bei der technischen Optimierung eurer Website braucht, könnt Sie einen unverbindlichen Termin mit unseren Beratern der Digital Strategies Group vereinbaren: