JavaScript-Websites: Ist das Spiel die Kerze wert? Meinung der Experten

Um diese Frage zu beantworten, müssen vorher ein paar Grundlagen verstanden werden. Der wohl wichtigste Unterschied zwischen Rich-JS-Websites und herkömmlichen Websites besteht darin, dass JavaScript nicht vom Server, sondern vom Browser ausgeführt wird. Wenn eine Suchmaschine die Inhalte crawlen möchte, die durch JavaScript erzeugt werden, muss die Suchmaschine die Arbeit des Browsers, das Rendern von JavaScript, übernehmen.

Google nutzt laut eigenen Aussagen den Web Rendering Service (WRS), welcher auf dem Stand des Google Chrome Browsers in der Version 41 basiert, um JavaScript zu rendern. Technologien und Features aus dem Jahr 2015. Wer gerne den Unterschied zwischen dem Chrome 41 und der aktuellen Version vergleichen möchte, kann sich caniuse.com anschauen.

Abgesehen davon, ist Google aktuell die einzige Suchmaschine, die überhaupt versucht, JavaScript zu rendern. Andere Crawler von Unternehmen wie z. B. Bing, Facebook, Twitter usw. versuchen es gar nicht. Ist es sinnvoll, Content bereitzustellen, den nur Google sieht?

Allgemein beschäftigen sich Technical-SEOs damit, Websites und deren Inhalte in einem bestmöglichen Zustand schnell und einfach an die Suchmaschinen auszuliefern. Wer sich dessen bewusst ist, wird sich wohl die Frage selbst beantworten können, ob es sinnvoll ist, eine Website und deren Content der Suchmaschinen Client-Side bereitzustellen.

In der Regel wird JavaScript dazu verwendet, um eine Website mit Funktionalitäten im Sinne des Progressive-Enhancements zu bereichern, die die User-Experience und die Bedienbarkeit verbessern sollen. Sprechen wir von JavaScript-basierten Seiten, dann sieht die Anwendung etwas anders aus.

Grundsätzlich unterscheidet sich die Auslieferung von JavaScript-basierten Seiten von der von den konventionellen folgendermaßen: Normalerweise wird das HTML-Dokument auf dem Server gerendert und fertig, also mit allen relevanten Inhalten im DOM (Document Object Model) an den Client (z. B. dem Browser) geschickt.

Reine JavaScript-Seiten werden prinzipiell als leeres Dokument an den Client geschickt und erst dort gerendert. Für Maschinen, insbesondere Crawler, Spider und Bots bedeutet das Auslesen der Inhalte somit wesentlich mehr Aufwand, denn das JavaScript muss von ihnen ausgeführt und die Seite gerendert werden.

Ja, auch JavaScript-basierte Webseiten können optimiert werden. Dabei gilt folgende Faustregel: Je leichter Inhalte zu erreichen sind, desto zuverlässiger und schneller können sie indexiert werden.

Neben der Grundausstattung wie den Meta-Tags sind wichtige Faktoren die Lade-Performance (Dateigrößen, Code-Reduzierung, serverseitiges Rendering), Rendering-Performance (Code-Qualität und Optimierung, Pre-Compiling bei Frameworks) und, wie auch bei statischen Seiten, Zugänglichkeit (Accessibility) sowie Semantik (Kontext).

Diese Frage kann man eindeutig mit „Jein" beantworten. Google ist in der Interpretierung von JavaScript eindeutig besser, als die Mitbewerber. Jedoch haben Tests gezeigt, dass auch Google hier noch nicht perfekt arbeitet. Man sollte sich hier also nicht auf die Fähigkeiten der Suchmaschine verlassen.

Wer auch auf andere Suchmaschinen, wie beispielsweise Yandex angewiesen ist, sollte hier grundsätzlich vorsichtig sein, da andere Suchdienste beim Interpretieren von JavaScript Schwächen haben.

Historisch gesehen hatten Suchmaschinen mit der Indexierung von per JavaScript geladenen Inhalten immer große Probleme, aber während sich viele Suchmaschinen auch 2019 noch schwertun, JS-basierte Seiten zu verarbeiten, kommt Branchenprimus Google mittlerweile recht gut damit zurecht. Trotzdem gibt es noch zahlreiche Stolpersteine, die verhindern können, dass eine JS-basierte Seite gut gefunden wird.

Es ist aber durchaus möglich Seiten, die auf Frameworks wie Angular, React, Vue & Co basieren, für Google und auch andere Suchmaschinen zu optimieren. Jedoch ist eine Optimierung solcher Seiten meist deutlich aufwendiger und setzt ein tieferes technisches Verständnis voraus. Dazu kommt sich das auch das Auditing solcher Websites schwieriger gestaltet, nachdem bei weitem noch nicht alle SEO-Tools mit JavaScript umgehen können.

