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 der offiziellen Aussage von Google, kann der Googlebot JavaScript rendern, die Inhalte crawlen und indexieren. Auf der AngularConnect 2016 in London, geht Googles John Mueller auf das Thema JavaScript SEO ein und bestätigt, dass Google ein gutes Verständnis dafür hat, Inhalte in JavaScript zu rendern und 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?

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. Auch führende SEO-Tools sind hinsichtlich dieser Thematik noch hinterher. Dieser Stand wird sich sicherlich in der Zukunft grundlegend ändern.

JavaScript ist hier um zu bleiben. Andere Suchmaschinen, soziale Netzwerke und Softwareanbieter werden nicht an dem Thema vorbeikommen.

Technologien von Crawlern – Wie interagiert ein Crawler mit JavaScript?

Um als SEO-Verantwortlicher mit JavaScript umgehen zu können, sollten die JavaScript-Grundlagen und die Technologien von Crawlern bekannt sein, um valide Test-Verfahren durchführen zu können.

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. 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 einer Rendering-Engine. Auch Tools die beim Auditing unterstützend helfen, müssen über diese Technologien verfügen um valide Daten zu liefern.

Der Crawler rendert nicht JavaScript

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.

Wie geht der Crawler mit JavaScript-Webseiten im Gegensatz zu reinen Html-Webseiten um?

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.

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

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

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 2 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.

Welche Crawler sind in der Lage JavaScript zu rendern?

Abbildung 3: Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?

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.

Hinweis: Dieser Beitrag wird stätig aktualisiert. Sobald andere Crawler wie die von Bing, Yahoo oder Yandex in der Lage sind JavaScript auszuführen, werden die Erkenntnisse hier ebenfalls ergänzt.

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.

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.

Für den Umgang und weitere Einblicke in Chrome 41 ist caniuse.com und Chrome Platform Status sehr nützlich.

Googlebot vs. Google Search Console Bot

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

Da von Google offiziell bestätig wurde, dass der Google Bot den WRS des Google Chromes 41 nutzt, ist der Blick auf das Fetch and Render Tool der Google Search Console interessant. Welche Technologien werden beim „So hätte ein Besucher Ihrer Webseite die Webseite gesehen“ verwendet?

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 5).

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.

Sicherlich wird es auch weitere Unterschiede geben. Bislang sind aber keine weiteren Aussagen von Google bekannt.

Crawling und Indexierung von verschiedenen JavaScript-Frameworks

Abbildung 6: 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 7: 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.

Wie geht Google mit dem AJAX-Schema um?

Abbildung 8: Google stellt das Crawlen nach dem alten AJAX Crawling Schema noch dieses Jahr einstellen

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

Zusammenfassung der Erkenntnisse

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.

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

5. Der Google Chrome 41 kann neben dem „Fetch and Rendering“-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. Crawling vom AJAX-Schema wird 2018 eingestellt.

Das hier erlernte Wissen und die gewonnenen Erkenntnisse sollten beim Auditing von JavaScript-Webseiten beachtet werden.

Auditing von JavaScript-Webseiten und Best Practices

Da nun die Grundprinzipien von JavaScript und die dadurch entstehenden Schwierigkeiten bezüglich SEO bekannt sind, wird sich der folgende Teil dieses Artikels darüber beschäftigen, wie JavaScript-Webseiten analysiert werden können, auf welche Punkte geachtet werden sollte und welche Tools dabei hilfreich sein können.

Quellcode vor und nach dem Rendern

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

Bei 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 bei korrekter Implementierung alle Inhalte auch im Quellcode sichtbar.

In der linken Spalte in Abbildung 7 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.

Um sicher zu gehen, wurden Textbereiche aus dem Browser kopiert und im gerenderten Quellcode gesucht. Hier konnten alle Inhalte einwandfrei gefunden werden.

Chrome Developer Tools – Auditing vom gerenderten Quellcode

Abbildung 10: 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.

