JavaScript SEO Guide

 

Webseiten die komplett mit JavaScript realisiert werden, sind im Bereich SEO immer noch ein recht unerforschtes Gebiet. Laut eigenen Aussagen Seitens Google, kann der Googlebot Inhalte von Webseiten die durch JavaScript ausgespielt werden rendern, crawlen und indexieren. Wieso diese Aussage „gefährlich“ sein kann und welche Fallstricke sich hinter dem Zusammenspiel von JavaScript-Webseiten und SEO verstecken, wird in diesem Artikel erläutert.

 

 

Können Suchmaschinen JavaScript-Webseiten crawlen und indexieren?

 

Laut offiziellen Aussagen Seitens Google kann der Googlebot JavaScript rendern, die Inhalte crawlen und indexieren. Google bestätigt immer wieder, dass der Suchmaschinen-Konzern ein gutes Verständnis dafür hat JavaScript zu rendern und die dadurch erzeugten Inhalte zu crawlen.

Leider gibt es einige Fallstudien die genau diese Aussage wiederlegen. Liegt es bei diesen Fallstudien wirklich an der mangelnden Interpretationsfähigkeit Seitens Googles oder schlichtweg an einer fehlerhaften Implementierung von JavaScript? JavaScript ist weit aus komplexer für Crawler als reines HTML. Wieso man sich auf sehr dünnes Eis begibt, wenn man JavaScript Client-Side ausspielt, wird in diesem Beitrag im Detail beleuchtet.

Abgesehen davon gibt es zum aktuellen Stand wenige Crawler die JavaScript rendern können. Crawler von anderen Suchmaschinen und sozialen Netzwerken versuchen überhaupt nicht JavaScript zu rendern und das aus einem guten Grund. Auch führende SEO-Tools sind hinsichtlich dieser Thematik noch hinterher. Wieso neben Google nur wenige JavaScript rendern und wieso sich das wohl in naher Zukunft nicht ändert, wird in diesem Beitrag erklärt.

 

Technologien von Crawlern – Wie interagiert ein Crawler mit JavaScript?

 

Um als SEO-Verantwortlicher mit JavaScript umgehen zu können, sollten ein paar wichtige JavaScript-Grundlagen und die Technologien von Crawlern bekannt sein, um die gesamte Problematik zu verstehen und sich der Risiken bewusst zu sein.

 

Wie wird JavaScript ausgeführt?

 

Abbildung 1: PHP-Rendering und JavaScript-Rendering zwischen Browser und Server

 

Zu Beginn einige Grundlagen, um das Thema in den nächsten Absätzen zu verdeutlichen. Hier einer der größten Unterschiede und gleichzeitig der Hauptgrund wieso JavaScript für Crawler eine Herausforderung darstellt. JavaScript wird nicht vom Server, sondern vom Browser (Client) ausgeführt. Ein vereinfachter Ablauf wird im Folgenden erläutert und ist in Abbildung 1 grafisch dargestellt:

 

1. Der Browser stellt eine GET-Anfrage an den Server

2. Der Server führt das PHP-Script aus (z.B. beim Einsatz eines CMS)

3. Der Server gibt den HTML-Quellcode an den Browser zurück

4. Der Browser führt das JavaScript aus

 

Bei einer Webseite ohne Einsatz von JavaScript liegt bereits nach Punkt 3 der Inhalt einer Webseite dem Browser oder einem Crawler vor. JavaScript-Code wird erst in Punkt 4 vom Browser selbst ausgeführt.

Genau hier liegt das große Problem. Damit ein Crawler Inhalte die durch JavaScript ausgeführt werden crawlen kann, muss dieser die Arbeit eines Browsers übernehmen inklusive aller nötigen Technologien und Ressourcen, wie z.B. einer Rendering-Engine. Auch Tools die beim Auditing unterstützend helfen, müssen über diese Technologien verfügen um valide Daten zu liefern.

 

Quellcode vor und nach dem Rendern

 

Abbildung 2: Einblick in den Quellcode vor und nach dem Rendern von JavaScript

 

Mit einem Blick auf den Quellcode einer JavaScript-Basierenden Webseite, wird schnell deutlich, dass die vom Browser angezeigten Inhalte im Quellcode nicht zu sehen sind. Das liegt daran, dass kein JavaScript ausgeführt wurde, also der DOM der Webseite nicht gerendert wurde. Erst nachdem JavaScript ausgeführt wird, werden alle Inhalte auch im Quellcode sichtbar.

In der linken Spalte in Abbildung 2 ist der Quellcode einer JavaScript-Basierenden Webseite zu sehen. Hier ist gut zu erkennen, dass im Quellcode keinerlei Inhalte zu sehen sind. In der rechten Spalte wurde JavaScript bereits ausgeführt, daher sind hier alle Inhalte die im Browser zu sehen sind auch im Body-Bereich des gerenderten Quellcodes vorhanden.

 

Headless-Browser – Wie interagiert ein Crawler mit einer Webseite?

 
Abbildung 3: Grundprinzipien eines Headless-Browsers an Hand von Headless Chrome
 

Um vereinfacht darzustellen, wie ein Crawler mit einer Webseite interagiert, wird der Crawler wie einen Headless-Browser betrachtet.
Ein Headless-Browser beschreibt relativ genau, wie der Googlebot mit einer JavaScript-Basierenden Webseite interagiert, deswegen ist es hilfreich zu verstehen, wie ein Headless-Browser arbeitet.

Ein Headless-Browser ist ein Browser ohne visuelle Komponenten. Das bedeutet, dass ein Headless-Browser keine Inhalte darstellt um mit diesen wie ein Webseitenbesucher zu interagieren. Dieser interagiert mittels Befehlen mit einer Webseite.

Um die Arbeitsweise eines Headless-Browser einfacher zu verdeutlichen, wurde der Headless-Mode des Google Chrome Browser genutzt. Der Headless-Mode ist seit der Version 59 für Mac OS und Linux und seit der Version 61 für Windows verfügbar. Laut Spekulationen wurde der Headless Chrome für den Googebot entwickelt.

Um den Headless Chrome (Headless Mode von Google Chrome) nutzen zu können, genügt die Konsole bei Windows bzw. das Terminal bei Mac OS. In Abbildung 3 sind einfache Befehle verwendet worden, um den Headless Chrome zu steuern.

In Zeile 1 wurde lediglich der Pfad der Installation von Google Chrome hinterlegt um mit dem Befehl „chrome“ direkt auf den Browser zugreifen zu können. Zeile 5 kann folgend interpretiert werden:

 

1. Chome: Zugriff auf den Google Chrome Browser

2. –headless: Google Chrome im Headless-Mode ausführen

3. –disable-gpu: Dieser Befehl ist laut Google aktuell nur wegen eines Problems notwendig

4. –dump-dom: Ausgeben des DOM

5. Url:Diese Url wird für den Befehl angesteuert

 

Nach der Eingabe dieser Befehle liest der Headless Chrome den DOM der angegebenen Webseite aus und gibt diesen direkt in der Konsole bzw. Terminal aus. Der DOM kann danach beliebig in ein Textprogramm eingefügt und analysiert werden.

Zur Verdeutlichung wurden noch weitere Befehle ausgeführt. In Zeile 8 wird der Headless Chrome die angegebene Webseite als PDF speichern. Ab Zeile 9 wird von der Webseite ein Screenshot der Webseite, je nach Wahl der Pixel-Größe, erstellen und gespeichern.

Vereinfacht sollen dieses Befehle verdeutlichen, wie ein Crawler sich durch die Webseite arbeitet.

 

Googlebot Rendering – Welche Technologien nutzt der Googlebot um Webseiten zu rendern?

 

Abbildung 4: Welche Technologien nutzt der GoogleBot um Webseiten zu rendern

 

Erst im August 2017 wurden von Google tiefere Einblicke in die Technologie beim Rendern von Webseiten des Googlebots veröffentlicht. Bis Dato war über das Rendering des Googlebots kaum etwas bekannt und lediglich die Google Search Console diente als valide Quelle für Debugging und Testing.

Laut diesem Dokument nutzt der Googlebot den Web Rendering Service (WRS) welcher auf dem Google Chrome 41 basiert, um Webseiten zu rendern. Diese Version des Google Chrome Browsers stammt aus dem Jahr 2015 und verfügt etwa über 60% der Technologien und Features der aktuellen Chrome Version. Laut Aussagen von Google, soll die Technologie zum rendern von Webseiten des Googlebots im Jahr 2018 aktualisiert werden.