Aufgrund der oben genannten Argumente wird in den meisten Fällen eine Server-Side-Lösung empfohlen, um Rich-JS-Webseiten für SEO in den Griff zu bekommen. Bei diesen Lösungen wird dem User die Website wie gewohnt ausgespielt. Dem Crawler hingegen, wie z. B. dem Googlebot, wird eine bereits vorgerenderte Website ausgeliefert. Damit profitiert der User von allen Vorteilen die eine JS-Lösung mit sich bringt und der Crawler bekommt alle relevanten Inhalte, ohne selbst rendern zu müssen.

Google selbst empfiehlt in einigen Fällen Server-Side-Rendering. Google nennt es lediglich anders: „Dynamic Rendering". Interessant ist es auch, dass Google für die hauseigene Videoplattform YouTube Server-Side-Rendering einsetzt. Wenn das nicht schon genug Gründe gegen Client-Side-Rendering und für Server-Side-Rendering in Bezug auf SEO wären

Folgende Punkte spielen eine bedeutende Rolle:

Lade-Performance

Eine Seite sollte möglichst schnell an den Client ausgeliefert werden. Gerade in Zeiten der mobilen Devices spielt dieser Aspekt eine fundamentale Rolle und wirkt sich auf die Platzierung in den SERPs aus. Im Optimalfall sollte die Seite in einer Sekunde im Browser angezeigt werden und zumindest ansatzweise bedienbar sein.

Viele populäre JavaScript-Frameworks wie z. B. Angular, React oder Vue bieten SSR (Server-Side-Rendering) an. Dabei werden dedizierte Seiten auf dem Server vorgerendert, als fertiges HTML an den Client gesendet und die eigentliche Applikation dann im Hintergrund nachgeladen. Dadurch befinden sich initiale Inhalte bereits im DOM, wenn sie beim Client ankommen und können direkt konsumiert werden.

Genau wie bei konventionellen Seiten spielen Code-Optimierung und Architektur eine ebenso wichtige Rolle. In Zeiten von HTTP/2 wird z. B. eine große JavaScript-Datei gerne in mehrere sogenannte Chunks aufgeteilt, die dann parallel in einem Stream geladen und somit schneller ausgeliefert werden können.

Rendering-Performance

Wie bei herkömmlichen Seiten sollte der Code natürlich schlank und performant gehalten werden. Werden Frameworks benutzt, sollte der Code pre-compiled, also bereits vorkompiliert ausgeliefert werden. Angular nutzt dafür z. B. das AOT (Ahead Of Time) Compiling, welches die Kompilierung von Angular und Typescript bereits im Build-Prozess ausführt und natives JavaScript erzeugt. Durch eine Vorkompilierung wird dem Client-Device (also auch dem Bot) Rechenleistung abgenommen.

Zugänglichkeit und Semantik

Auch wenn das HTML über JavaScript generiert wird, gelten die gleichen Regeln für Zugänglichkeit und Barrierefreiheit wie bei den konventionellen Websites.

Z. B. sollten im Umfeld einer SPA (Single Page Application) die einzelnen Unterseiten über Deeplinks mittels eines Routings erreichbar gemacht werden (Anm.: wichtig ist dabei die Unterscheidung zwischen einem tatsächlichen Anchor-Tag mit sichtbarem Link und einem Button, der eigentlich nur als Schaltfläche für Interaktionen auf derselben Page dient). Auf diesem Wege kann die Suchmaschine die Seiten verfolgen und die Links können letztlich auch in die obligatorische Sitemap aufgenommen werden.

Es empfiehlt sich, wenn es das Budget zulässt, Microdata zu implementieren. Um die Einbindung in Javascript-basierte Seiten und SPAs (Single Page Applications), also dynamisch generierte Seiten zu erleichtern, wurde das JSON-LD-Format (JSON für Linked Data) für schema.org entwickelt. Der Vorteil an einem JSON-LD-Template im Gegensatz zu den schema.org-Annotationen ist die Unabhängigkeit vom HTML-Markup, denn es kann mit einem Script-Tag an entsprechender Stelle in das DOM injiziert und dynamisch befüllt werden. Viele Informationen, die über JSON-LD an die Suchmaschinen geliefert werden, generieren in den SERPs die begehrten Rich Snippets.