Diese Vorgehensweise wurde auch bereits von Justin Briggs thematisiert.

Chrome 41 – Googles Technologien nutzen

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.

Fetch and Render Tool der Google Search Console und Site-Abfrage

Abbildung 12: Google Search Console „Fetch & Render“-Tool gibt lediglich Auskunft, ob eine Seite technisch gerendert werden kann

Naheliegend ist es natürlich, das Fetch and Render Tool der Google Search Console zu nutzen. Hierbei sollte aber darauf geachtet werden, dass das Fetch and Render Tool der Google Search Console lediglich Auskünfte darüber gibt, ob eine Webseite technisch gerendert werden kann. Timeouts und Performance-Ansprüche des GoogleBots werden hier nicht berücksichtigt. Dieses Tatsache bestätigt ein spannendes Experiment von Tomasz Rudzi im Elephate-Blog.

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.

Deswegen ist es immer zu Empfehlen eine Site-Abfrage inkl. Ausschnitt des zu überprüfenden Textes zu starten.

Google Rich Media Tester zur Betrachtung des DOM nutzen

Abbildung 13: Betrachtung des DOM mit dem Google Rich Media Tester

Laut eigenen Aussagen von Google (John Mueller) weißt das Fetch and Render Tool der Google Search Console noch einige Schwächen auf, wenn es um die Betrachtung des DOM geht. Deswegen wird der Google Rich Media Tester hier empfohlen. Veränderungen die durch JavaScript am DOM nachträglich vorgenommen werden, können mit dem Google Rich Media Tester dargestellt werden. Auch CSS-Anweisungen die z.B. durch Resizing verursacht werden, kann der Google Rich Media Tester darstellen. Die Betrachtung des DOM, die der Google Rich Media Tester aktuell bietet, ist laut eigenen Aussagen von Google auch für das Fetch and Render Tool der Google Search Console geplant.

Screaming-Frog – Eigene Rendering-Engine mit Vorsicht geniesen

Abbildung 14: Der Einsatz des SEO Spider Screaming Frog 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.

Searchmetrics Suite – Chrome- und PhantomJS-basiertes JavaScript-Crawling

Abbildung 15: 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 16: 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:

Malte Landwehr, Director Product Marketing & Solutions, Searchmetrics

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.

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.

Node.JS und Puppeteer – Automatisierung & Scrapping mit JavaScript

Abbildung 17: Automatisieren und Scrappen mit Headless Chrome

Ein weiteres Hilfreiches Tool ist Node.JS mit der Kombination mit der Node.JS Libary API Puppeteer. Da Node.JS die für Google Chrome entwickelte JavaScript-Engine „V8“ nutzt, eignet sich diese gut für Testing und Debugging.

Puppeteer ist eine Node.js Library API mit der man Headless Chrome steuern kann. Dadurch kann JavaScript-Code eingesetzt werden, um Webseiten mit Headless Chrome zu scrappen. Mit dem Einsatz von JavaScript-Befehlen lassen sich damit weit aus intensivere Testszenarios entwickeln, als mit den herkömmlichen Headless Chrome Befehlen.

Wie Puppeteer und Node.JS eingerichtet und verwendet werden kann wird von Brandon Morelli bei Codeburst.io sehr ausführlich und sachlich erklärt. Die API Dokumentation von Puppeteer und das von Google erstelle Dokument „Getting Started with Headless Chrome“ sind ebenfalls sehr gute Ressourcen.

Unterschiedliche Ergebnisse beim Fetch & Rendering Tool der Search Console und Chrome 41

Wie oben bereits erwähnt, kann dient das Fetch & Rendering Tool der Search Console und der Google Chrome in der Version 41 als einige valide Quellen für das Testing und Debugging von JavaScript für SEO. Trotz dessen, konnten beim Testing unterschiedliche Ergebnisse zwischen dem Fetch & Rendering Tool der Search Console und dem Google Chrome 41 beobachtet werden. In einigen Fällen wurde JavaScript sauber gerendert und im Chrome 41 dargestellt, hingegen das Fetch & Rendering Tool der Search Console nur Teilweise bis gar keine Inhalte darstelle.