Diese Aussage ist für das Thema JavaScript SEO sehr interessant. Dadurch kann der Google Chrome in der Version 41 als valides Tool für Debugging und Testing von JavaScript verwendet werden. Den Google Chrome in der Version 41 gibt es hier direkt bei Google zum Download.

Google ist laut eigenen Aussagen dran, die Rendering-Engine an die aktuelle Chrome-Version anzupassen. Erste Tests von DeepCrawl zeigen, dass Google testweise Features der aktuellen Chrome-Version für den Googlebot nutzen.

Des Weiteren ist bekannt, dass der Googlebot das Transfer Protokoll HTTP/2 aktuell nicht unterstützt. Da HTTP/2 Abwärtskompatibel ist, sollte dies keine Probleme darstellen. Zudem gibt es keine Unterstützung für WebSocket-Protokoll, IndexedDB und WebSQL-Interfaces zur Datenhaltung im Browser.

Inhalte die erst nach Zustimmung des Users angezeigt werden, werden ebenfalls nicht indexiert. Interessant ist auch die Information, dass Inhalte des Local Storages sowie Session Storages gelöscht werden und beim Aufruf einer neuen Url HTTP-Cookies gelöscht werden.

Solange Googlebot lediglich die Features vom Chrome 41 nutzt, müssen diese Einschränkungen bei der Implementierung von JavaScript berücksichtigt werden. Welche Unterschiede es zwischen der Version 41 und aktuellen Version gibt, zeigt Caniuse.com und Chrome Platform Status deutlich.

 

Google Caffeine (Indexer) ist für das Rendering zuständig

 

Vermehrt herrscht die Meinung, dass der Crawler, bei Google ist es der Googlebot, für das Rendern von JavaScript verantwortlich ist. Dies ist aber ein Fehlglaube. Das Rendern von JavaScript übernimmt erst der Indexer, bei Google ist es Caffeine. Genauer gesagt, ist es der Web Rendering Service (WRS), der ein Teil von Caffeine ist. Genauso wie der PageRanker ein Teil von Caffeine ist. Mehr zu den Technologien die Google für das Rendern von JavaScript nutzt, werden weiter im Artikel erläutert.

 

 

Rendering von JavaScript vs. HTML

 

Um sich über die Herausforderungen, vor denen Suchmaschinen beim Crawlen und Indexieren von JavaScript-Inhalten stehen, bewusst zu sein, ist es wichtig zu verstehen, wie der Ablauf einer Suchmaschine beim Crawlen und Indexieren von Html-Webseiten im Vergleich zu JavaScript-Webseiten aussieht. Der folgende Ablauf dient als vereinfachte Darstellung.

 

Ablauf beim Crawlen von Html-Inhalten

 

1. HTML-Dateien werden runtergeladen

2. Links werden aus dem Quellcode entnommen und können gecrawlt werden

3. CSS-Dateien werden runtergeladen

4. Googlebot (Crawler) sendet alle Ressourcen zu Caffeine (Indexer)

5. Googlebot sendet alle Ressourcen zu Caffeine

 

Dieser Prozess kann einem Ablauf abgeschlossen werden. Das bedeutet, nach dem der Crawler seine Schritte absolviert hat, werden die weiteren Arbeitsabläufe an den Indexer übergeben. Wenn dieser fertig ist, ist der Ablauf abgeschlossen bis der Crawler die Webseite erneut besucht.

 

Ablauf beim Crawlen von JavaScript-Inhalten

 

1. HTML-Dateien werden runtergeladen

2. CSS- und JavaScript-Daten werden parallel runterladen

3. WRS (Web Rendering Service) wird genutzt (Teil von Caffeine) um JS auszuführen

4. WRS rendert alle Dateien

5. Caffeine kann nun die Inhalte ggf. indexieren

6. Erst jetzt kann Googlebot neue Links crawlen

 

Der große Nachteil bei diesem Ablauf ist, dass dieser für jede einzelne Url wiederholt werden muss, da der Indexer erst JavaScript rendern muss, um an die weiteren links zu kommen, die der Crawler dann besuchen kann. Hier entsteht für die Suchmaschinen also nicht nur der Aufwand des Rendern von JavaScript, sondern auch beim Crawlen ist der Prozess sehr umständlich.

 

Second Wave of Indexing

 

Abbildung 5: Second Wave of Indexing – Google I/O 2018
 

Google selbst spricht hier von „Second Wave of Indexing“. Hierbei wird erklärt, dass beim ersten Besuch (Crawl) das „Instant, first wave of indexing“ stattfindet. Es werden alle Inhalte direkt indexiert, ohne Rendering überhaupt anzuwenden. Was für Rich-JS-Webseiten fatal sein kann. Besonders wenn sich Inhalte oft ändern und aktuell sein müssen. Erst beim zweiten Besuch wird gerendert. Zwischen dem ersten und zweiten Besuch können aber auch mal ein paar Tage bis Wochen liegen, Zitat von Googles John Müller auf Twitter:

 

Yeah, there's no fixed timeframe — the rendering can happen fairly quickly in some cases, but usually it's on the order of days to a few weeks even. If your site produces new / updated content frequently & you want it indexed quickly, you need that content in the HTML.

— 🍌 John 🍌 (@JohnMu) 13. September 2018

 

Googlebot vs. Google Search Console Bot

 

Abbildung 6: Abrufen und Rendern mit dem Googlebot und dem Google Search Console Bot

 

Da von Google offiziell bestätig wurde, dass der Googlebot den WRS des Google Chromes 41 nutzt, war es interessant zu erfahren, wo der Unterschied zwschen dem bereits abgeschaften „Fetch and Render Tool“ der Google Search Console und dem Googlbot liegt.

Nach einem Blick auf die LogFiles ist zu sehen, dass der Googlebot, wie erwartet als Googlebot2.1 die Webseite besucht. Die Google Search Console hingegen besucht die Webseite als Chrome/41.0.2272.118 (zusehen in Abbildung 6).

Das bedeutet, dass sowohl der Googlebot, als auch die Google Search Console dieselbe Technologie zum Rendern von Webseiten nutzen. Wo liegt nun der Unterschied? Aktuell ist der einzige bekannte Unterschied, dass der Google Search Console Bot die Robots.txt gänzlich ignoriert.

Vermerk: Das „Fetch and Render Tool“ wurde bereits vom „Url-Prüfen-Tool“ abgelöst. Hinsichtlich dieses Tests ändern sich die Erkenntnisse aber nicht.

 

Umgang unterschiedlicher Suchmaschinen mit JavaScript – Google ist nicht alles!

 

Abbildung 7: Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?

 

Google nutzt also eine Rendering-Engine für JavaScript- Wie sieht es aber mit anderen Suchmaschinen aus? Um diese Frage zu beantworten, hat der geschätzte Kollege Bartosz Góralwicz ein interessantes Experiment durchgeführt. Das Ziel des Experimentes war es, herauszufinden, wie Crawler mit welchen JavaScript-Frameworks umgehen können. Interessant zu sehen ist, dass bis auf Google (Ask bassiert auf Google) keine andere Suchmaschine in der Lage ist JavaScript zu rendern.

Abgesehen von diesem Experiment ist auch bekannt, dass Crawler von Facebook, Twitter, LinkedIn oder Xing aktuell auch kein JavaScript rendern. Nach dieser Erkenntnis werden lediglich die Technologien des Googlebots für die Interaktion mit JavaScript betrachtet.

Mit einer Server-Side gerednerten Rich-JS-Webstte schließt man alle anderen Suchmaschinen und soziale Netzwerke aktuelle aus!

 

Bing JavaScript SEO – Kann Bing JavaScript?

 

Berüchten zu folge scheint Bing lediglich bei großen Webseiten JavaScript zu rendern. Diese Aussage konnte lange Zeit nicht bestätigt werden. Der geschätzer Kollege Dan Patrovic hat auf Twitter gezeigt, dass die Webseite lendi.com die JavaScript Server-Side ausspielt von der Suchmaschine von Microsoft indexierte Inhalte aufweist.

 

Crawling und Indexierung von verschiedenen JavaScript-Frameworks

 

Abbildung 8: Wie crawlt und indexiert der Googlebot verschiedene JavaScript-Frameworks?

 