Es ist in diesem Zusammenhang eine Binsenweisheit, dass man (wenn man Websites mit JavaScript erfolgreich optimieren möchte) die Crawler von JS-Verzeichnissen nicht aussperren sollte. Daher sollte die robots.txt dahingehend geprüft werden. Die URLs müssen einzigartig sein, sonst ist eine korrekte Indexierung nicht möglich.

Auf Anfragen muss der Server den Status-Code 200 liefern, vom Umschreiben der URL mit pushState sollte man daher Abstand nehmen. Für JS-Seiten gilt das Gleiche, wie für HTML. Der Bot wertet Meta-Daten aus und sollte diese auch bekommen. Ähnliches gilt für vorhandene Hyperlinks und Bilder. Hier werden immer wieder die beschreibenden Attribute vergessen.

Während beim Abruf eines traditionellen serverseitigen HTML-Dokuments Struktur und Inhalt bereits im Quellcode enthalten sind, kommt bei React, Angular und Co JavaScript zum Einsatz, um das DOM (Document Object Model) erst clientseitig, also im Browser, fertig zu rendern. Das pre-DOM HTML kommt daher zunächst ziemlich leer daher. Wird nun der gesamte Inhalt einer Seite auf diese Art und Weise geladen, findet ein Suchmaschinen-Crawler, der lediglich den HTML-Code einer Seite ausliest, weder Links, denen er weiter folgen kann, noch grundsätzliche Informationen zum Inhalt der Seite, und zum Teil oft nicht einmal irgendwelche Meta-Tags.

Bisher ist Google leider die einzige Suchmaschine, von der wir wissen, dass sie eine Rendering Engine einsetzt, um JavaScript auszuführen und die Website ebenso zu „sehen" wie sie auch der User in seinem Browser sieht. Dass man JS- und CSS-Ressourcen nicht für den Googlebot blockiert, sollte selbstverständlich sein.

Dieses Rendern von Webseiten ist aber enorm ressourcenaufwendig – selbst für den Branchenriesen Google. Dazu kommt, dass Crawler anderer Suchmaschinen (sowie auch Crawler von Facebook, Twitter, LinkedIn usw., die Seiten beispielsweise für die Generierung einer Preview Box besuchen) noch überhaupt kein JavaScript rendern.

Das Zauberwort, um JavaScript Frameworks SEO-tauglich zu machen ist daher: Server-Side-Rendering. Statt den HMTL-Code erst auf Client-Seite errechnen zu lassen, wird die Seite schon serverseitig „vorgerendert" (pre-rendering) und fertig ausgeliefert. Dabei gibt es verschiedene Modelle, an welche User-Agents was ausgeliefert werden soll. So kann die bereits auf dem Server vorgerenderte Seite einfach an alle – sowohl Browser als auch Bots – ausgeliefert werden oder man setzt eine Middleware ein, um ausschließlich Bots die vorgerenderte Version zu zeigen, während die normalen User die JS-basierte Seite bekommen.

Google empfiehlt einen Mittelweg zu wählen, bei dem zunächst sowohl normale User als auch Suchmaschinen eine vorgerenderte Version der Seite ausgeliefert bekommen. Erst wenn der User beginnt, mit der Seite zu interagieren, beginnt das JavaScript über das DOM, den Quellcode zu verändern.

Dazu dürfen „klassische" technische SEO-Basics nicht vergessen werden. Zum Beispiel braucht natürlich jede Seite, die indexiert werden soll, eine eigene, einzigartige und dauerhafte URL. Denn URLs sind schließlich die Entitäten, die Suchmaschinen in den Suchergebnissen listen. Da man per JavaScript Inhalte dynamisch laden kann, ohne dass sich dabei die URL ändert, scheint das bei JS-Frameworks aber nicht immer selbstverständlich (Stichwort „Single Page App"). Als SEO muss man daher sichergehen, dass alle relevanten Seiten auf eigenen URLs liegen und dass diese auch immer direkt aufrufbar sind.

Auch das Handling von Meta-Tags, die korrekte Verwendung von Server Status Codes oder simple Verlinkungen können zu Stolpersteinen werden.

Da Google laut eigenen Aussagen von „Second Wave of Indexing" spricht, werden Websites am Anfang erst ohne den Einsatz von Rendering gecrawlt und gegebenenfalls indexiert. Erst beim zweiten Besuch wird das Rendering genutzt, um alle Inhalte zu erhalten. In einigen Fällen kann es vorkommen, dass zwischen den beiden Besuchen einige Tage liegen. Das heißt, Inhalte, die durch JavaScript erzeugt werden, landen später im Index als gewollt.

