JavaScript-SEO: Vermeiden Sie die Fallstricke des serverseitigen Renderings

JavaScript-SEO ist derzeit eines der heißesten Themen in der SEO-Branche, da sich das moderne Web weiterentwickelt und immer mehr Websites neu gestartet werden oder auf JavaScript-basierten Webanwendungen basieren, hauptsächlich auf React oder AngularJS. Damit wird SEO komplexer, da wir sicherstellen müssen, dass Google JavaScript effektiv rendern kann, damit die Seiten korrekt indexiert und eingestuft werden können. Dies kann durch serverseitiges Rendern erreicht werden. Dies ist jedoch nicht ohne Risiko. In diesem Artikel gehe ich fünf Fehler beim serverseitigen Rendern durch und erkläre, wie Sie sie vermeiden können.

Sie suchen Unterstützung bei der technischen Optimierung Ihrer Website? Dann vereinbaren Sie einen unverbindlichen Termin mit unseren Beratern der Digital Strategies Group und finden Sie heraus, wo sie Ihnen weiterhelfen können.

Einen Termin beantragen!

Welche verschiedenen Arten von serverseitigem Rendering gibt es?

Das Vorab-Rendering Ihrer Website für Google auf Ihrem Server (serverseitiges Rendering, SSR) ist eine Option, um sicherzustellen, dass Ihre JavaScript-Website Googlbot-freundlich ist. Auf diese Weise können Sie die vorgerenderte HTML-Version Ihrer Website an Google liefern, während der Nutzer die normale (noch nicht gerenderte) Browserversion erhält.

Aber auch beim serverseitigen Rendern gibt es verschiedene Möglichkeiten, wie Sie der nächsten Grafik entnehmen können, die hilfreicherweise von Google bereitgestellt wurde, mit einigen nützlichen Ergänzungen von Jan-Willem Bobbink.

Es gibt drei Hauptwege zum Einrichten und Ausführen von serverseitigem Rendern:

1. Serverseitiges Rendern mit dynamischem HTML

Beim serverseitigen Rendering wird bei Bedarf eine gerenderte HTML-Version jeder URL erstellt.

2. Statisches Rendering mit statischem HTML

Im Grunde erstellt dies vorab eine vorgerenderte (statische) HTML-Version einer URL und speichert sie im Cache.

3. Serverseitiges Rendering mit (Re-)Hydration mit dynamischem HTML und JS/DOMs

Der Server stellt eine statische HTML-Version der URL bereit und der Client (Browser etc.) enthält bereits ein strukturiertes Document Object Model (DOM)-Markup. Der Client nimmt dies und verwandelt es in ein dynamisches DOM, das auf clientseitige Änderungen reagieren kann und es interaktiver macht.

Google hat einen großartigen Überblick über das Rendern des Webs veröffentlicht, mit allen Vor- und Nachteilen, plus einer tieferen Erklärung, falls Sie interessiert sind. Aber zuerst einmal, wenn Sie Hilfe zum Thema JavaScript SEO oder Server Side Rendering suchen, kontaktieren Sie uns bitte hier bei der Searchmetrics Digital Strategies Group.

In Kontakt kommen!

Fallstricke beim Rendern von JavaScript-Websites über den Server

Wir sind kürzlich bei einem unserer Kunden auf einige SSR-Probleme gestoßen. Sie betreiben ihre Website auf Angular JS und rendern sie mit Rendertron über ein Headless Chrome.

Sie verwenden einen statischen SSR-Rendering-Ansatz, was bedeutet, dass sie eine Seite rendern und das gerenderte HTML auf dem Server zwischenspeichern (im Voraus). Das zwischengespeicherte HTML wird nicht automatisch ersetzt, sondern basiert auf der Rendering-Logik. Im Folgenden sind fünf Probleme aufgeführt, auf die wir bei der Arbeit an dieser Website gestoßen sind. Ich teile sie hier mit Ihnen, damit Sie, wenn Sie ähnliche Herausforderungen haben, eine Vorstellung davon haben, wie Sie damit umgehen können. Dies kann jedoch als eine unfertige/erweiterbare Liste betrachtet werden.

1. Wenn du nichts tust

Wenn es Ihnen egal ist und Sie nicht darauf achten, wie Google Ihre Seite rendert, lassen Sie mich Ihnen zeigen, wie Google Ihre Seite rendert (tatsächlich sieht). Dies basiert auf einer Website, die auf einer Single-Page-Anwendung (SPA) unter Verwendung eines JavaScript-Frameworks ohne serverseitiges Rendering aufgebaut ist.

Das sieht nicht besonders vielversprechend aus, oder? Genau aus diesem Grund ist es wichtig, SSR zu verwenden, denn dann sieht es so aus:

2 . Seitennummerierung