Um nochmals auf das Experiment von Bartosz Góralewisz zurückzukommen, wurde zwar festgestellt, dass Google aktuell die einzige Suchmaschine ist, die einen Crawler ins Rennen schickt, der auch JavaScript rendern kann, sich aber bei verschiedenen JavaScript-Frameworks auch unterschiedlich verhält.

Besonders bei extern aufgerufenen JavaScript hat der Crawler laut diesem Experiment Probleme Urls zu crawlen und diese zu besuchen. Deswegen kann davon ausgegangen werden, dass der Einsatz von Inline-JS die bessere Variante ist JavaScript zu implementieren, was gegen eine saubere Architektur spricht.

 

Fehler im Angular JS 2 Framework führte zu Crawling-Problemen

 

Abbildung 9: Ein Fehler im Angular JS 2 Framework führte zu Indexierungsproblemen seitens Google

 

Besonders die Ergebnisse beim Angular JS 2 Framework hat viele Fragen aufgeworfen. Google hat Probleme ihr eigenes Framework zu crawlen? Nach langen Überlegungen konnte diese Frage aufgeklärt werden: Ein einfacher Fehler im Framework hat dazu geführt, dass Google selbst Probleme bei der Indexierung hatte. Nach eigenen Angaben von Google, wurde dieser Fehler am 26. April 2017 behoben, was die Indexierung des Angular JS 2 Frameworks ermöglichte. Dies ist ein weiteres Beispiel dafür, wie fehleranfällig JavaScript-Frameworks sind, wenn es um die Crawlbarkeit und Indexierbarkeit geht.

 

JavaScript Rendering ist Ressourcenintensiv

 

Abbildung 10: JavaScript Rendering Performance
 

Ein wichtiger Punkt beim Rendern von JavaScript ist, dass dieser wie bereits vom Browser gerendert wird. der Browser greift für das Rendern auf die Hardware des Rechners, besonders auf die CPU. Was bedeutet, dass Rich-JS-Webseiten auf leistungsstarken Rechnern schneller lädt, als auf älteren schwächeren CPUs.

Diese Rechenleistung müssen Suchmaschinenkonzerne mitberücksichten, um JavaScript zu rendern. Diese Rechenleistung kostet natürlich mehr Geld als bei herkömmlichen HTML-Webseiten. Für Google ist es mit dem enormen Marktanteil keine große Schwierigkeit diese Rechenleistung, auch wenn nur limitiert, zu Verfügung zu stellen.

Konkurrenten wie Bing oder andere Suchmaschinen haben mit Ihrem nur sehr geringen Marktanteil nicht die nötigen Mittel um eigenes Rendering von JavaScript anzubieten. Man spricht davon, dass eine JavaScript-Website im Vergleich zu einer HTML-Webseite von gleicher größe etwa das hundertfache an Ressourcen benötigt um gerendert zu werden.

Aus diesem Grund ist es sehr unwahrscheinlich, dass andere Suchmaschinen mit eigenen Rendering-Engines nachziehen werden.

 

Zusammenfassung – Crawler-Interaktion mit JavaScript

 

Um auf den nächsten Abschnitt dieses Beitrages zu Blicken, lohnt sich eine kurze Zusammenfassung der bis hier erläuterten Erkenntnisse:

 

1. JavaScript wird vom Browser ausgeführt, nicht vom Server. Diese Aufgabe (rendern) muss der Crawler übernehmen, um Inhalte die durch JavaScript ausgeführt werden zu crawlen und zu indexieren.

2. Ein Headless-Browser beschreibt relativ genau, wie ein Crawler mit einer Webseite interagiert.

3. Der Googlebot verwendet zum Rendern von Webseiten den Web Rendering Service (WRS) welches auf dem Google Chrome Browser Version 41 basiert. Google arbeitet bereits an einem Upate

4. Features und Technologien des Googlebots sind damit auf dem Stand vom Jahr 2015

5. Der Google Chrome 41 kann neben dem „Url-Prüfen“-Tool der Google Search Console für Debugging und Testing von JavaScript verwendet werden.

6. Das HTTP/2 Transfer Protokoll wird nicht unterstützt. Da es aber abwärtskompatibel ist, sollte es kein Problem darstellen.

7. WebSocket-Protokoll, IndexedDB und WebSQL- Interfaces werden nicht unterstützt.

8. Der Googlebot interagiert unterschiedlich mit verschiedenen JavaScript-Frameworks.

9. Bis auf Google, rendert kein anderer Suchmaschinen-Crawler JavaScript.

10. Googles Indexer (Caffein) ist für das Rendering geantwortlich, nicht der Crawler (Googlebot)

11. Google rendert beim ersten Besuch einer Url JavaScript nicht, sondern Indexiert alles was ohne Rendering vorhanden ist.

12. Lediglich Google rendert JavaScript. Andere Crawler von Suchmaschinen oder sozialen Netzwerken nicht.

13. Das Rendern von JavaScript ist auch für Google Ressourcenintensiv

 

SEO-Auditing-Tools für JavaScript-Webseiten

 

Da nun die Grundprinzipien von JavaScript und die dadurch entstehenden Schwierigkeiten bezüglich SEO bekannt sind, geht es in diesem Teil um hilfreiche Tools von Google aber auch externe Anbieter um JavaScript und SEO unter einen Hut zu bekommen.

 

Google Chrome Browser 41 (Chromium) – Aktullen Stand von Google verwenden

 

Abbildung 11: Auditing von JavaScript-Webseiten mit Chrome 41

 

Wie bereits erwähnt, dient Googles eigener Browser, Chrome in der Version 41, zum Testing von JavaScript-Webseiten. Hierbei sollte beachtet werden, dass Features, die neuer als der Chrome 41 sind, von Google (Caffeines WRS) nicht ausgeführt werden können. Hierbei sollte immer darauf geachtet werden, welche Fehler vom Chrome Developer ausgeworfen werden und dieses korrigieren. Für den Umgang und weitere Einblicke in die Technologien und Features des Chrome 41 ist caniuse.com und Chrome Platform Status sehr nützlich. Grundsätzlich sollte der Browser genutzt werden, der auf den Technologien und Featers vom Googlebot basiert um JavaScript für SEO zu testen.

 

Chrome Developer Tools – Auditing vom gerenderten Quellcode

 

Abbildung 12: Gerenderten Quellcode einsehen und analysieren

 

Um JavaScript-Basierende Webseiten für SEO zu analysieren, muss nur ein kleiner Teil von JavaScript betrachtet werden. Im folgenden Abschnitt wird vereinfacht dargestellt, was passiert, wenn der Googlebot eine JavaScript-Basierende Webseite besucht.

Um diesen Ablauf zu simulieren, wird das integrierte Developer Tool im Google Chrome Browser genutzt.

 

1. In einen „leeren Bereich“ der Webseite rechts-klicken und „Untersuchen“ auswählen

2. Um den gesamten Inhalt zu erhalten, den HTML-Tag im rechten Bereich des Browsers auswählen

3. Mit einem Rechtsklick auf den HTML-Tag auf „Copy“ und „Copy OuterHTML“ navigieren um den gesamten Inhalt zu kopieren

4. Der kopierte HTML-Code kann nun in Textprogramm eingefügt werden, um den Inhalt einzusehen und zu analysieren

 

Dieser Vorgang kann auch verwendet werden, um den Inhalt einer JavaScript-Basierenden Webseite auf OnPage-Faktoren zu überprüfen.

 

Google Search Console – Url-Prüfungs-Tool

 

Abbildung 13: Url-Prüfungs-Tool – Google Search Console

 

Naheliegend ist es natürlich, das „Url-Prüfungs-Tool“ der Google Search Console zu nutzen. Sehr hilfreich ist hier der Live-Test des Url-Prüfungs-Tools. Neben dem gerenderten HTML-Code und einem Screenshot von der gerenderten Webseite erhält man weitere Informationen, die vorallem für das Handling mit JavaScript sehr hilfreich sein können.

Hierbei sollte aber darauf geachtet werden, dass das Tool der Google Search Console lediglich Auskünfte darüber gibt, ob eine Webseite technisch gerendert werden kann oder bezüglich JavaScript Probleme beim crawlen auftreten. Timeouts und Performance-Ansprüche des GoogleBots werden hier nicht berücksichtigt.

Deswegen ist es immer zu Empfehlen eine Site-Abfrage inkl. Ausschnitt des zu überprüfenden Textes zu starten, um wirklich sicher zu gehen.

 

Site-Abfrage in der Google-Suche – Google Index überprüfen

 