Dies lag vorallem daran, dass der Googlebot nach 5 Sekunden einen Screenshot der Webseite erstellt. Damit wurden alle Inhalte, die erst nach den 5 Sekunden gerendert wurden, nicht mehr in der Vorschau des Fetch & Rendering Tool der Search Console dargestellt. Der Google Chrome 41 hingegen arbeitet zwar mit denselben technologien, agiert aber wie ein herkömmlicher Browser und rendert auch weit über die 5 Sekunden. Darauf sollte beim Testing unbedingt geachtet werden.

Umgang mit dynamischen Inhalten

Abbildung 18: 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.

Indexierbare Urls – Darauf sollte bei der Verlinkung geachtet werden

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.

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.

Zusammenfassung – Auditing von JavaScript-Webseiten

Zur Übersicht wurden hier nochmals alle wichtigen Punkte, die beim Auditing von JavaScript-Webseiten beachtet werden sollten 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. Beim Aufruf einer Seite muss eine eigene Url mit serverseitiger Unterstützung erzeugt werden

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

5. Strukturierte Daten sollten mir JSCON-LD realisiert werden

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

Serverseitiges Rendering von JavaScript – Prerendering

Wenn der Googlebot aus verschiedenen Gründen nicht in der Lage ist, JavaScript zu rendern, greift dieser auf den nichtgerenderten Quellcode der Webseite zurück, um diesen zu crawlen. Das hätte für SEO verehrende Auswirkungen, wenn der komplette Inhalt der Webseite durch JavaScript dargestellt wird. Deswegen setzen viele SEO-Verantwortliche heutzutage auf Pre-Rendering.

Wieso ist Prerendering eine Option?

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.

Wie funktioniert Prerendering?

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

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.

Testing von Prerendering im ScreamingFrog

Abbildung 20: 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 15 sind drei Tests-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 21: 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 16 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.

Nachteile von Prerendering

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 22: 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.

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. Hier sollten Suchmaschinen-Konzerne wie Google mehr Transparenz bieten. Ein erster Schritt in die richtige Richtung, war das Veröffentlichen des Dokumentes „Rendering von Google Search“. Hier sollte viel mehr über die Technologien preisgegeben werden. 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.

35 JavaScript SEO Ressourcen + SEO Campixx & SEOKomm Slides

Hier gibt es die Folien zum Vortrag auf der SEOKomm 2017 „JavaScript SEO: Crawling, Indexierung und Auditing von JavaScript-Webseiten“ inklusive 35 großartige JavaScript SEO Ressourcen (Download-Link in den Folien).

SEO Campixx 2018 Slides – JavaScript SEO

SEOKomm 2017 Slides – JavaScript SEO

Artur Kosch

Artur Kosch ist Online-Unternehmer und SEO-Experte. Als geschäftsführender Gesellschafter von Kosch Klink Performance schreibt er regelmäßig Fachartikel und hält Vorträge auf Konferenzen rund um das Thema Online Marketing und SEO.

So wirst du von Google als Entität wargenommen – Das Selbstexperiment: in 2 Tagen zur Entität bei Google
21. Dezember 2018

Non-Brand-Traffic Messung im SEO: Datenauswertung der Google Search Console im Google Data Studio
17. September 2018

Search Experience Optimization: Verständnis der Nutzererwartung für die Content-Erstellung
22. Mai 2017

Egobait im Influencer Marketing: Die Reichweite der Branchen-Experten nutzen
18. April 2017

Searchmetrics Content Experience: Ein tiefer Einblick in das Content-Tool
6. Januar 2017

Die Suchanalyse in der Google Search Console: Sieben Anwendungsfälle aus der Praxis
16. Dezember 2016