Wie gehen Sie mit Ihren paginierten Seiten um, wenn es um das Rendern geht? Nun, besonders beim Veröffentlichen können paginierte Seiten immer noch eine gute Sache sein, um Google mit Ihren (neuesten) Artikeln zu versorgen, während Google sie durchsucht. Wenn Sie sich Ihre Protokolldateien ansehen, sehen Sie, wie Google auf Ihre Paginierung zugreift, sodass Sie wissen, wo es sinnvoll ist, eine vorgerenderte Version bereitzustellen (Spoiler: Sie müssen keine 399-URLs mit einer gerenderten Version bereitstellen )

Da unser Kunde mit einem statischen SSR-Ansatz rendert, hat er nur die erste Seite gerendert und die zwischengespeicherte Version von Seite 1 bis Seite 10 gespiegelt. Ohne gerenderte Version ab Seite 11 und weiter. Hier sind zwei Screenshots, die das Problem recht gut zeigen, wobei genau derselbe Inhalt von Seite 1 auch auf den Seiten 2-10 bereitgestellt wird.

Das bedeutet, dass Sie Google 10 Seiten mit den gleichen Inhalten und Artikeln geben. Idealerweise möchten Sie, dass Google alle Seiten mit korrekt paginierten Artikeln als einzigartig darstellt.

3 . Erneuern Sie die gerenderte Version der Kategorieseiten, nachdem ein neuer Artikel/ein neues Produkt veröffentlicht wurde

Unser Kunde hat sein Ranking in fast allen Google News-Produkten, wie AMP Carousels, Google News Boxes und Mobile News Boxes, mit Ausnahme von Publisher Carousels, ziemlich deutlich verbessert. Wir haben begonnen, dies zu untersuchen, und es stellte sich heraus, dass unser Kunde seine zwischengespeicherte Version nicht aktualisiert hat, als ein neuer Artikel veröffentlicht wurde. Wir fanden heraus, dass sie ihre zwischengespeicherte Version der Hauptkategorien eine Woche später erneuerten:

und auf Unterkategorien sogar einen Monat später.

Dies führte dazu, dass sie in ihrer vorgerenderten Version noch einen alten Artikel zum Thema Brexit hatten, aber nicht alle neuen Artikel zum Thema veröffentlicht hatten. Wir nehmen hier an, dass es aufgrund dieses Problems nicht genügend neue Artikel für Google gab, um ein Karussell zu füllen, und dies hatte einen großen negativen Einfluss auf ihre Leistung. Wir untersuchen noch die Auswirkungen der Änderung.

4 . Das Rendern kann zu doppelten Inhalten und einer falschen Kanonisierung führen

Die Bereitstellung einer vorgerenderten Version einer URL kann systembasierte Probleme verursachen. Da unser Kunde vorgerenderte Seiten lieferte, jede mit ihrer eigenen URL, die von der Render-Engine erstellt wurde, hatten diese URLs die Parameter „p=1; render=1“ und waren vollständig indexierbar:

Es gab sogar eine neue kanonische Einrichtung durch die SSR-Engine für diese URL. Ziemlich unheimlich, oder?

Idealerweise möchten Sie diese Parameter vom Google-Crawling ausschließen.

5 . Änderung des Seitentitels beim Rendern

Wir haben auch herausgefunden, dass aktuelle Seitentitel über JavaScript gerendert wurden. Dies wurde so gemacht, dass der HTML-Metatitel immer den Markennamen anzeigte, wenn JavaScript deaktiviert war. Und wenn der Benutzeragent nicht Googlebot ist, rendert er nur den Titel der HTML-Seite. Siehe die folgenden zwei Beispiele unten. Die erste zeigt die URL mit deaktiviertem JavaScript. Die zweite ist die gleiche URL, aber mit aktiviertem JavaScript.

Um sicherzustellen, dass Metadaten immer korrekt gerendert werden, sollten Sie sie in die nicht gerenderte Version (JavaScript) der URL aufnehmen.

Fazit

Serverseitiges Rendern kann nicht als Cookie-Cutter-Ansatz zum Rendern von Single-Page-Anwendungen verwendet werden. Besondere Aufmerksamkeit ist bei statischen Ansätzen erforderlich, bei denen Sie nur eine Momentaufnahme bereitstellen. Wie Sie am Beispiel unseres Kunden sehen können, müssen Sie sicherstellen, dass die SSR-Engine immer eine aktuelle Version der URL bereitstellt, da Google sonst Ihre neuesten Artikel nicht sieht und erfasst, und Sie schon wertvollem Traffic entgehen.

Stellen Sie vor dem Relaunch von einer HTML-basierten Website zu einem JavaScript-basierten Framework sicher, dass das serverseitige Rendering enthalten ist und immer dynamisch bereitgestellt wird!

Wenn Sie JavaScript-Probleme haben oder anderweitig Unterstützung bei der technischen Optimierung Ihrer Website suchen, dann vereinbaren Sie doch einen unverbindlichen Termin mit unseren Beratern der Digital Strategies Group und finden Sie heraus, wo sie Ihnen helfen können.

Einen Termin beantragen!