Abbildung 14: Site-Abfrage mit Text Auszug in der Google-Suche um zu testen ob Inhalte indexiert werden können
 

Um wirklich sicher gehen zu können, ob Inhalte gecrawlt und indexiert werden können, ist eine Site-Abfrage notwendig. Hierfür kann folgende Suchanfrage genutzt werden:

Site:deinedomain.de/deineseite „Zu testender Textauszug“

Auch wenn eine Url im Index ist, bedeutet es nicht, dass alle Inhalte einwandfrei indexiert wurden. Nur mit der Site-Abfrage in der Google Suche kann zu 100% sichergestellt werden, ob Google die Inhalte indexiert.

 

Google Mobile Friendly Tester – Von Google gerenderter Code

 

Abbildung 15: Betrachtung des DOM mit dem Google Mobile Friendly Tester

 

Vor der Einführung des „Url-Überprüfungs-Tool“ wurde der „Mobile Friendly Tester“ empfohlen, da laut eigenen Aussagen von Google (John Mueller) das bereits abgeschafte Fetch and Render Tool der Google Search Console einige Schwächen aufwies, wenn es um die Betrachtung des DOM geht. Deswegen wurde der Mobile Friendly Tester oder der Google Rich Media Tester empfohlen. Veränderungen die durch JavaScript am DOM nachträglich vorgenommen oder CSS-Anweisungen die z.B. durch Resizing verursacht werden, können mit dem Mobile Friendly Tester dargestellt werden.

Dank des „Url-Überprüfungs-Tool“ der Google Search Console ist der „Mobile Friendly Tester“ nicht unbedingt notwendig, kann aber auch zusätzlich genutzt werden. Interessant ist dieses Tool vorallem, um sich externe Seiten anzuschauen, deren Google Search Console Zugang nicht vorhanden ist.

 

Screaming Frog SEO Spider

 

Abbildung 16: Der Einsatz des Screaming Frog SEO Spider zum rendern von JavaScript-Webseiten

 

Eine Hilfestellung bietet der Screaming Frog SEO Spider. Dieser Crawler bietet bereits die Funktion, JavaScript zu rendern und erstellt ähnlich wie der Googlebot einen Screenshot der Webseite nach dem Load-Event.

Unter dem Menüpunkt „Configuration » Spider » Rendering“ kann hier der Punkt „JavaScript“ ausgewählt werden. Nach dem erfolgreichen crawlen der Webseite kann jede URL als „Rendered Page“ betrachtet werden. Dieser Screenshot kann bereits erste Aufschlüsse darüber geben, ob es Probleme beim Rendern der Webseite gibt. Zu beachten ist, dass diese Funktion lediglich in der Paid-Version des Screaming Frog SEO Spiders verfügbar ist.

Obwohl sich der Sreaming Frog SEO Spider ähnlich die der Googlebot verhält, ist leider damit nicht gewährleistet, ob der Googlebot exakt so verfährt und diese Seite genauso gerendert wird.

Des Weiteren ist vom Screaming Frog SEO Spider bekannt, dass dieser zwar die Rendering-Engine „Blink“ vom Chromium Project nutzt, diese sich aber von der des Googelbots (WRS) unterscheidet. Außerdem benötigt das Rendern (inkl. AJAX Timeout von 5 Sekunden) von JavaScript mit dem Screaming Frog SEO Spider große Ressourcen, was das Crawlen von JavaScript-Seiten mit mehr als 100.000 Urls quasi unmöglich macht.

 

Ryte Business Suite – Vorstellung inkl. Interview mit Marcus Tandler

 

Abbildung 17: Ryte Business Suite – High-Performance Crawler mit JavaScript-Crawling

 

Ryte bietet in der Business Suite für Ihre Kunden ebenfalls die Möglichkeit, Webseiten mit dem High-Performance Crawler mit JavaScript Crawling zu analysieren. Ryte nutzt beim Crawling den Google Chrome und versucht immer möglichst nah an der neusten Version zu bleiben. Dies ist natürlich bei Rich-JS-Webseiten sehr hilfreich um eine ausführliche OnPage-Analyse zu bekommen, da ohne JavaScript-Crawling der Crawler nicht sehen könnte.

 

Abbildung 18: Ryte Business Suite – Erweiterte Anaylse-Einstellingen für JavaScript-Crawling

 

Wir haben das große Glück den CO-Founder und Co-Geschäftsführer persönlich zu kennen, der wohl am besten erklären kann was der neue Ryte High-Performance Crawler mit JavaScript Crawling drauf hat:

 

Hallo Marcus, super, dass du Zeit gefunden hast, um uns ein paar Fragen zu eurem neuen JS-Crawler zu beantworten. Stell dich doch bitte kurz vor, wer du bist und was du bei Ryte machst.

Hallo, ich bin Marcus und ich liebe SEO 🙂
Ich bin Co-Gründer und Co-Geschäftsführer von Ryte und neben meinen Aufgaben als Geschäftsführer bin ich vor allem auch SEO Sparringspartner für unsere aktiven und potentiellen Business Suite Kunden.

 

Welche Rendering-Engine nutzt ihr um JavaScript auszuführen und wird es in Zukunft auch eine Funktion geben, um zwischen unterschiedlichen Engines zu wechseln?

Wir verwenden Google Chrome und versuchen immer möglichst nah an der neuesten Version zu bleiben. Der Wechsel der Engines ist nicht möglich und auch derzeit nicht geplant. Aber komplett ausgeschlossen ist es natürlich auch nicht.

 

Euer JS-Crawler hat etwas auf sich warten lassen. Welche Herausforderungen bzw. Ansprüche hatte ihr besonders an euren Crawler, wenn es um das Rendering von JavaScript geht?

Unsere Ansprüche haben wir für uns von Anfang an klar formuliert:
1) Stabil
2) Skalierbar
3) Wirtschaftlich
4) Unabhängig vom JavaScript Framework
5) Ergebnisse wie ein moderner Browser ausgeben
6) Kein “3rd party rendering”
7) Hohe Performance

Die Herausforderungen für uns sahen dabei folgendermaßen aus:
1) Welche Engine verwenden wir?
Die Engine sollte möglichst nah an einem Browser sein, sollte alle JavaScript Frameworks unterstützen, möglichst performant und durch Software steuerbar sein. Hier waren wir mit viel Recherche und Prototyping konfrontiert.
2) Wie können wir verteilt (distributed), skalierbar (scaleable) und belastbar (resilient) bauen und trotzdem wirtschaftlich bleiben?
3) Wie kann man die Ressourcennutzung (RAM, CPU) von Chrome reduzieren?
4) JavaScript an sich ist eine große Herausforderung, da es viele Probleme gibt, die man nur durch Testen herausfinden kann. Ein kurzes Beispiel: Wie behandelt man window.location Änderungen ohne Informationen zu verlieren? Viele dieser Fragestellungen sind initial gar nicht unbedingt auf der Agenda bis sie dann zum ersten Mal tatsächlich auftreten.
5) Die Ladezeiten von JavaScript Seiten sorgen für einen lang andauernden Crawl. Hier galt es, möglichst schnell unterwegs zu sein, um von Anfang an eine hohe Performance aufzuweisen.

 

Für wie wichtig haltet ihr es, dass euer Crawler so nah wie möglich an der Technologie von Google angelehnt ist, um Webseiten zu crawlen?

Google ist schlichtweg die bedeutendste Suchmaschine für unsere Zielmärkte. Damit macht es natürlich Sinn, sich technologisch an Google zu orientieren. Darüber hinaus hat Google auch für unser Tool eine hohe Bedeutung, da wir auf den Einsatz von 100% echten Google Daten setzen, um die Suchrealität abbilden zu können.

 

Kannst du jetzt schon etwas zu kommenden Features rund um das Thema JavaScript SEO für Ryte erzählen?

Wir planen keine expliziten JavaScript Features in den nächsten Monaten. Was wir aber berücksichtigen werden, sind Features, die auf Basis des Rendering umsetzbar sind. Wir haben da eine Menge spannender, neuartiger Ideen 🙂

Don’t just do it. Do it Ryte!

 

Danke, dass du dir die Zeit genommen hast, unsere Fragen zu beantworten. Wir freuen uns auf die weitere Entwicklung eurer Produkte.

 

Searchmetrics Suite – Vorstellung inkl. Interview mit Malte Landwehr

 

Abbildung 19: Searchmetrics Suite – Chrome- und PhantomJS-basiertes JavaScript-Crawling
 