Ich gestehe, dass ich aus SEO-Sicht derzeit kein Freund davon bin. JavaScript war und ist in Bezug auf Funktionalität spannend und die Möglichkeiten von Progressive Web Apps (PWA) sind ebenfalls riesig. Als SEO hätte ich aber Bauchschmerzen, wenn ein Kunde sich hierauf fokussieren würde. JavaScript-Sites haben aber durch das Rendering oftmals mit höheren Ladezeiten zu kämpfen. Hier könnte Dynamic Rendering hilfreich sein.

Rein JavaScript-basierte Ansätze bedürfen einiges an Mehraufwand, um sie fit für Suchmaschinen zu machen und meistens ist der Code für eine SPA umfangreicher als der ihrer nativen Verwandten. Der Rechenaufwand für den Client, der ja häufig ein mobiles Endgerät mit relativ langsamen Prozessor ist, ist demnach signifikant größer. Das ist auch relevant für einen Crawler, der diese Rechenleistung ja ebenfalls aufbringen muss. Die Folge ist oft eine verlangsamte und unzuverlässige Indexierung.

Direkte, messbare und verwertbare Vorteile für SEO habe ich bei rein JavaScript-basierten Ansätzen noch nicht feststellen können. Denkbar wäre ein Konkurrenzvorteil durch verbesserte Bedienbarkeit, erhöhte Conversion und dadurch gesteigerte CTR.

Für Suchmaschinenoptimierer bringt JavaScript ganz neue Herausforderungen mit sich. Rein aus SEO-Sicht bringt die Optimierung einer JS-basierten Single-Page-Application große Herausforderungen mit sich. Neben der Problematik des Renderings tauchen bei solchen Seiten auch immer wieder ganz andere Fehlerquellen auf, die man von „traditionellen" Seiten kaum (mehr) kennt.

Die größte Aufgabe ist oft die Entwickler der Seiten für das Thema SEO zu sensibilisieren, um gemeinsam potenzielle Probleme bezüglich der Crawlbarkeit und Indexierung von vorneherein mitzudenken. Denn oft scheint die Umsetzung relevanter Punkte in solchen Seiten aufwendiger als gewöhnlich.

Neben den oben erwähnten Problemen gibt es noch zahlreiche weitere Stolpersteine zu beachten. JavaScript bringt definitiv einige Vorteile mit sich, die ihre Berechtigung haben. In Bezug auf SEO bringt diese Kombination lediglich zahlreiche Probleme und Hürden mit sich, die sowohl zeitaufwändig als auch kostspielig sind. Wer als SEO-Verantwortlicher ein Projekt mit einer Rich-JS-Website verantworten muss, sollte auf eine Server-Side-Lösung setzen.

Für herkömmliche Websites, die lediglich Content-getrieben sind, wie z. B. News-Seiten, Firmenvorstellungen oder Blogs, lohnt sich ein JS-basierter Ansatz wohl kaum.

Interessant wird es erst, wenn viele Interaktionen im User-Interface gefragt sind und die Inhalte dynamisch generiert werden. Klassische Beispiele dafür sind Dashboards jeglicher Art und datengetriebene Ansätze mit Suchfunktionen und Filtermöglichkeiten.

Bei Shops wird es schon komplizierter, denn die Vorteile eines JS-basierten User-Interfaces mit asynchronen Filterungen und Suchmechanismen sind schon sehr verlockend, aber die Produkte sollten in jedem Fall leicht und schnell zu indexieren sein.

Die Verwendung eines reinen JS-basierten Ansatzes muss immer genau mit den Bedürfnissen der Plattform abgestimmt werden und ist von daher nicht in jedem Fall empfehlenswert.

Wenn ich JavaScript einsetzen sollte, wären Progressive Web Apps mein Thema. Hier verschwimmen die Grenzen zwischen Apps und mobilen Seiten. PWAs müssten im Gegensatz zu normalen Apps nicht installiert werden. Die Inhalte wären auch bei schlechter (oder fehlender) Internetverbindung verfügbar und wären daher vorteilhaft für die User-Experience, weil sie die Vorteile mehrerer Welten vereinen. Außerdem werden Apps länger und intensiver genutzt, als vergleichbare Mobil-Seiten.

Angular, React, Vue, usw. machen vor allem Sinn, wenn es darum geht wirkliche Web-Applikationen bereitzustellen, auf denen Inhalte sehr dynamisch dargestellt werden und die stark personalisiert sind oder auf Nutzer-Interaktionen reagieren. Für solche Anwendungen schaffen die Frameworks eine flüssige und schnelle User-Experience im Browser, die an jene nativer Apps herankommt.

Man sollte daher immer abwägen, welche Features und Funktionen die geplante Website bieten soll und welcher Weg hier sinnvoll ist.