Die Searchmetrics Suite bietet mit der Site-Optimization ein JavaScript-Crawling an, welches auf dem Chrome 41 und PhantomJS basiert. Damit bietet dieses Tool ein praktisches Werkzeug um SEO-Verantwortlichen die Arbeit zu erleichtern. Wir durften uns das Tool bereits anschauen und ausgiebig testen. Bei den Crawling-Einstellungen kann bereits gewählt werden, ob der Crawler JavaScript mitberücksichtigen soll. Da Searchmetrics bei diesem Crawl JavaScript ausführt, kann die Webseite hinsichtlich OnPage-Faktoren wie jede herkömmliche Webseite betrachtet werden, was einen große Hilfe für SEO-Verantwortliche bietet.

 

Abbildung 20: Searchmetrics Suite – Crawler Einstellungen

 

Freundlicherweise stand uns der Director für Product Marketing & Solutions, Malte Landwehr für ein kurzes Interview zur Verfügung, um unsere Fragen zu Searchmetrics JavaScript-Crawler zu beantworten:

 

Hallo Malte, super, dass du Zeit gefunden hast, um uns ein paar Fragen zu eurem neuen JS-Crawler zu beantworten. Stell dich doch bitte kurz vor, wer du bist und was du bei Searchmetrics machst.

Ich leite bei Searchmetrics die Bereiche Product Marketing und Product Solutions. Mein Team sorgt dafür, dass wir in der Produktentwicklung an den richtigen Themen arbeiten und dass unsere Kunden maximal von unseren Softwareinnovationen profitieren.

Und dann beschäftigen wir uns noch mit einer Million anderer Dinge wie Go-to-Market-Strategien, Release-Management, Pricing, Packaging, Sales Collateral, RFPs, usw.

Ich selbst wurschtel seit mehr als 10 Jahren im Online Marketing rum. Anfangs als Hobby, dann als Affiliate, Blogger und Freelancer. Dann war ich noch CoFounder einer SEO-Agentur in Münster und auf Kreta und hatte einen kurzen Ausflug in die Wissenschaft als ich mich für die Uni Münster, IBM, die DFG, die Vodafone Stiftung und die Konrad Adenauer Stiftung mit Social Network Analysis und dem politischen Diskurs auf Twitter beschäftigt habe. Zuletzt war ich Unternehmensberater und bin jetzt seit fast drei 3 Jahren bei Searchmetrics.

Wenn ich mich mal nicht mit SEO beschäftige, gehe ich meiner Kindle- und Netflix-Sucht nach.

 

Wieso ist es eurer Meinung nach beim Crawlen von Webseiten wichtig, auch JavaScript zu rendern?

JavaScript erlaubt es Websites mit viel besserer User-Experience zu erstellen als dies mit reinem HTML und CSS der Fall ist. Fast alle modernen Websites basieren heute auf Angular, React oder einem der vielen anderen JavaScript-Frameworks. Aus der modernen Webentwicklung ist JavaScript einfach nicht mehr wegzudenken.

Da auch Google JavaScript teilweise versteht, ist es wichtig bei der SEO-Bewertung von Websites auch DOM-Änderungen zu berücksichtigen, die nicht im puren HTML-Code stehen sondern durch JavaScript ausgelöst werden. Wenn eine Website via JavaScript den Title-Tag ändert und Inhalte nachlädt – und dies auf eine Art und Weise tut, die der Google Bot versteht – dann muss auch ein SEO-Crawler diese Änderungen verstehen um eine realistische SEO-Bewertung abzugeben.

 

Welche Rendering-Engine nutzt ihr um JavaScript auszuführen und wird es in Zukunft auch eine Funktion geben, um zwischen unterschiedlichen Engines zu wechseln?

Wir arbeiten mit Chrome und PhantomJS. Chrome ist natürlich näher am Google Bot, der aktuell auf Chrome 41 basiert. PhantomJS hat den Vorteil, dass sich damit auch Websites crawlen lassen, mit denen Chrome 41 nicht klar kommt.

Da wir als agile Software Company nicht mit starren Roadmaps arbeiten, spreche ich ungern über eventuelle zukünftige Funktionen. Ich kann so viel verraten: JavaScript-Crawling ist ein sehr wichtiges Thema für uns und wir machen uns intensiv Gedanken was für unsere Kunden am besten ist.

 

Für wie wichtig haltet ihr es, dass euer Crawler so nah wie möglich an der Technologie von Google angelehnt ist, um Webseiten zu crawlen?

Das halte ich für absolut essentiell um Kunden genau aufzeigen zu können, wie gut ihre Website für Google optimiert ist.

Allerdings geht unser Crawling-Anspruch etwas weiter als nur die Optimierung für Suchmaschinen. Kaputte Links können eine Auswirkung auf die User Experience haben. Für eine JavaScript-lastige Shopping-Website kann es also durchaus ein Mehrwert sein, wenn wir die Seite wie ein Mensch crawlen und nicht wie Google.

 

Nach offiziellen Aussagen der Suchmaschinen-Konzerne, ist aktuelle nur Google in der Lage, JavaScript zu rendern. Sobald andere Suchmaschinen nachziehen, werden diese sicherlich ihre eigenen Technologien einsetzen. Wie weit wird das in eurem Crawler mitberücksichtigt werden, wenn es soweit ist?

Wir unterstützen aktuell in der Searchmetrics Suite ein knappes Dutzend Suchmaschinen. Neben Google, Yahoo, Baidu und Yandex auch so Exoten wie Qihoo 360 und Sogou. In Amerika und Europa ist aber für eigentlich jeden Kunden Google das Maß der Dinge. Die meisten SEOs die ich kenne, prüfen nie wie Bing und Yahoo mit Noindex, Nofollow oder der robots.txt umgehen. An diesem Google-Fokus wird meiner Meinung nach auch JavaScript-Crawling nichts ändern.

Da Microsoft hochwertige Progressive Web Apps über den Bing Crawler aufspüren und über den Microsoft Store direkt in Windows verfügbar machen möchte, werden wir sicher in Zukunft deutlich mehr JavaScript Crawling aus dem Hause Microsoft sehen. Und damit wird das Thema JavaScript-Crawling/PWA-Crawling dann auch deutlich über den SEO-Tellerrand hinaus spannend! Denn es ist vermutlich nicht der Head of SEO, der sich damit befasst ob die eigene PWA gut in Windows 10 funktioniert und wie sie im Windows Store gelistet wird.

 

Danke, dass du dir die Zeit genommen hast, unsere Fragen zu beantworten und vielen Dank, dass wir euren Crawler ausgiebig testen durften. Wir freuen uns auf die weitere Entwicklung eurer Produkte.

 

Zusammenfassung – SEO-Auditing-Tools für JavaScript Webseiten

 

Um auf den nächsten Abschnitt dieses Beitrages zu Blicken, lohnt sich eine kurze Zusammenfassung der bis hier erläuterten Erkenntnisse:

 

1. Mit dem Google Chrome Browser in der Version 41 werden Webseiten mit den selben Features gerendert. Damit ein sehr wichtiges Testing-Tool

2. Die Chrome Developer Tools ermöglichen den gerenderten Code darzustellen und Fehler beim Rendering zu identifizieren

3. Der Live-Test im „Url-Überprüfen“-Tool hilft beim Auditing von Fehlern und zur Betrachtung des von Google gerenderten Code

4. Lediglich eine Site-Abfrage in dern Google-Suche gibt valide Aussagen ob Inhalte indexiert wurden

5. Neben der Google Search Console dient Googles Mobile Friendly Tester als Audting-Tool. Besonders bei externen Webseiten ohne Zugriff auf die GSC

6. Der Screaming Frog SEO Spider mit einer eigenen Rendering Engine eigenet sich gut für kleinere Webseiten

7. Mit dem Ryte High-Performance Crawler mit JavaScript Cralwing können auch OnPage-Analysen erstellt werden, trotz Client-Side-Rendering JavaScript

8. Searchmetrics bietet in ihrer Suite ebenfalls die Möglichkeit Webseiten mit Client-Side-Rendering JavaScript zu crawlen

 

 

Best Practices Empfehlungen von Google zu JavaScript SEO

 

Im Folgenden werden die wichtigsten Empfehlungen und Best Practice Beispiele erklärt, um JavaScript und SEO am besten zu verheiraten. Viele der Tipps stammen direkt von Google und sollen helfen grobe Fehler zu vermeiden

 

Umgang mit dynamischen Inhalten

 

Abbildung 21: Load Event und User Event für die Verwendung von wichtigen Inhalten

 

Da Google den gerenderten Quellcode direkt nach dem Load-Event crawlt, werden alle dynamischen Inhalte die während bzw. nach einem User-Event geladen werden, gänzlich ignoriert. Der Load-Event ist beendet, wenn die Seite komplett geladen wurde. Hierbei sollte beachtet werden, dass der Googlebot nach etwa 5 Sekunden einen Screenshot der Webseite erstellt. Alle wichtigen Inhalte sollten in dieser Zwischenzeit geladen sein.

User-Events führen dazu, dass JavaScript den Quellcode einer Webseite verändert. Dies kann ebenfalls mit dem integrierten Developer Tool im Google Chrome Browser simuliert und veranschaulicht werden. Ein User-Event kann z.B. ein Klick (onClick) auf einen Tab sein, der weitere Inhalte zum Vorschein bringt. Aus diesem Grund ist es wichtig, dass alle wichtigen Inhalte die von Google gecrawlt werden sollen, auf der Seite dargestellt werden, ohne das eine Interaktion des Webseitenbesuchers notwendig ist.

Es konnte weiter beobachtet werden, dass Google auch Inhalte indexiert, die erst durch ein User-Event erstellt werden. Der Grund dafür kann sein, dass ein Headless-Browser auch durch Befehle mit der Webseite interagieren kann. Hier war kein klares Muster zu erkennen, da andere Inhalte gänzlich ignoriert wurden. Deswegen die Empfehlung, alle wichtigen Inhalte bereitzustellen ohne die Notwendigkeit eines User-Events.

 

Die 5 Sekunden-Regel – GoogleBot ist ungeduldig

 

Wie oben bereits erwähnt, dient das Url-Überprüfen-Tool der Search Console und der Google Chrome in der Version 41 als valide Quellen für das Testing und Debugging von JavaScript für SEO. Trotz dessen, konnten beim Testing unterschiedliche Ergebnisse zwischen dem Url-Überprüfen-Tool dem tatsächlichen Renderingverhalten des Googlebots.

Dies lag vorallem daran, dass der Googlebot nach 5 Sekunden einen Screenshot der Webseite erstellt. Damit werden alle Inhalte, die erst nach den 5 Sekunden gerendert wurden, nicht unbedingt indexiert. Darauf sollte beim Testing unbedingt geachtet werden.

Dieses Tatsache bestätigt ein spannendes Experiment von Tomasz Rudzi im Elephate-Blog der mit dem damaligen „Fetch and Render Tool“ der Google Search Console welches bereits vom „Url-Überprüfungs-Tool“ abgelöst wurde, zeigte.

 

Abbildung 22: Google Search Console gibt lediglich Auskunft, ob eine Seite technisch gerendert werden kann

 

In diesem Experiment wurden Textinhalte über JavaScript erzeugt, die aber erst nach 2 Minuten auf der Webseite sichtbar waren. Bei der Betrachtung im Fetch and Render Tool der Google Search Console wurden diese Inhalte, die mit einer Verzögerung von 2 Minuten vom JavaScript erzeugt wurden, einwandfrei dargestellt. Bei der Betrachtung einer Site-Abfrage konnte aber festgestellt werden, dass er Indexer nicht so geduldig war. Die verzögerten Inhalte wurden von Google nicht indexiert.

 

Indexierbare Urls – Darauf sollte bei der Verlinkung geachtet werden

 

Abbildung 23: Empfehlung von Google für Verlinkung von Urls mit JavaScript

 

Für die URL-Struktur sollten bei JavaScript-Basierenden Webseiten ein paar Punkte beachtet werden. Es ist wichtig sicherzustellen, dass beim Aufruf von Seiten jeweils neue URLs aufgerufen werden. Das bedeutet, dass jeder Seite einer Domain eine eigene URL zugeordnet wird.

Des Weiteren sollten alle eigenständigen URLs ohne Hash „#“ realisiert werden, da Google die Angaben in der URL nach dem „#“ ignoriert. Dies führt dazu, dass Google alle internen Verlinkungen als Links zur Startseite identifizieren würde und keinen weiteren Links folgen würde. Für Sprungmarken kann ein Hash „#“, wie auch bei herkömmlichen Webseiten, verwendet werden. Zu empfehlen sind auch bei JavaScript-Basierenden Webseiten „sprechende“ URLs.

Um dem Googlebot das crawlen von Links zu ermöglichen, sollten alle Links über den HTML A-Tag realisiert werden. Auch hier sollte darauf geachtet werden, dass diese Links nicht durch ein User-Event (z.B. onClick) aufgerufen werden.

Des Weiteren sollte darauf geachtet werden, dass pushState-Fehler vermieden werden, damit die original URL mit serverseitiger Unterstützung weitergegeben wird.

 

Einsatz von Canonical-Tags

 

Im Hinblick auf das „Second Wave of Indexing“ sollten vorallem Canonical-Tags im Head-Bereich bereits crawlbar sein, ohne das JavaScript gerendert werden muss. Google selbst gibt diese Empfehlung:

 

We (currently) only process the rel=canonical on the initially fetched, non-rendered version.

— 🍌 John 🍌 (@JohnMu) 10. Mai 2018

 

Spannend zu diesem Thema ist das Experiment von Eoghan Henn, der versucht hat Canonical-Tags per JavaScript auszuspielen. Das Ergebniss war, dass Google wohl doch die knaonisiserten Urls indexiert hat, aber erst nach 34 Tagen. Dieses Experiment zeigt nochmal, wie lange es dauern kann, bis Google Inhalte die durch JavaScript erzeugt werden verarbeitet und indexiert. Daher klare Empfehlung: Canonical-Tags ohne notweniges Rendern von JavaScript ausgeben.

 

Lösungen für den Head-Bereich

 

Wie bereits im oberen Abschnitt erwähnt wurde, sind Crawler von anderen Suchmaschinen und sozialen Netzwerken noch nicht in der Lage, JavaScript zu rendern. Um diesen Crawlern wichtige Informationen wie Title-Tag, Meta-Description, Cannonical-Tag, Meta-Robots-Angaben und wenn vorhanden OpenGraph-Angaben bereit zu stellen, sollten diese Inhalte ohne vorher gerendert werden zu müssen, im Head-Bereich der Webseite aufrufbar sein.

Google selbst empfiehlt für strukturierte Daten bei JavaScript-Basierenden Webseiten den Einsatz von JSON-LD. Allgemein empfiehlt sich der Einsatz von JSON-LD für alle Arten von Webseiten.

 

Lazy Loading von Bildern für JavaScript-Webseiten

 

Abbildung 24: Vorgabe von Google für Lazy Loading mit JavaScript

 

Beim Einsatz von Lazy-Loading für Bilder gibt Google klare Empfehlungen diese entweder über ein Noscript oder über schema.org mittels JSON-LD zu lösen. Ähnlich wie bei der Vorgabe von Verlinken ist es, dass die Url des Bilder direkt ohne nötiges Rendering im Quellcode vorhanden ist.

 

Wie geht Google mit dem AJAX-Schema um?

 

Abbildung 25: Google stellt das Crawlen nach dem alten AJAX Crawling Schema einstellen

 

Google das Crawlen nach altem AJAX-Schema bereits 2018 einstellt. Johannes Müller hatte in einem Webmaster-Hangout mitgeteilt, dass keine Escaped-Fragment-URLs wie „/page?query&_escaped_fragment=key=value“ mehr aufgerufen würden.

Die Suchmaschine Bing hinsichtlich unterstützt weiterhin das AJAX-Schema.

 

Zusammenfassung – Best Pracitces im SEO für JavaScript-Webseiten

 

Zur Übersicht wurden hier nochmals alle Best-Practice-Beispiele zusammengefasst:

 

1. Analyse vom Quellcode (Pre-DOM) reicht nicht aus, da erst der gerenderte Code alle Inhalte anzeigt

2. Inhalte müssen nach dem Load-Event dargestellt werden. Inhalte die durch ein User-Event erzeugt werden, können nicht indexiert werden

3. Suchmaschinenrelevante Inhalte sollten innerhalb von 5 Sekunden gerendert und geladen sein

4. Beim Aufruf einer Seite muss eine eigene Url mit serverseitiger Unterstützung erzeugt werden

5. Kein Einsatz von Hash (#) in der Url, da alles was nach einem Hash folgt, vom Crawler gänzlich ignoriert wird

6. pushState-Fehler sollten vermieden werden, damit die original URL mit serverseitiger Unterstützung weitergegeben wird

7. Links über a-href realisieren und nicht durch User-Events (z.B. onClik) erzeugen lassen

8. Canonical-Tags sollten ohne notweniges Rendern von JavaScript im Header geladen werden

9. Beim Einsatz von Lazy Loading für Bilder muss der Dateiname im Quellcode vorhanden sein

10. Strukturierte Daten sollten mit JSCON-LD realisiert werden

11. Google hat das Crawling vom AJAX-Schema 2018 eingestellt.

 

Serverseitiges Rendering von JavaScript – Prerendering

 

Nachdem bereits alle wichtigen Problematiken Hinsichtlich JavaScript und SEO aufgeklärt wurden, dass kein SEO-Verantwortlicher mit einer Rich-JS-Webseite 100% sicher gehen kann, dass seitens der Suchmaschine alles einwandfrei abläuft. Hier kommt das Thema „Prerendering“ ins Spiel. Was das genau ist, wieso es für SEO-Verantwortliche wahrscheinlich die beste Lösung ist und alles weitere wichtige zu dem Thema, gibt es im folgenen Abschnitt.

 

Berücksichtigung von anderen Suchmaschinen?

 

Abbildung 26: Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?

 

Wie bereits angesprochen, ist lediglich der Crawler von Google in der Lage JavaScript zu rendern. Wenn man einen Wert auf andere Suchmaschinen und besonders soziale Netzwerke wie Facebook, Twitter, Instagram, Xing etc. legt, sollte eine Möglichkeit gesucht werden, auch diesen Crawlern das Auslesen der Inhalte zu ermöglichen. Prerendering, also Server-Side Rendering ist hier eine mögliche Lösung.

 

Wie funktioniert Prerendering?

 

Abbildung 27: Einsatz von Prerendering für JavaScript-Webseiten im SEO

 

Prerendering führet dazu, dass JavaScript vorgerendert wird. Das bedeutet, dass der Googlebot und alle anderen Crawler bereits den gerenderten HTML-Code bereitgestellt bekommen und nicht selbst rendern müssen um die Inhalte crawlen zu können. Das bringt den großen Vorteil mit sich, dass ganz genau sichergestellt werden kann wie der HTML-Code der dem Googlebot bereitgestellt wird aussieht.

Wer sich nicht selbst um ein serverseitiges Rendering von JavaScript kümmern möchte, kann auf kostenpflichtige Dienste wie Prerender.io setzten. Nach der erfolgreichen Implementierung des Dienstes wird die gesamte Webseite gerendert und auf dem Server gespeichert (Cache). Wie oft der Cache aktualisiert wird, hängt von dem jeweiligen Dienstleister ab.

Bei einer Anfrage an den Server wird nun geschaut, welcher User-Agent hinter einer Anfrage steckt. Wenn es sich hier um ein Bot wie z.B. den Googlebot handelt, wird diesem der bereits zwischengespeicherte, also gerenderte Code zur Verfügung gestellt. Damit erspart sich der Crawler das Rendern von JavaScript bzw. ermöglicht es Crawlern, die nicht in der Lage sind JavaScript auszuführen die Inhalte der Webseite zu erfassen.

 

Einfaches Testing von Prerendering für SEOs

 

Abbildung 28: Einsatz von Prerendering für JavaScript-Webseiten im SEO

 

Um den korrekten Einsatz von Prerendering-Diensten extern zu testen, empfiehlt sich der Einsatz des Screaming Frog SEO Spiders. In Abbildung 28 sind drei Test-Szenarien zu sehen.

 

1. Test-Scenario: User-Agent: Screaming Frog, Rendering: Text Only. Hier ist zu erkennen, dass der Crawler bis auf die Startseite keine weiteren Urls gecrawlt hat, da das JavaScript nicht ausgeführt wurde.

2. Test-Scenario: User-Agent: Googlebot, Rendering: Text Only. Hier ist zu erkennen, dass alle Urls gecrawlt wurden da der Prerendering-Dienst den User-Agent Googlebot erkannt hat und den vorgerenderten Code ausgegeben hat

3. Test-Scenario: User-Agent: Googlebot, Rendering: JavaScript. Auch hier ist zu erkennen, dass alle Urls gecrawlt wurden da die Rendering-Engine vom Screaming Frog aktiviert wurde

 

Zu Vermerken ist, dass sobald beim Screaming Frog die Rendering-Engine aktiviert wird, der Crawler auch JavaScript ausführt, egal welcher User-Agent hinter der Anfrage steckt.

 

Testing von Prerendering mit dem User-Agent-Switcher

 

Abbildung 29: Einsatz von Prerendering für JavaScript-Webseiten im SEO

 

Neben dem Screaming Frog SEO Spider eignet sich auch der Google Chrome Browser für das Testing von Prerendering-Diensten. Hierfür muss das kostenlose Add-On „UserAgent-Switcher“ installiert werden.

Mit dem UserAgent-Switcher kann der User-Agent beliebig manipuliert werden. Im ersten Fall, welcher in Abbildung 29 zu sehen ist, wurde der User-Agent auf „Default“ gestellt. Bei der Betrachtung des Quellcodes ist zu sehen, dass hier kein JavaScript ausgefuhrt wurde.

Im zweiten Fall wurde der User-Agent „Googlebot“ gewählt und die Webseite erneut besucht. Bei der Betrachtung des Quellcodes ist zu sehen, dass hier der vorgerenderte Code an den Brower ausgeliefert wurde, da der Prerendering-Dienst den Googlebot als UserAgent erkannt kann.

Bei solchen Tests sollte darauf geachtet werden, dass der Cache des Browsers bei jeder neuen Anfrage an den Server gelöscht werden sollte.

 

Dynamic Rendering – Google Empfiehlt den Einsatz von Prerendering

 

Abbildung 30: Dynamic Renderung – Googles Empfehlung für Prerendering

 

Spannden ist, dass Google selbst, zumindest laut eigener Aussage in den meisten Fällen zu Prerendering rät. Google nutzt hierfür den eigen erfundenen Namen „Dynamic Rendering“, was nichts anderes ist als das hier angesprochene Prerendering, also eine Lösung in dem JavaScript bereits vom Server gerendert wird. Google gibt hinsichtlich noch den Tipp, dass für das Rendern ein seperater Server genutzt werden soll, da das Rendern die Server zu sehr belasten könne. Dynamic Rendering wurde zum ersten mal auf der Google I/O 2018 präsentiert:

 

 

 

Google nutzt für YouTube ebenfalls Prerendering

 

Abbildung 31: Einsatz von Prerendering (Server-Side Rendering) bei YouTube

 

Interessant zu beobachten ist, dass Google für ihre Hauseigene Vidoplatform YouTube selbst Prerendering Einsetzt. Dies lässt sich in dem oben erklärten Ablauf einfach testen. Mit dem Standard User-Agent von Chrome und aktivirtem JavaSript lädt die Webseite wie gewohnt. Sobald JavaScript im Browser deaktiviert wird, sind keine Inhalte mehr zu sehen, da bei YouTube alle Videos über JavaScript erzeugt werden. Sobald der User-Agent zusätzlich auf Googlebot gestellt wird, ist die vorgerenderte Version der Webseite zu sehen. Die wichtigsten Inhalte, auch wenn in einer etwas anderen Darstellung, werden angezeigt.

Ob es sich hierbei wirklich um Prerendering handelt ist nicht sicher. Es ist aber deutlich, dass Google dem Crawler eine gesonderte Version zur Verfügung stellt, ohne JavaScript rendern zu müssen. Bei dem täglichen Neuaufkommen von Videos eine verständliche Maßnahmen Seitens Google.

 

Prerendering – Eigene Lösungen oder Kostenpflichtige Dienste?

 

Ob beim Einsatz von Prerendering auf eigene Lösungen oder kostenpflichtige Dienste gesetzt wird, gibt es keine eindeutige Antwort und sollte selbst abgeschätzt werden. Besonders der Faktor kosten und Aufwand spielt hier eine große Rolle.

Google selbst empfiehlt den Einsatz vom Kostenpflichtigen Dienst wie Prerender.io und als eigene Lösungen Renderton oder Puppeteer. Desweiteren wäre noch Phantom.js zu empfehlen.

In einem Beispiel zeigt Jesse Hanley was passieren kann, wenn der externe Dienst streiken sollte oder es Probleme bei der Abrechnnung gab:

 

Today's face palm: if you're using React, don't use a third party for server side rendering. If they go down or your credit card fails (example below) then your site will tank in the SERPs.

Self host https://t.co/7xAiWkW7XW for less headaches. pic.twitter.com/jkN3eMAvs0

— ˗ˏˋ Jesse Hanley ˎˊ˗ (@jessethanley) 21. August 2018

 

Nachteile von Prerendering- Worauf besonders achten?

 

Bei all diesen Vorteilen, bringt serverseitiges Rendern von JavaScript auch einige Nachteile für SEO mit sich. Da dem User und dem Crawler unterschiedliche Wege bis zum Aufruf der Inhalte präsentiert werden, entsteht eine Gefahr von Cloaking. Auch wenn sich die Gefahr in Grenzen hält, sollte jeder SEO-Verantwortliche bei der Entscheidung diesen Punkt mitberücksichtigen.

Des Weiteren ist durch das längere zwischenspeichern der Webseite, „Realtime Content“ nur in begrenzten Möglichkeiten einsetzbar. Änderungen werden dementsprechend erst beim nächsten „Caching“ der Webseite für den Crawler sichtbar. Damit erhöht sich die Gefahr von Cloaking.

Durch eine saubere Implementierung von Prerendering auf dem Server entstehen größere Aufwände. Auch wenn auf externe Prerendering-Dienste zurückgegriffen wird, fallen monatliche Kosten auf. Diese Staffeln sich meist je nach Webseitengröße und der Frequenz der zwischengespeicherten Version der Webseite auf dem Server.

Zu weiteren Nachteilen gehört, dass die selbe Version einer Webseite für verschiedene Endgeräte bereitgestellt wird. Bei der Nutzung von Responsive-Design und Responsive –Content muss der DOM erneut geladen werden, um jeder Bildschirmauflösung gerecht zu werden.

All diese Nachteile sollten bei der Nutzung von Prerendering in Betracht gezogen und validiert werden.

 

Isomorphic (Universal) JavaScript – die ultimative Lösung für JavaScript SEO?

 

Abbildung 32: Ist Isomorphic JavaScript die Lösung für alle SEO-Probleme?

 

Isomorphic JavaScript bzw. Universal JavaScript bietet hier Abhilfe und verspricht die Wunderwaffe im Zusammenspiel von JavaScript und SEO zu sein. Was ist Isomorphic JavaScript und wieso ist es im Bereich SEO so interessant?

 

Was ist Isomorphic JavaScript?

 

Mit dem Einsatz von Isomorphic-Lösungen wird der JavaScript-Code sowohl vom Server als auch vom Client ausgeführt. Das bedeutet, dass dem Client ein bereits gerenderter Code präsentiert wird. Das spannende dabei ist, dass JavaScript Inhalte im Browser trotzdem verändern kann. Dadurch können weiterhin dynamische Inhalte abgebildet werden und der Crawler bekommt den gerenderten Code präsentiert. Dieser „Shared-Code“ wird damit sowohl vom Browser, als auch vom Crawler genutzt.

Mit dieser Lösung wird dem Crawler das Rendern von JavaScript erspart und der Client profitiert von der besseren Performance, da der vorgerenderte Code direkt dargestellt werden kann. Damit wären die größten Schwierigkeiten beim Zusammenspiel von JavaScript und SEO gelöst.

 

Nachteile von Isomorphic JavaScript?

 

Nur bestimmte JavaScript-Frameworks eigenen sich ohne Weiteres für den Einsatz von Isomorphic-Lösungen. Andere Frameworks lassen sich nur über Umwege und deutlich höheren Aufwand für solch ein Projekt anpassen.

Da dieses Themengebiet noch sehr neu und unerprobt ist, benötigt es ein hohes Maß an Erfahrung und Knowhow auf Seiten des Entwickler-Teams. Besonders Testing und Debugging von Isomorphic JavaScript benötigt eine weitaus größere Aufmerksamkeit als herkömmliche JavaScript-Lösung im Bereich SEO. Damit ist dieser Ansatz für kleinere Projekte mit geringem Budget gänzlich unattraktiv.

Nicht desto Trotz, bietet Isomorphic JavaScript in Zukunft eine vielversprechende Lösung um SEO und JavaScript zu verheiraten.

 

Zusammenfassung – Prerendering (Server-Side-Rendering) für JavaScript-Webseiten

 

Zur Übersicht wurden hier nochmals alle wichtigen Punkte die für Prerendering (Server-Side-Rendering) für JavaScript-Webseiten wichtig sind zusammengefasst:

 

1. Ohne Prerendering werden alle anderen Suchmaschinen und soziale Netzwerke ignoriert

2. Beim Einsatz von Prerendering wird dem Crawler eine bereits vorgerenderte (cache) Version der Seite präsentiert. Der User profitiert somit weiterhin von allen Client-Side-Rendering Vorteilen von JavaScript

3. Mit dem Screaming Frog SEO Spider und der Google Chrome Erweiterung User Agent Switcher lässt sich Prerendering extern einfach testen

4. Google selbst empfiehlt in den meisten Fällen Prerendering (Dynamic Rendering)

5. Sowohl eigene Lösungen als auch kostenpflichte Dienste für Prerendering kommen in Frage

6. Isomorhic (Universal) JavaScript bietet in ferner Zukunft die optimale Lösung, steckt aktuell aber noch in den Kinderschuhen

 

Gedanken zu JavaScript SEO – Wie sieht die Zukunft von JavaScript SEO aus?

 

Abschließend einige Gedanken zu JavaScript SEO, welche Punkte es SEO-Verantwortlichen erschwert JavaScript und SEO unter einen Hut zu bringen, welche neuen Ansätze geschaffen werden müssen und wo der Weg hingehen sollte.

 

Welche Punkte erschweren SEO-Verantwortlichen den Umgang mit JavaScript?

 

Alleine die Schwierigkeit, dass nur Google als bislang einzige Suchmaschine JavaScript rendern kann, erschwert es SEO-Verantwortlichen den Umgang mit JavaScript. Auch wenn andere Suchmaschinen nachziehen, werden diese sehr wahrscheinlich andere Technologien und Renderning-Engines nutzen, um JavaScript ausführen zu können. Zusätzlich muss mit unterschiedlichen JavaScript-Frameworks anders umgegangen werden.

Wie sieht es mit dem Auditing und Testing aus? Da kaum Tool-Anbieter überhaupt das Rendering von JavaScript anbieten, wenn überhaupt, dann mit unterschiedlichen Rendering-Engines, sind diese Tools kaum bis gar keine validen Quellen auf die sich SEO-Verantwortliche verlassen können.

 

Ist JavaScript für SEO zu empfehlen?

 

Auch beim Einsatz von Best Practice JavaScript SEO Maßnahmen ist keine Garantie für die korrekte Indexierung gewehrleistet. Ein erster Schritt in die richtige Richtung seitens Google, war das Veröffentlichen des Dokumentes „Rendering von Google Search“ und „Dynamic Rendering. Den Großteil der aktuellen Ressourcen zu JavaScript SEO stammt von sehr engagierten SEOs aus der ganzen Welt, die sich diesem Thema widmen.

Nach Erfahrungen und aktuellen Erkenntnissen kann der Einsatz von JavaScript für die Disziplin SEO nicht empfohlen werden. Es gibt zwar Lösungen und Wege JavaScript und SEO unter einen Hut zu bringen, diese Wege und Lösungen sind aber aufwendig, riskant und fehleranfällig und geben nie eine 100% Garantie, ob Google wirklich alles so verarbeitet wie gewollt. Daher gibt es abschließend eine klare Empfehlung für den Einsatz von Prerendering.

Abschließend ein Zitat vom Kollegen Bartosz: „Ranking well with CSR JavaScript Websites is very hard if not impossible“.

 

Vorträge über JavaScript SEO

 

Abschließen gibt es hier nochmals die Webinar-Aufzeichnung bei Searchmetrics und die Slides zu Vorträgen von der SEOKomm, dem SEO Day und der SEO Campixx zu JavaScript SEO.

 

Searchmetrics Webinar-Aufzeichnung 2018 – JavaScript SEO

 

 

SEO Day 2018 Slides – JavaScript SEO

 

 

SEO Campixx 2018 Slides – JavaScript SEO

 

 

SEOKomm 2017 Slides – JavaScript SEO