• 21. August 2019
  • 53 Min

Java­Script SEO Guide

Crawling, Indexierung und Auditing von JavaScript-Webseiten

YouTube

Mit dem Laden des Vide­os akzep­tie­ren Sie die Daten­schutz­er­klä­rung von You­Tube.
Mehr erfah­ren

Video laden

Laut offi­zi­el­len Aus­sa­gen Sei­tens Goog­le kann der Goog­le­bot Java­Script ren­dern, die Inhal­te craw­len und inde­xie­ren. Goog­le bestä­tigt immer wie­der, dass der Such­ma­schi­nen-Kon­zern ein gutes Ver­ständ­nis dafür hat Java­Script zu ren­dern und die dadurch erzeug­ten Inhal­te zu crawlen.

Lei­der gibt es eini­ge Fall­stu­di­en die genau die­se Aus­sa­ge wie­der­le­gen. Liegt es bei die­sen Fall­stu­di­en wirk­lich an der man­geln­den Inter­pre­ta­ti­ons­fä­hig­keit Sei­tens Goo­g­les oder schlicht­weg an einer feh­ler­haf­ten Imple­men­tie­rung von Java­Script? Java­Script ist weit aus kom­ple­xer für Craw­ler als rei­nes HTML. Wie­so man sich auf sehr dün­nes Eis begibt, wenn man Java­Script Cli­ent-Side aus­spielt, wird in die­sem Bei­trag im Detail beleuchtet.

Abge­se­hen davon gibt es zum aktu­el­len Stand weni­ge Craw­ler die Java­Script ren­dern kön­nen. Craw­ler von ande­ren Such­ma­schi­nen und sozia­len Netz­wer­ken ver­su­chen über­haupt nicht Java­Script zu ren­dern und das aus einem guten Grund. Auch füh­ren­de SEO-Tools sind hin­sicht­lich die­ser The­ma­tik noch hin­ter­her. Wie­so neben Goog­le nur weni­ge Java­Script ren­dern und wie­so sich das wohl in naher Zukunft nicht ändert, wird in die­sem Bei­trag erklärt.

Um als SEO-Ver­ant­wort­li­cher mit Java­Script umge­hen zu kön­nen, soll­ten ein paar wich­ti­ge Java­Script-Grund­la­gen und die Tech­no­lo­gien von Craw­lern bekannt sein, um die gesam­te Pro­ble­ma­tik zu ver­ste­hen und sich der Risi­ken bewusst zu sein.

PHP-Rendering und JavaScript-Rendering zwischen Browser und Server
Abbil­dung 1: PHP-Ren­de­ring und Java­Script-Ren­de­ring zwi­schen Brow­ser und Server

Zu Beginn eini­ge Grund­la­gen, um das The­ma in den nächs­ten Absät­zen zu ver­deut­li­chen. Hier einer der größ­ten Unter­schie­de und gleich­zei­tig der Haupt­grund wie­so Java­Script für Craw­ler eine Her­aus­for­de­rung dar­stellt. Java­Script wird nicht vom Ser­ver, son­dern vom Brow­ser (Cli­ent) aus­ge­führt. Ein ver­ein­fach­ter Ablauf wird im Fol­gen­den erläu­tert und ist in Abbil­dung 1 gra­fisch dargestellt:

  1. 1.
    Der Brow­ser stellt eine GET-Anfra­ge an den Server
  2. 2.
    Der Ser­ver führt das PHP-Script aus (z.B. beim Ein­satz eines CMS)
  3. 3.
    Der Ser­ver gibt den HTML-Quell­code an den Brow­ser zurück
  4. 4.
    Der Brow­ser führt das Java­Script aus

Bei einer Web­sei­te ohne Ein­satz von Java­Script liegt bereits nach Punkt 3 der Inhalt einer Web­sei­te dem Brow­ser oder einem Craw­ler vor. Java­Script-Code wird erst in Punkt 4 vom Brow­ser selbst ausgeführt.

Genau hier liegt das gro­ße Pro­blem. Damit ein Craw­ler Inhal­te die durch Java­Script aus­ge­führt wer­den craw­len kann, muss die­ser die Arbeit eines Brow­sers über­neh­men inklu­si­ve aller nöti­gen Tech­no­lo­gien und Res­sour­cen, wie z.B. einer Ren­de­ring-Engi­ne. Auch Tools die beim Audi­t­ing unter­stüt­zend hel­fen, müs­sen über die­se Tech­no­lo­gien ver­fü­gen um vali­de Daten zu liefern.

Links ist der Quellcode einer Webseite zusehen vor dem Rendering vom JavaScript. Rechts nach dem Rendering
Abbil­dung 2: Ein­blick in den Quell­code vor und nach dem Ren­dern von JavaScript

Mit einem Blick auf den Quell­code einer Java­Script-Basie­ren­den Web­sei­te, wird schnell deut­lich, dass die vom Brow­ser ange­zeig­ten Inhal­te im Quell­code nicht zu sehen sind. Das liegt dar­an, dass kein Java­Script aus­ge­führt wur­de, also der DOM der Web­sei­te nicht geren­dert wur­de. Erst nach­dem Java­Script aus­ge­führt wird, wer­den alle Inhal­te auch im Quell­code sichtbar.

In der lin­ken Spal­te in Abbil­dung 2 ist der Quell­code einer Java­Script-Basie­ren­den Web­sei­te zu sehen. Hier ist gut zu erken­nen, dass im Quell­code kei­ner­lei Inhal­te zu sehen sind. In der rech­ten Spal­te wur­de Java­Script bereits aus­ge­führt, daher sind hier alle Inhal­te die im Brow­ser zu sehen sind auch im Body-Bereich des geren­der­ten Quell­codes vorhanden.

Grundprinzipien eines Headless-Browsers an Hand von Headless Chrome
Abbil­dung 3: Grund­prin­zi­pi­en eines Head­less-Brow­sers an Hand von Head­less Chrome

Um ver­ein­facht dar­zu­stel­len, wie ein Craw­ler mit einer Web­sei­te inter­agiert, wird der Craw­ler wie einen Head­less-Brow­ser betrach­tet.
Ein Head­less-Brow­ser beschreibt rela­tiv genau, wie der Goog­le­bot mit einer Java­Script-Basie­ren­den Web­sei­te inter­agiert, des­we­gen ist es hilf­reich zu ver­ste­hen, wie ein Head­less-Brow­ser arbeitet.

Ein Head­less-Brow­ser ist ein Brow­ser ohne visu­el­le Kom­po­nen­ten. Das bedeu­tet, dass ein Head­less-Brow­ser kei­ne Inhal­te dar­stellt um mit die­sen wie ein Web­sei­ten­be­su­cher zu inter­agie­ren. Die­ser inter­agiert mit­tels Befeh­len mit einer Webseite.

Um die Arbeits­wei­se eines Head­less-Brow­ser ein­fa­cher zu ver­deut­li­chen, wur­de der Head­less-Mode des Goog­le Chro­me Brow­ser genutzt. Der Head­less-Mode ist seit der Ver­si­on 59 für Mac OS und Linux und seit der Ver­si­on 61 für Win­dows ver­füg­bar. Laut Spe­ku­la­tio­nen wur­de der Head­less Chro­me für den Goo­ge­bot entwickelt.

Um den Head­less Chro­me (Head­less Mode von Goog­le Chro­me) nut­zen zu kön­nen, genügt die Kon­so­le bei Win­dows bzw. das Ter­mi­nal bei Mac OS. In Abbil­dung 3 sind ein­fa­che Befeh­le ver­wen­det wor­den, um den Head­less Chro­me zu steuern.

In Zei­le 1 wur­de ledig­lich der Pfad der Instal­la­ti­on von Goog­le Chro­me hin­ter­legt um mit dem Befehl „chro­me“ direkt auf den Brow­ser zugrei­fen zu kön­nen. Zei­le 5 kann fol­gend inter­pre­tiert werden:

  • Chome: Zugriff auf den Goog­le Chro­me Browser
  • –head­less: Goog­le Chro­me im Head­less-Mode ausführen
  • –dis­able-gpu: Die­ser Befehl ist laut Goog­le aktu­ell nur wegen eines Pro­blems notwendig
  • –dump-dom: Aus­ge­ben des DOM
  • Url: Die­se Url wird für den Befehl angesteuert

Nach der Ein­ga­be die­ser Befeh­le liest der Head­less Chro­me den DOM der ange­ge­be­nen Web­sei­te aus und gibt die­sen direkt in der Kon­so­le bzw. Ter­mi­nal aus. Der DOM kann danach belie­big in ein Text­pro­gramm ein­ge­fügt und ana­ly­siert werden.

Zur Ver­deut­li­chung wur­den noch wei­te­re Befeh­le aus­ge­führt. In Zei­le 8 wird der Head­less Chro­me die ange­ge­be­ne Web­sei­te als PDF spei­chern. Ab Zei­le 9 wird von der Web­sei­te ein Screen­shot der Web­sei­te, je nach Wahl der Pixel-Grö­ße, erstel­len und gespeichern.

Ver­ein­facht sol­len die­ses Befeh­le ver­deut­li­chen, wie ein Craw­ler sich durch die Web­sei­te arbeitet.

Welche Technologien nutzt der GoogleBot um Webseiten zu rendern
Abbil­dung 4: Wel­che Tech­no­lo­gien nutzt der Goog­le­Bot um Web­sei­ten zu rendern

Erst im August 2017 wur­den von Goog­le tie­fe­re Ein­bli­cke in die Tech­no­lo­gie beim Ren­dern von Web­sei­ten des Goog­le­bots ver­öf­fent­licht. Bis Dato war über das Ren­de­ring des Goog­le­bots kaum etwas bekannt und ledig­lich die Goog­le Search Con­so­le dien­te als vali­de Quel­le für Debug­ging und Testing.

Laut die­sem Doku­ment nutz­te der Goog­le­bot den Web Ren­de­ring Ser­vice (WRS) wel­cher auf dem Goog­le Chro­me 41 basiert, um Web­sei­ten zu ren­dern. Die­se Ver­si­on (Down­load Chro­me Ver­si­on 41) des Goog­le Chro­me Brow­sers stammt aus dem Jahr 2015 und ver­fügt etwa über 60% der Tech­no­lo­gien und Fea­tures der aktu­el­len Chro­me Ver­si­on. Wer sich selbst ein Bild machen möch­te, wel­che Unter­schie­de zwi­schen Ver­si­on 41 und der aktu­el­len Chro­me-Ver­si­on sind erfährt alle Fea­ture-Unter­schie­de im Detail auf Caniuse.com und Chro­me Plat­form Sta­tus deutlich.

Knapp zwei Jah­re nach Publi­ka­ti­on die­ses Doku­men­tes ver­öf­fent­li­che Goog­le, dass der Goog­le­bot nun end­lich „ever­green“ läuft. Das bedeu­tet, dass der Goog­le­bot sich immer an die Fea­tures und Funk­tio­nen der aktu­el­len Ver­si­on des Chro­me Brow­sers anpasst. Der geschätz­te Kol­le­ge Valen­tin Plet­zer hat hier­für eine Web­sei­te ein­ge­rich­tet, die beim Besuch vom Goog­le­bot des­sen Ver­si­on tes­tet, um zu veri­fi­zie­ren, ob nach einer Aktua­li­sie­rung des Chro­mes, der Goog­le­bot auch die neu­en Fea­tures unter­stützt. Da Goog­le laut eige­nen Aus­sa­gen den User-Agent nicht ändern wird, wird der Goog­le Bot immer als Chro­me 41 iden­ti­fi­ziert. Dies hat aber nichts mit der Ver­si­on des WRS des Goog­le­bots zu tun.

Des Wei­te­ren ist bekannt, dass der Goog­le­bot das Trans­fer Pro­to­koll HTTP/2 aktu­ell nicht unter­stützt. Da HTTP/2 Abwärts­kom­pa­ti­bel ist, soll­te dies kei­ne Pro­ble­me dar­stel­len. Zudem gibt es kei­ne Unter­stüt­zung für WebSo­cket-Pro­to­koll, Inde­xedDB und WebS­QL-Inter­faces zur Daten­hal­tung im Brow­ser. Inhal­te die erst nach Zustim­mung des Users ange­zeigt wer­den, wer­den eben­falls nicht inde­xiert. Inter­es­sant ist auch die Infor­ma­ti­on, dass Inhal­te des Local Sto­rages sowie Ses­si­on Sto­rages gelöscht wer­den und beim Auf­ruf einer neu­en Url HTTP-Coo­kies gelöscht werden.

Wei­te­re Gui­des direkt vom Goog­le zum The­ma Ren­de­ring und Java­Script gibt es auf der Goog­le Deve­lo­pers Web­sei­te.

Ver­mehrt herrscht die Mei­nung, dass der Craw­ler, bei Goog­le ist es der Goog­le­bot, für das Ren­dern von Java­Script ver­ant­wort­lich ist. Dies ist aber ein Fehl­glau­be. Das Ren­dern von Java­Script über­nimmt erst der Inde­xer, bei Goog­le ist es Caff­ei­ne. Genau­er gesagt, ist es der Web Ren­de­ring Ser­vice (WRS), der ein Teil von Caff­ei­ne ist. Genau­so wie der Page­R­an­ker ein Teil von Caff­ei­ne ist. Mehr zu den Tech­no­lo­gien die Goog­le für das Ren­dern von Java­Script nutzt, wer­den wei­ter im Arti­kel erläutert.

Der User @methode schreibt auf Twitter darüber, dass Google Caffeine für das Rendern von JavaScript verantwortlich ist.

Um sich über die Her­aus­for­de­run­gen, vor denen Such­ma­schi­nen beim Craw­len und Inde­xie­ren von Java­Script-Inhal­ten ste­hen, bewusst zu sein, ist es wich­tig zu ver­ste­hen, wie der Ablauf einer Such­ma­schi­ne beim Craw­len und Inde­xie­ren von Html-Web­sei­ten im Ver­gleich zu Java­Script-Web­sei­ten aus­sieht. Der fol­gen­de Ablauf dient als ver­ein­fach­te Darstellung.

Ablauf beim Craw­len von Html-Inhalten

  1. 1.
    HTML-Datei­en wer­den runtergeladen
  2. 2.
    Links wer­den aus dem Quell­code ent­nom­men und kön­nen gecrawlt werden
  3. 3.
    CSS-Datei­en wer­den runtergeladen
  4. 4.
    Goog­le­bot (Craw­ler) sen­det alle Res­sour­cen zu Caff­ei­ne (Inde­xer)
  5. 5.
    Goog­le­bot sen­det alle Res­sour­cen zu Caffeine
Ein HTML JavaScript Icon

Die­ser Pro­zess kann einem Ablauf abge­schlos­sen wer­den. Das bedeu­tet, nach dem der Craw­ler sei­ne Schrit­te absol­viert hat, wer­den die wei­te­ren Arbeits­ab­läu­fe an den Inde­xer über­ge­ben. Wenn die­ser fer­tig ist, ist der Ablauf abge­schlos­sen bis der Craw­ler die Web­sei­te erneut besucht.

Ablauf beim Craw­len von JavaScript-Inhalten

  1. 1.
    HTML-Datei­en wer­den runtergeladen
  2. 2.
    CSS- und Java­Script-Daten wer­den par­al­lel runterladen
  3. 3.
    WRS (Web Ren­de­ring Ser­vice) wird genutzt (Teil von Caff­ei­ne) um JS auszuführen
  4. 4.
    WRS ren­dert alle Dateien
  5. 5.
    Caff­ei­ne kann nun die Inhal­te ggf. indexieren
  6. 6.
    Erst jetzt kann Goog­le­bot neue Links crawlen
Ein HTML JavaScript Icon und eine Lupe

Der gro­ße Nach­teil bei die­sem Ablauf ist, dass die­ser für jede ein­zel­ne Url wie­der­holt wer­den muss, da der Inde­xer erst Java­Script ren­dern muss, um an die wei­te­ren links zu kom­men, die der Craw­ler dann besu­chen kann. Hier ent­steht für die Such­ma­schi­nen also nicht nur der Auf­wand des Ren­dern von Java­Script, son­dern auch beim Craw­len ist der Pro­zess sehr umständlich.

Ablauf beim Craw­len von JavaScript-Inhalten

Second Wave of Indexing - Javascript Rendering Google
Abbil­dung 5: Second Wave of Index­ing – Goog­le I/O 2018

Goog­le selbst spricht hier von „Second Wave of Index­ing“. Hier­bei wird erklärt, dass beim ers­ten Besuch (Crawl) das „Instant, first wave of index­ing“ statt­fin­det. Es wer­den alle Inhal­te direkt inde­xiert, ohne Ren­de­ring über­haupt anzu­wen­den. Was für Rich-JS-Web­sei­ten fatal sein kann. Beson­ders wenn sich Inhal­te oft ändern und aktu­ell sein müs­sen. Erst beim zwei­ten Besuch wird geren­dert. Zwi­schen dem ers­ten und zwei­ten Besuch kön­nen aber auch mal ein paar Tage bis Wochen lie­gen, Zitat von Goo­g­les John Mül­ler auf Twitter:

John Müller twittert über das Rendering von JavaScript.
Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?
Abbil­dung 6: Wie craw­len und inde­xie­ren ver­schie­de­ne Such­ma­schi­nen JavaScript?

Goog­le nutzt also eine Ren­de­ring-Engi­ne für Java­Script- Wie sieht es aber mit ande­ren Such­ma­schi­nen aus? Um die­se Fra­ge zu beant­wor­ten, hat der geschätz­te Kol­le­ge Bart­osz Góral­wicz ein inter­es­san­tes Expe­ri­ment durch­ge­führt. Das Ziel des Expe­ri­men­tes war es, her­aus­zu­fin­den, wie Craw­ler mit wel­chen Java­Script-Frame­works umge­hen kön­nen. Inter­es­sant zu sehen ist, dass bis auf Goog­le (Ask bas­siert auf Goog­le) kei­ne ande­re Such­ma­schi­ne in der Lage ist Java­Script zu rendern.

Abge­se­hen von die­sem Expe­ri­ment ist auch bekannt, dass Craw­ler von Face­book, Twit­ter, Lin­kedIn oder Xing aktu­ell auch kein Java­Script ren­dern. Nach die­ser Erkennt­nis wer­den ledig­lich die Tech­no­lo­gien des Goog­le­bots für die Inter­ak­ti­on mit Java­Script betrachtet.

Mit einer Ser­ver-Side gered­ner­ten Rich-JS-Webst­te schließt man alle ande­ren Such­ma­schi­nen und sozia­le Netz­wer­ke aktu­el­le aus!

Gerüch­ten zu fol­ge scheint Bing ledig­lich bei gro­ßen Web­sei­ten Java­Script zu ren­dern. Die­se Aus­sa­ge konn­te lan­ge Zeit nicht bestä­tigt wer­den. Der geschät­zer Kol­le­ge Dan Patro­vic hat auf Twit­ter gezeigt, dass die Web­sei­te lendi.com die Java­Script Ser­ver-Side aus­spielt von der Such­ma­schi­ne von Micro­soft inde­xier­te Inhal­te aufweist.

Wie crawlt und indexiert der Googlebot verschiedene JavaScript-Frameworks?
Abbil­dung 7: Wie crawlt und inde­xiert der Goog­le­bot ver­schie­de­ne JavaScript-Frameworks?

Um noch­mals auf das Expe­ri­ment von Bart­osz Góra­le­wisz zurück­zu­kom­men, wur­de zwar fest­ge­stellt, dass Goog­le aktu­ell die ein­zi­ge Such­ma­schi­ne ist, die einen Craw­ler ins Ren­nen schickt, der auch Java­Script ren­dern kann, sich aber bei ver­schie­de­nen Java­Script-Frame­works auch unter­schied­lich verhält.

Beson­ders bei extern auf­ge­ru­fe­nen Java­Script hat der Craw­ler laut die­sem Expe­ri­ment Pro­ble­me Urls zu craw­len und die­se zu besu­chen. Des­we­gen kann davon aus­ge­gan­gen wer­den, dass der Ein­satz von Inli­ne-JS die bes­se­re Vari­an­te ist Java­Script zu imple­men­tie­ren, was gegen eine sau­be­re Archi­tek­tur spricht.

Feh­ler im Angu­lar JS 2 Frame­work führ­te zu Crawling-Problemen

Ein Fehler im Angular JS 2 Framework führte zu Indexierungsproblemen seitens Google
Abbil­dung 8: Ein Feh­ler im Angu­lar JS 2 Frame­work führ­te zu Inde­xie­rungs­pro­ble­men sei­tens Google

Beson­ders die Ergeb­nis­se beim Angu­lar JS 2 Frame­work hat vie­le Fra­gen auf­ge­wor­fen. Goog­le hat Pro­ble­me ihr eige­nes Frame­work zu craw­len? Nach lan­gen Über­le­gun­gen konn­te die­se Fra­ge auf­ge­klärt wer­den: Ein ein­fa­cher Feh­ler im Frame­work hat dazu geführt, dass Goog­le selbst Pro­ble­me bei der Inde­xie­rung hat­te. Nach eige­nen Anga­ben von Goog­le, wur­de die­ser Feh­ler am 26. April 2017 beho­ben, was die Inde­xie­rung des Angu­lar JS 2 Frame­works ermög­lich­te. Dies ist ein wei­te­res Bei­spiel dafür, wie feh­ler­an­fäl­lig Java­Script-Frame­works sind, wenn es um die Crawl­bar­keit und Inde­xier­bar­keit geht.

Ein Fehler im Angular JS 2 Framework führte zu Indexierungsproblemen seitens Google
Abbil­dung 9: Java­Script Ren­de­ring Performance

Ein wich­ti­ger Punkt beim Ren­dern von Java­Script ist, dass die­ser wie bereits vom Brow­ser geren­dert wird. der Brow­ser greift für das Ren­dern auf die Hard­ware des Rech­ners, beson­ders auf die CPU. Was bedeu­tet, dass Rich-JS-Web­sei­ten auf leis­tungs­star­ken Rech­nern schnel­ler lädt, als auf älte­ren schwä­che­ren CPUs.

Die­se Rechen­leis­tung müs­sen Such­ma­schi­nen­kon­zer­ne mit­be­rück­sich­ten, um Java­Script zu ren­dern. Die­se Rechen­leis­tung kos­tet natür­lich mehr Geld als bei her­kömm­li­chen HTML-Web­sei­ten. Für Goog­le ist es mit dem enor­men Markt­an­teil kei­ne gro­ße Schwie­rig­keit die­se Rechen­leis­tung, auch wenn nur limi­tiert, zu Ver­fü­gung zu stellen.

Kon­kur­ren­ten wie Bing oder ande­re Such­ma­schi­nen haben mit Ihrem nur sehr gerin­gen Markt­an­teil nicht die nöti­gen Mit­tel um eige­nes Ren­de­ring von Java­Script anzu­bie­ten. Man spricht davon, dass eine Java­Script-Web­site im Ver­gleich zu einer HTML-Web­sei­te von glei­cher grö­ße etwa das hun­dert­fa­che an Res­sour­cen benö­tigt um geren­dert zu werden.

Aus die­sem Grund ist es sehr unwahr­schein­lich, dass ande­re Such­ma­schi­nen mit eige­nen Ren­de­ring-Engi­nes nach­zie­hen werden.

Um auf den nächs­ten Abschnitt die­ses Bei­tra­ges zu Bli­cken, lohnt sich eine kur­ze Zusam­men­fas­sung der bis hier erläu­ter­ten Erkenntnisse:

  • Java­Script wird vom Brow­ser aus­ge­führt, nicht vom Ser­ver. Die­se Auf­ga­be (ren­dern) muss der Craw­ler über­neh­men, um Inhal­te die durch Java­Script aus­ge­führt wer­den zu craw­len und zu indexieren.
  • Ein Head­less-Brow­ser beschreibt rela­tiv genau, wie ein Craw­ler mit einer Web­sei­te interagiert.
  • Der Goog­le­bot ver­wen­det zum Ren­dern von Web­sei­ten den Web Ren­de­ring Ser­vice (WRS) wel­ches immer auf der aktu­ells­ten Goog­le Chro­me Brow­ser Ver­si­on basiert. Goog­le arbei­tet bereits an einem Upate
  • Fea­tures und Tech­no­lo­gien des Goog­le­bots sind damit auf dem Stand vom Jahr 2015
  • Die Deve­lo­per-Tools des Goog­le Chro­me Brow­ser kann neben dem „Url-Prüfen“-Tool der Goog­le Search Con­so­le für Debug­ging und Tes­ting von Java­Script ver­wen­det werden.
  • Das HTTP/2 Trans­fer Pro­to­koll wird nicht unter­stützt. Da es aber abwärts­kom­pa­ti­bel ist, soll­te es kein Pro­blem darstellen.
  • WebSo­cket-Pro­to­koll, Inde­xedDB und WebS­QL- Inter­faces wer­den nicht unterstützt.
  • Der Goog­le­bot inter­agiert unter­schied­lich mit ver­schie­de­nen JavaScript-Frameworks.
  • Bis auf Goog­le, ren­dert kein ande­rer Such­ma­schi­nen-Craw­ler JavaScript.
  • Goo­g­les Inde­xer (Caff­e­in) ist für das Ren­de­ring geant­wort­lich, nicht der Craw­ler (Goog­le­bot)
  • Goog­le ren­dert beim ers­ten Besuch einer Url Java­Script nicht, son­dern Inde­xiert alles was ohne Ren­de­ring vor­han­den ist.
  • Ledig­lich Goog­le ren­dert Java­Script. Ande­re Craw­ler von Such­ma­schi­nen oder sozia­len Netz­wer­ken nicht.
  • Das Ren­dern von Java­Script ist auch für Goog­le Ressourcenintensiv

Da nun die Grund­prin­zi­pi­en von Java­Script und die dadurch ent­ste­hen­den Schwie­rig­kei­ten bezüg­lich SEO bekannt sind, geht es in die­sem Teil um hilf­rei­che Tools von Goog­le aber auch exter­ne Anbie­ter um Java­Script und SEO unter einen Hut zu bekommen.

Auditing mit Google Chrome von JavaScript-Webseiten
Abbil­dung 10: Audi­t­ing von Java­Script-Web­sei­ten mit Chro­me Browser

Da das Ren­de­ring auf Basis des Chro­me Brow­sers (WRS) basiert, eig­net sich der haus­ei­ge­ne Brow­ser von Goog­le als Go-To Tes­ting­tool. Beson­ders die Kon­so­le der Java­Script-Feh­lern kann Aus­künf­te über Feh­ler und War­nun­gen geben. Beson­ders inter­es­sant ist die Betrach­tung des geren­der­ten Codes.

Gerenderten Quellcode einsehen und analysieren
Abbil­dung 11: Geren­der­ten Quell­code ein­se­hen und analysieren

Um Java­Script-Basie­ren­de Web­sei­ten für SEO zu ana­ly­sie­ren, muss nur ein klei­ner Teil von Java­Script betrach­tet wer­den. Im fol­gen­den Abschnitt wird ver­ein­facht dar­ge­stellt, was pas­siert, wenn der Goog­le­bot eine Java­Script-Basie­ren­de Web­sei­te besucht.

Um die­sen Ablauf zu simu­lie­ren, wird das inte­grier­te Deve­lo­per Tool im Goog­le Chro­me Brow­ser genutzt.

  1. 1.
    In einen „lee­ren Bereich“ der Web­sei­te rechts-kli­cken und „Unter­su­chen“ auswählen
  2. 2.
    Um den gesam­ten Inhalt zu erhal­ten, den HTML-Tag im rech­ten Bereich des Brow­sers auswählen
  3. 3.
    Mit einem Rechtsklick auf den HTML-Tag auf „Copy“ und „Copy OuterHTML“ navi­gie­ren um den gesam­ten Inhalt zu kopieren
  4. 4.
    Der kopier­te HTML-Code kann nun in Text­pro­gramm ein­ge­fügt wer­den, um den Inhalt ein­zu­se­hen und zu analysieren

Die­ser Vor­gang kann auch ver­wen­det wer­den, um den Inhalt einer Java­Script-Basie­ren­den Web­sei­te auf OnPage-Fak­to­ren zu überprüfen.

Url Überprüfungs-Tool - Google Search Console
Abbil­dung 12: Url-Prü­fungs-Tool – Goog­le Search Console

Nahe­lie­gend ist es natür­lich, das „Url-Prü­fungs-Tool“ der Goog­le Search Con­so­le zu nut­zen. Sehr hilf­reich ist hier der Live-Test des Url-Prü­fungs-Tools. Neben dem geren­der­ten HTML-Code und einem Screen­shot von der geren­der­ten Web­sei­te erhält man wei­te­re Infor­ma­tio­nen, die vor­al­lem für das Hand­ling mit Java­Script sehr hilf­reich sein können.

Hier­bei soll­te aber dar­auf geach­tet wer­den, dass das Tool der Goog­le Search Con­so­le ledig­lich Aus­künf­te dar­über gibt, ob eine Web­sei­te tech­nisch geren­dert wer­den kann oder bezüg­lich Java­Script Pro­ble­me beim craw­len auf­tre­ten. Time­outs und Per­for­mance-Ansprü­che des Goog­le­Bots wer­den hier nicht berücksichtigt.

Des­we­gen ist es immer zu Emp­feh­len eine Site-Abfra­ge inkl. Aus­schnitt des zu über­prü­fen­den Tex­tes zu star­ten, um wirk­lich sicher zu gehen.

Site-Abfrage mit Text Auszug in der Google-Suche um zu testen ob Inhalte indexiert werden können
Abbil­dung 13: Site-Abfra­ge mit Text Aus­zug in der Goog­le-Suche um zu tes­ten ob Inhal­te inde­xiert wer­den können

Um wirk­lich sicher gehen zu kön­nen, ob Inhal­te gecrawlt und inde­xiert wer­den kön­nen, ist eine Site-Abfra­ge not­wen­dig. Hier­für kann fol­gen­de Such­an­fra­ge genutzt werden:

Site:deinedomain.de/deineseite „Zu tes­ten­der Textauszug“

Auch wenn eine Url im Index ist, bedeu­tet es nicht, dass alle Inhal­te ein­wand­frei inde­xiert wur­den. Nur mit der Site-Abfra­ge in der Goog­le Suche kann zu 100% sicher­ge­stellt wer­den, ob Goog­le die Inhal­te indexiert.

DOM Betrachtung mit dem Google Mobile Friendly Tester
Abbil­dung 14: Betrach­tung des DOM mit dem Goog­le Mobi­le Friend­ly Tester

Vor der Ein­füh­rung des „Url-Über­prü­fungs-Tool“ wur­de der „Mobi­le Friend­ly Tes­ter“ emp­foh­len, da laut eige­nen Aus­sa­gen von Goog­le (John Muel­ler) das bereits abge­schaf­te Fetch and Ren­der Tool der Goog­le Search Con­so­le eini­ge Schwä­chen auf­wies, wenn es um die Betrach­tung des DOM geht. Des­we­gen wur­de der Mobi­le Friend­ly Tes­ter oder der Goog­le Rich Media Tes­ter emp­foh­len. Ver­än­de­run­gen die durch Java­Script am DOM nach­träg­lich vor­ge­nom­men oder CSS-Anwei­sun­gen die z.B. durch Resi­zing ver­ur­sacht wer­den, kön­nen mit dem Mobi­le Friend­ly Tes­ter dar­ge­stellt werden.

Dank des „Url-Über­prü­fungs-Tool“ der Goog­le Search Con­so­le ist der „Mobi­le Friend­ly Tes­ter“ nicht unbe­dingt not­wen­dig, kann aber auch zusätz­lich genutzt wer­den. Inter­es­sant ist die­ses Tool vor­al­lem, um sich exter­ne Sei­ten anzu­schau­en, deren Goog­le Search Con­so­le Zugang nicht vor­han­den ist.

Der Einsatz des SEO Spider Screaming Frog zum rendern von JavaScript-Webseiten
Abbil­dung 15: Der Ein­satz des Screa­ming Frog SEO Spi­der zum ren­dern von JavaScript-Webseiten

Eine Hil­fe­stel­lung bie­tet der Screa­ming Frog SEO Spi­der. Die­ser Craw­ler bie­tet bereits die Funk­ti­on, Java­Script zu ren­dern und erstellt ähn­lich wie der Goog­le­bot einen Screen­shot der Web­sei­te nach dem Load-Event.

Unter dem Menü­punkt „Con­fi­gu­ra­ti­on » Spi­der » Ren­de­ring“ kann hier der Punkt „Java­Script“ aus­ge­wählt wer­den. Nach dem erfolg­rei­chen craw­len der Web­sei­te kann jede URL als „Ren­de­red Page“ betrach­tet wer­den. Die­ser Screen­shot kann bereits ers­te Auf­schlüs­se dar­über geben, ob es Pro­ble­me beim Ren­dern der Web­sei­te gibt. Zu beach­ten ist, dass die­se Funk­ti­on ledig­lich in der Paid-Ver­si­on des Screa­ming Frog SEO Spi­ders ver­füg­bar ist.

Obwohl sich der Srea­ming Frog SEO Spi­der ähn­lich die der Goog­le­bot ver­hält, ist lei­der damit nicht gewähr­leis­tet, ob der Goog­le­bot exakt so ver­fährt und die­se Sei­te genau­so geren­dert wird.

Des Wei­te­ren ist vom Screa­ming Frog SEO Spi­der bekannt, dass die­ser zwar die Ren­de­ring-Engi­ne „Blink“ vom Chro­mi­um Pro­ject nutzt, die­se sich aber von der des Goo­gel­bots (WRS) unter­schei­det. Außer­dem benö­tigt das Ren­dern (inkl. AJAX Time­out von 5 Sekun­den) von Java­Script mit dem Screa­ming Frog SEO Spi­der gro­ße Res­sour­cen, was das Craw­len von Java­Script-Sei­ten mit mehr als 100.000 Urls qua­si unmög­lich macht.

Ryte Business Suite JavaScript Crawling
Abbil­dung 16: Ryte Busi­ness Suite – High-Per­for­mance Craw­ler mit JavaScript-Crawling

Ryte bie­tet in der Busi­ness Suite für Ihre Kun­den eben­falls die Mög­lich­keit, Web­sei­ten mit dem High-Per­for­mance Craw­ler mit Java­Script Craw­ling zu ana­ly­sie­ren. Ryte nutzt beim Craw­ling den Goog­le Chro­me und ver­sucht immer mög­lichst nah an der neus­ten Ver­si­on zu blei­ben. Dies ist natür­lich bei Rich-JS-Web­sei­ten sehr hilf­reich um eine aus­führ­li­che OnPage-Ana­ly­se zu bekom­men, da ohne Java­Script-Craw­ling der Craw­ler nicht sehen könnte.

Die erweiterten Einstellungen der Ryte Business Suite zum JavaScript-Crawling.
Abbil­dung 17: Ryte Busi­ness Suite – Erwei­ter­te Anayl­se-Ein­stel­lin­gen für JavaScript-Crawling

Wir haben das gro­ße Glück den CO-Foun­der und Co-Geschäfts­füh­rer per­sön­lich zu ken­nen, der wohl am bes­ten erklä­ren kann was der neue Ryte High-Per­for­mance Craw­ler mit Java­Script Craw­ling drauf hat:

Hal­lo Mar­cus, super, dass du Zeit gefun­den hast, um uns ein paar Fra­gen zu eurem neu­en JS-Craw­ler zu beant­wor­ten. Stell dich doch bit­te kurz vor, wer du bist und was du bei Ryte machst.

Hal­lo, ich bin Mar­cus und ich lie­be SEO 🙂
Ich bin Co-Grün­der und Co-Geschäfts­füh­rer von Ryte und neben mei­nen Auf­ga­ben als Geschäfts­füh­rer bin ich vor allem auch SEO Spar­rings­part­ner für unse­re akti­ven und poten­ti­el­len Busi­ness Suite Kunden.

 

Ryte Gründer Marcus Tandler kennt sich mit JavaScript aus.
Mar­cus Tand­ler, Co-Grün­der & Co-Geschäfts­füh­rer, Ryte

Wel­che Ren­de­ring-Engi­ne nutzt ihr um Java­Script aus­zu­füh­ren und wird es in Zukunft auch eine Funk­ti­on geben, um zwi­schen unter­schied­li­chen Engi­nes zu wechseln?

Wir ver­wen­den Goog­le Chro­me und ver­su­chen immer mög­lichst nah an der neu­es­ten Ver­si­on zu blei­ben. Der Wech­sel der Engi­nes ist nicht mög­lich und auch der­zeit nicht geplant. Aber kom­plett aus­ge­schlos­sen ist es natür­lich auch nicht.

 

Euer JS-Craw­ler hat etwas auf sich war­ten las­sen. Wel­che Her­aus­for­de­run­gen bzw. Ansprü­che hat­te ihr beson­ders an euren Craw­ler, wenn es um das Ren­de­ring von Java­Script geht?

Unse­re Ansprü­che haben wir für uns von Anfang an klar for­mu­liert:
1) Sta­bil
2) Ska­lier­bar
3) Wirt­schaft­lich
4) Unab­hän­gig vom Java­Script Frame­work
5) Ergeb­nis­se wie ein moder­ner Brow­ser aus­ge­ben
6) Kein “3rd par­ty ren­de­ring”
7) Hohe Performance

Die Her­aus­for­de­run­gen für uns sahen dabei fol­gen­der­ma­ßen aus:
1) Wel­che Engi­ne ver­wen­den wir?
Die Engi­ne soll­te mög­lichst nah an einem Brow­ser sein, soll­te alle Java­Script Frame­works unter­stüt­zen, mög­lichst per­for­mant und durch Soft­ware steu­er­bar sein. Hier waren wir mit viel Recher­che und Pro­to­typ­ing kon­fron­tiert.
2) Wie kön­nen wir ver­teilt (dis­tri­bu­t­ed), ska­lier­bar (sca­le­ab­le) und belast­bar (resi­li­ent) bau­en und trotz­dem wirt­schaft­lich blei­ben?
3) Wie kann man die Res­sour­cen­nut­zung (RAM, CPU) von Chro­me redu­zie­ren?
4) Java­Script an sich ist eine gro­ße Her­aus­for­de­rung, da es vie­le Pro­ble­me gibt, die man nur durch Tes­ten her­aus­fin­den kann. Ein kur­zes Bei­spiel: Wie behan­delt man window.location Ände­run­gen ohne Infor­ma­tio­nen zu ver­lie­ren? Vie­le die­ser Fra­ge­stel­lun­gen sind initi­al gar nicht unbe­dingt auf der Agen­da bis sie dann zum ers­ten Mal tat­säch­lich auf­tre­ten.
5) Die Lade­zei­ten von Java­Script Sei­ten sor­gen für einen lang andau­ern­den Crawl. Hier galt es, mög­lichst schnell unter­wegs zu sein, um von Anfang an eine hohe Per­for­mance aufzuweisen.

 

Für wie wich­tig hal­tet ihr es, dass euer Craw­ler so nah wie mög­lich an der Tech­no­lo­gie von Goog­le ange­lehnt ist, um Web­sei­ten zu crawlen?

Goog­le ist schlicht­weg die bedeu­tends­te Such­ma­schi­ne für unse­re Ziel­märk­te. Damit macht es natür­lich Sinn, sich tech­no­lo­gisch an Goog­le zu ori­en­tie­ren. Dar­über hin­aus hat Goog­le auch für unser Tool eine hohe Bedeu­tung, da wir auf den Ein­satz von 100% ech­ten Goog­le Daten set­zen, um die Such­rea­li­tät abbil­den zu können.

 

Kannst du jetzt schon etwas zu kom­men­den Fea­tures rund um das The­ma Java­Script SEO für Ryte erzählen?

Wir pla­nen kei­ne expli­zi­ten Java­Script Fea­tures in den nächs­ten Mona­ten. Was wir aber berück­sich­ti­gen wer­den, sind Fea­tures, die auf Basis des Ren­de­ring umsetz­bar sind. Wir haben da eine Men­ge span­nen­der, neu­ar­ti­ger Ideen 🙂

Don’t just do it. Do it Ryte!

 

Dan­ke, dass du dir die Zeit genom­men hast, unse­re Fra­gen zu beant­wor­ten. Wir freu­en uns auf die wei­te­re Ent­wick­lung eurer Produkte.

Searchmetrics JavaScript Crawling
Abbil­dung 18: Search­metrics Suite – Chro­me- und Phan­tom­JS-basier­tes JavaScript-Crawling

Die Search­metrics Suite bie­tet mit der Site-Opti­miz­a­ti­on ein Java­Script-Craw­ling an, wel­ches auf dem Goog­le Chro­me und Phan­tom­JS basiert. Damit bie­tet die­ses Tool ein prak­ti­sches Werk­zeug um SEO-Ver­ant­wort­li­chen die Arbeit zu erleich­tern. Wir durf­ten uns das Tool bereits anschau­en und aus­gie­big tes­ten. Bei den Craw­ling-Ein­stel­lun­gen kann bereits gewählt wer­den, ob der Craw­ler Java­Script mit­be­rück­sich­ti­gen soll. Da Search­metrics bei die­sem Crawl Java­Script aus­führt, kann die Web­sei­te hin­sicht­lich OnPage-Fak­to­ren wie jede her­kömm­li­che Web­sei­te betrach­tet wer­den, was einen gro­ße Hil­fe für SEO-Ver­ant­wort­li­che bietet.

Searchmetrics Suite - Crawler Einstellungen
Abbil­dung 19: Search­metrics Suite – Craw­ler Einstellungen

Freund­li­cher­wei­se stand uns der Direc­tor für Pro­duct Mar­ke­ting & Solu­ti­ons, Mal­te Land­wehr für ein kur­zes Inter­view zur Ver­fü­gung, um unse­re Fra­gen zu Search­metrics Java­Script-Craw­ler zu beantworten:

Hal­lo Mal­te, super, dass du Zeit gefun­den hast, um uns ein paar Fra­gen zu eurem neu­en JS-Craw­ler zu beant­wor­ten. Stell dich doch bit­te kurz vor, wer du bist und was du bei Search­metrics machst.

Ich lei­te bei Search­metrics die Berei­che Pro­duct Mar­ke­ting und Pro­duct Solu­ti­ons. Mein Team sorgt dafür, dass wir in der Pro­dukt­ent­wick­lung an den rich­ti­gen The­men arbei­ten und dass unse­re Kun­den maxi­mal von unse­ren Soft­ware­in­no­va­tio­nen profitieren.

Searchmetrics Director Product & Marketing & Solutions Malte Landwehr
Mal­te Land­wehr, Direc­tor Pro­duct Mar­ke­ting & Solu­ti­ons, Searchmetrics

Und dann beschäf­ti­gen wir uns noch mit einer Mil­li­on ande­rer Din­ge wie Go-to-Mar­ket-Stra­te­gien, Release-Manage­ment, Pri­cing, Pack­a­ging, Sales Col­la­te­ral, RFPs, usw.

Ich selbst wursch­tel seit mehr als 10 Jah­ren im Online Mar­ke­ting rum. Anfangs als Hob­by, dann als Affi­lia­te, Blog­ger und Free­lan­cer. Dann war ich noch CoFoun­der einer SEO-Agen­tur in Müns­ter und auf Kre­ta und hat­te einen kur­zen Aus­flug in die Wis­sen­schaft als ich mich für die Uni Müns­ter, IBM, die DFG, die Voda­fone Stif­tung und die Kon­rad Ade­nau­er Stif­tung mit Social Net­work Ana­ly­sis und dem poli­ti­schen Dis­kurs auf Twit­ter beschäf­tigt habe. Zuletzt war ich Unter­neh­mens­be­ra­ter und bin jetzt seit fast drei 3 Jah­ren bei Searchmetrics.

Wenn ich mich mal nicht mit SEO beschäf­ti­ge, gehe ich mei­ner Kind­le- und Net­flix-Sucht nach.

 

Wie­so ist es eurer Mei­nung nach beim Craw­len von Web­sei­ten wich­tig, auch Java­Script zu rendern?

Java­Script erlaubt es Web­sites mit viel bes­se­rer User-Expe­ri­ence zu erstel­len als dies mit rei­nem HTML und CSS der Fall ist. Fast alle moder­nen Web­sites basie­ren heu­te auf Angu­lar, React oder einem der vie­len ande­ren Java­Script-Frame­works. Aus der moder­nen Web­ent­wick­lung ist Java­Script ein­fach nicht mehr wegzudenken.

Da auch Goog­le Java­Script teil­wei­se ver­steht, ist es wich­tig bei der SEO-Bewer­tung von Web­sites auch DOM-Ände­run­gen zu berück­sich­ti­gen, die nicht im puren HTML-Code ste­hen son­dern durch Java­Script aus­ge­löst wer­den. Wenn eine Web­site via Java­Script den Tit­le-Tag ändert und Inhal­te nach­lädt – und dies auf eine Art und Wei­se tut, die der Goog­le Bot ver­steht – dann muss auch ein SEO-Craw­ler die­se Ände­run­gen ver­ste­hen um eine rea­lis­ti­sche SEO-Bewer­tung abzugeben.

 

Wel­che Ren­de­ring-Engi­ne nutzt ihr um Java­Script aus­zu­füh­ren und wird es in Zukunft auch eine Funk­ti­on geben, um zwi­schen unter­schied­li­chen Engi­nes zu wechseln?

Wir arbei­ten mit Chro­me und Phan­tom­JS. Chro­me ist natür­lich näher am Goog­le Bot, der aktu­ell auf dem Goog­le Chro­me basiert. Phan­tom­JS hat den Vor­teil, dass sich damit auch Web­sites craw­len las­sen, mit denen Goog­le Chro­me nicht klar kommt.

Da wir als agi­le Soft­ware Com­pa­ny nicht mit star­ren Road­maps arbei­ten, spre­che ich ungern über even­tu­el­le zukünf­ti­ge Funk­tio­nen. Ich kann so viel ver­ra­ten: Java­Script-Craw­ling ist ein sehr wich­ti­ges The­ma für uns und wir machen uns inten­siv Gedan­ken was für unse­re Kun­den am bes­ten ist.

 

Für wie wich­tig hal­tet ihr es, dass euer Craw­ler so nah wie mög­lich an der Tech­no­lo­gie von Goog­le ange­lehnt ist, um Web­sei­ten zu crawlen?

Das hal­te ich für abso­lut essen­ti­ell um Kun­den genau auf­zei­gen zu kön­nen, wie gut ihre Web­site für Goog­le opti­miert ist.

Aller­dings geht unser Craw­ling-Anspruch etwas wei­ter als nur die Opti­mie­rung für Such­ma­schi­nen. Kaput­te Links kön­nen eine Aus­wir­kung auf die User Expe­ri­ence haben. Für eine Java­Script-las­ti­ge Shop­ping-Web­site kann es also durch­aus ein Mehr­wert sein, wenn wir die Sei­te wie ein Mensch craw­len und nicht wie Google.

 

Nach offi­zi­el­len Aus­sa­gen der Such­ma­schi­nen-Kon­zer­ne, ist aktu­el­le nur Goog­le in der Lage, Java­Script zu ren­dern. Sobald ande­re Such­ma­schi­nen nach­zie­hen, wer­den die­se sicher­lich ihre eige­nen Tech­no­lo­gien ein­set­zen. Wie weit wird das in eurem Craw­ler mit­be­rück­sich­tigt wer­den, wenn es soweit ist?

Wir unter­stüt­zen aktu­ell in der Search­metrics Suite ein knap­pes Dut­zend Such­ma­schi­nen. Neben Goog­le, Yahoo, Bai­du und Yandex auch so Exo­ten wie Qihoo 360 und Sogou. In Ame­ri­ka und Euro­pa ist aber für eigent­lich jeden Kun­den Goog­le das Maß der Din­ge. Die meis­ten SEOs die ich ken­ne, prü­fen nie wie Bing und Yahoo mit Noin­dex, Nofol­low oder der robots.txt umge­hen. An die­sem Goog­le-Fokus wird mei­ner Mei­nung nach auch Java­Script-Craw­ling nichts ändern.

Da Micro­soft hoch­wer­ti­ge Pro­gres­si­ve Web Apps über den Bing Craw­ler auf­spü­ren und über den Micro­soft Store direkt in Win­dows ver­füg­bar machen möch­te, wer­den wir sicher in Zukunft deut­lich mehr Java­Script Craw­ling aus dem Hau­se Micro­soft sehen. Und damit wird das The­ma Java­Script-Craw­lin­g/P­WA-Craw­ling dann auch deut­lich über den SEO-Tel­ler­rand hin­aus span­nend! Denn es ist ver­mut­lich nicht der Head of SEO, der sich damit befasst ob die eige­ne PWA gut in Win­dows 10 funk­tio­niert und wie sie im Win­dows Store gelis­tet wird.

 

Dan­ke, dass du dir die Zeit genom­men hast, unse­re Fra­gen zu beant­wor­ten und vie­len Dank, dass wir euren Craw­ler aus­gie­big tes­ten durf­ten. Wir freu­en uns auf die wei­te­re Ent­wick­lung eurer Produkte.

Um auf den nächs­ten Abschnitt die­ses Bei­tra­ges zu Bli­cken, lohnt sich eine kur­ze Zusam­men­fas­sung der bis hier erläu­ter­ten Erkenntnisse:

  • Mit dem Goog­le Chro­me Brow­ser in der aktu­el­len Ver­si­on wer­den Web­sei­ten mit den sel­ben Fea­tures geren­dert. Damit ein sehr wich­ti­ges Testing-Tool
  • Die Chro­me Deve­lo­per Tools ermög­li­chen den geren­der­ten Code dar­zu­stel­len und Feh­ler beim Ren­de­ring zu identifizieren
  • Der Live-Test im „Url-Überprüfen“-Tool hilft beim Audi­t­ing von Feh­lern und zur Betrach­tung des von Goog­le geren­der­ten Code
  • Ledig­lich eine Site-Abfra­ge in dern Goog­le-Suche gibt vali­de Aus­sa­gen ob Inhal­te inde­xiert wurden
  • Neben der Goog­le Search Con­so­le dient Goo­g­les Mobi­le Friend­ly Tes­ter als Aud­ting-Tool. Beson­ders bei exter­nen Web­sei­ten ohne Zugriff auf die GSC
  • Der Screa­ming Frog SEO Spi­der mit einer eige­nen Ren­de­ring Engi­ne eige­net sich gut für klei­ne­re Webseiten
  • Mit dem Ryte High-Per­for­mance Craw­ler mit Java­Script Cralwing kön­nen auch OnPage-Ana­ly­sen erstellt wer­den, trotz Cli­ent-Side-Ren­de­ring JavaScript
  • Search­metrics bie­tet in ihrer Suite eben­falls die Mög­lich­keit Web­sei­ten mit Cli­ent-Side-Ren­de­ring Java­Script zu crawlen

Im Fol­gen­den wer­den die wich­tigs­ten Emp­feh­lun­gen und Best Prac­ti­ce Bei­spie­le erklärt, um Java­Script und SEO am bes­ten zu ver­hei­ra­ten. Vie­le der Tipps stam­men direkt von Goog­le und sol­len hel­fen gro­be Feh­ler zu vermeiden

Load Event und User Event für die Verwendung von wichtigen Inhalten
Abbil­dung 20: Load Event und User Event für die Ver­wen­dung von wich­ti­gen Inhalten

Da Goog­le den geren­der­ten Quell­code direkt nach dem Load-Event crawlt, wer­den alle dyna­mi­schen Inhal­te die wäh­rend bzw. nach einem User-Event gela­den wer­den, gänz­lich igno­riert. Der Load-Event ist been­det, wenn die Sei­te kom­plett gela­den wur­de. Hier­bei soll­te beach­tet wer­den, dass der Goog­le­bot nach etwa 5 Sekun­den einen Screen­shot der Web­sei­te erstellt. Alle wich­ti­gen Inhal­te soll­ten in die­ser Zwi­schen­zeit gela­den sein.

User-Events füh­ren dazu, dass Java­Script den Quell­code einer Web­sei­te ver­än­dert. Dies kann eben­falls mit dem inte­grier­ten Deve­lo­per Tool im Goog­le Chro­me Brow­ser simu­liert und ver­an­schau­licht wer­den. Ein User-Event kann z.B. ein Klick (onClick) auf einen Tab sein, der wei­te­re Inhal­te zum Vor­schein bringt. Aus die­sem Grund ist es wich­tig, dass alle wich­ti­gen Inhal­te die von Goog­le gecrawlt wer­den sol­len, auf der Sei­te dar­ge­stellt wer­den, ohne das eine Inter­ak­ti­on des Web­sei­ten­be­su­chers not­wen­dig ist.

Es konn­te wei­ter beob­ach­tet wer­den, dass Goog­le auch Inhal­te inde­xiert, die erst durch ein User-Event erstellt wer­den. Der Grund dafür kann sein, dass ein Head­less-Brow­ser auch durch Befeh­le mit der Web­sei­te inter­agie­ren kann. Hier war kein kla­res Mus­ter zu erken­nen, da ande­re Inhal­te gänz­lich igno­riert wur­den. Des­we­gen die Emp­feh­lung, alle wich­ti­gen Inhal­te bereit­zu­stel­len ohne die Not­wen­dig­keit eines User-Events.

Wie oben bereits erwähnt, dient das Url-Über­prü­fen-Tool der Search Con­so­le und der Goog­le Chro­me als vali­de Quel­len für das Tes­ting und Debug­ging von Java­Script für SEO. Trotz des­sen, konn­ten beim Tes­ting unter­schied­li­che Ergeb­nis­se zwi­schen dem Url-Über­prü­fen-Tool dem tat­säch­li­chen Ren­de­ring­ver­hal­ten des Googlebots.

Dies lag vor­al­lem dar­an, dass der Goog­le­bot nach 5 Sekun­den einen Screen­shot der Web­sei­te erstellt. Damit wer­den alle Inhal­te, die erst nach den 5 Sekun­den geren­dert wur­den, nicht unbe­dingt inde­xiert. Dar­auf soll­te beim Tes­ting unbe­dingt geach­tet werden.

Die­ses Tat­sa­che bestä­tigt ein span­nen­des Expe­ri­ment von Tomasz Rud­zi im Ele­pha­te-Blog der mit dem dama­li­gen „Fetch and Ren­der Tool“ der Goog­le Search Con­so­le wel­ches bereits vom „Url-Über­prü­fungs-Tool“ abge­löst wur­de, zeigte.

In die­sem Expe­ri­ment wur­den Text­in­hal­te über Java­Script erzeugt, die aber erst nach 2 Minu­ten auf der Web­sei­te sicht­bar waren. Bei der Betrach­tung im Fetch and Ren­der Tool der Goog­le Search Con­so­le wur­den die­se Inhal­te, die mit einer Ver­zö­ge­rung von 2 Minu­ten vom Java­Script erzeugt wur­den, ein­wand­frei dar­ge­stellt. Bei der Betrach­tung einer Site-Abfra­ge konn­te aber fest­ge­stellt wer­den, dass er Inde­xer nicht so gedul­dig war. Die ver­zö­ger­ten Inhal­te wur­den von Goog­le nicht indexiert.

Empfehlung von Google für Verlinkung von Urls mit JavaScript
Abbil­dung 22: Emp­feh­lung von Goog­le für Ver­lin­kung von Urls mit JavaScript

Für die URL-Struk­tur soll­ten bei Java­Script-Basie­ren­den Web­sei­ten ein paar Punk­te beach­tet wer­den. Es ist wich­tig sicher­zu­stel­len, dass beim Auf­ruf von Sei­ten jeweils neue URLs auf­ge­ru­fen wer­den. Das bedeu­tet, dass jeder Sei­te einer Domain eine eige­ne URL zuge­ord­net wird.

Des Wei­te­ren soll­ten alle eigen­stän­di­gen URLs ohne Hash „#“ rea­li­siert wer­den, da Goog­le die Anga­ben in der URL nach dem „#“ igno­riert. Dies führt dazu, dass Goog­le alle inter­nen Ver­lin­kun­gen als Links zur Start­sei­te iden­ti­fi­zie­ren wür­de und kei­nen wei­te­ren Links fol­gen wür­de. Für Sprung­mar­ken kann ein Hash „#“, wie auch bei her­kömm­li­chen Web­sei­ten, ver­wen­det wer­den. Zu emp­feh­len sind auch bei Java­Script-Basie­ren­den Web­sei­ten „spre­chen­de“ URLs.

Um dem Goog­le­bot das craw­len von Links zu ermög­li­chen, soll­ten alle Links über den HTML A‑Tag rea­li­siert wer­den. Auch hier soll­te dar­auf geach­tet wer­den, dass die­se Links nicht durch ein User-Event (z.B. onClick) auf­ge­ru­fen werden.

Des Wei­te­ren soll­te dar­auf geach­tet wer­den, dass push­Sta­te-Feh­ler ver­mie­den wer­den, damit die ori­gi­nal URL mit ser­ver­sei­ti­ger Unter­stüt­zung wei­ter­ge­ge­ben wird.

Im Hin­blick auf das „Second Wave of Index­ing“ soll­ten vor­al­lem Cano­ni­cal-Tags im Head-Bereich bereits crawl­bar sein, ohne das Java­Script geren­dert wer­den muss. Goog­le selbst gibt die­se Empfehlung:

Twitter User @JohnMu schreibt, dass Google bislang nur rel=canonical bei der nicht gerenderten Seite verarbeitet

Span­nend zu die­sem The­ma ist das Expe­ri­ment von Eoghan Henn, der ver­sucht hat Cano­ni­cal-Tags per Java­Script aus­zu­spie­len. Das Ergeb­niss war, dass Goog­le wohl doch die knao­ni­sis­er­ten Urls inde­xiert hat, aber erst nach 34 Tagen. Die­ses Expe­ri­ment zeigt noch­mal, wie lan­ge es dau­ern kann, bis Goog­le Inhal­te die durch Java­Script erzeugt wer­den ver­ar­bei­tet und inde­xiert. Daher kla­re Emp­feh­lung: Cano­ni­cal-Tags ohne not­we­ni­ges Ren­dern von Java­Script ausgeben.

Wie bereits im obe­ren Abschnitt erwähnt wur­de, sind Craw­ler von ande­ren Such­ma­schi­nen und sozia­len Netz­wer­ken noch nicht in der Lage, Java­Script zu ren­dern. Um die­sen Craw­lern wich­ti­ge Infor­ma­tio­nen wie Tit­le-Tag, Meta-Descrip­ti­on, Can­no­ni­cal-Tag, Meta-Robots-Anga­ben und wenn vor­han­den Open­Graph-Anga­ben bereit zu stel­len, soll­ten die­se Inhal­te ohne vor­her geren­dert wer­den zu müs­sen, im Head-Bereich der Web­sei­te auf­ruf­bar sein.

Goog­le selbst emp­fiehlt für struk­tu­rier­te Daten bei Java­Script-Basie­ren­den Web­sei­ten den Ein­satz von JSON-LD. All­ge­mein emp­fiehlt sich der Ein­satz von JSON-LD für alle Arten von Webseiten.

Vorgabe von Google für Lazy Loading mit JavaScript
Abbil­dung 23: Vor­ga­be von Goog­le für Lazy Loading mit JavaScript

Beim Ein­satz von Lazy-Loading für Bil­der gibt Goog­le kla­re Emp­feh­lun­gen die­se ent­we­der über ein Noscript oder über schema.org mit­tels JSON-LD zu lösen. Ähn­lich wie bei der Vor­ga­be von Ver­lin­ken ist es, dass die Url des Bil­der direkt ohne nöti­ges Ren­de­ring im Quell­code vor­han­den ist.

Altes AJAX Crawling Schema wird eingestellt
Abbil­dung 24: Goog­le stellt das Craw­len nach dem alten AJAX Craw­ling Sche­ma einstellen

Goog­le das Craw­len nach altem AJAX-Sche­ma bereits 2018 ein­stellt. Johan­nes Mül­ler hat­te in einem Web­mas­ter-Han­gout mit­ge­teilt, dass kei­ne Escaped-Frag­ment-URLs wie „/page?query&_escaped_fragment=key=value“ mehr auf­ge­ru­fen würden.

Die Such­ma­schi­ne Bing hin­sicht­lich unter­stützt wei­ter­hin das AJAX-Schema.

Zur Über­sicht wur­den hier noch­mals alle Best-Prac­ti­ce-Bei­spie­le zusammengefasst:

  • Ana­ly­se vom Quell­code (Pre-DOM) reicht nicht aus, da erst der geren­der­te Code alle Inhal­te anzeigt
  • Inhal­te müs­sen nach dem Load-Event dar­ge­stellt wer­den. Inhal­te die durch ein User-Event erzeugt wer­den, kön­nen nicht inde­xiert werden
  • Such­ma­schi­nen­re­le­van­te Inhal­te soll­ten inner­halb von 5 Sekun­den geren­dert und gela­den sein
  • Beim Auf­ruf einer Sei­te muss eine eige­ne Url mit ser­ver­sei­ti­ger Unter­stüt­zung erzeugt werden
  • Kein Ein­satz von Hash (#) in der Url, da alles was nach einem Hash folgt, vom Craw­ler gänz­lich igno­riert wird
  • push­Sta­te-Feh­ler soll­ten ver­mie­den wer­den, damit die ori­gi­nal URL mit ser­ver­sei­ti­ger Unter­stüt­zung wei­ter­ge­ge­ben wird
  • Links über a‑href rea­li­sie­ren und nicht durch User-Events (z.B. onClik) erzeu­gen lassen
  • Cano­ni­cal-Tags soll­ten ohne not­we­ni­ges Ren­dern von Java­Script im Hea­der gela­den werden
  • Beim Ein­satz von Lazy Loading für Bil­der muss der Datei­na­me im Quell­code vor­han­den sein
  • Struk­tu­rier­te Daten soll­ten mit JSCON-LD rea­li­siert werden
  • Goog­le hat das Craw­ling vom AJAX-Sche­ma 2018 eingestellt.

Nach­dem bereits alle wich­ti­gen Pro­ble­ma­ti­ken Hin­sicht­lich Java­Script und SEO auf­ge­klärt wur­den, dass kein SEO-Ver­ant­wort­li­cher mit einer Rich-JS-Web­sei­te 100% sicher gehen kann, dass sei­tens der Such­ma­schi­ne alles ein­wand­frei abläuft. Hier kommt das The­ma „Pre­ren­de­ring“ ins Spiel. Was das genau ist, wie­so es für SEO-Ver­ant­wort­li­che wahr­schein­lich die bes­te Lösung ist und alles wei­te­re wich­ti­ge zu dem The­ma, gibt es im fol­ge­nen Abschnitt.

Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?
Abbil­dung 25: Wie craw­len und inde­xie­ren ver­schie­de­ne Such­ma­schi­nen JavaScript?

Wie bereits ange­spro­chen, ist ledig­lich der Craw­ler von Goog­le in der Lage Java­Script zu ren­dern. Wenn man einen Wert auf ande­re Such­ma­schi­nen und beson­ders sozia­le Netz­wer­ke wie Face­book, Twit­ter, Insta­gram, Xing etc. legt, soll­te eine Mög­lich­keit gesucht wer­den, auch die­sen Craw­lern das Aus­le­sen der Inhal­te zu ermög­li­chen. Pre­ren­de­ring, also Ser­ver-Side Ren­de­ring ist hier eine mög­li­che Lösung.

Einsatz von Prerendering für JavaScript-Webseiten im SEO
Abbil­dung 26: Ein­satz von Pre­ren­de­ring für Java­Script-Web­sei­ten im SEO

Pre­ren­de­ring füh­ret dazu, dass Java­Script vor­ge­ren­dert wird. Das bedeu­tet, dass der Goog­le­bot und alle ande­ren Craw­ler bereits den geren­der­ten HTML-Code bereit­ge­stellt bekom­men und nicht selbst ren­dern müs­sen um die Inhal­te craw­len zu kön­nen. Das bringt den gro­ßen Vor­teil mit sich, dass ganz genau sicher­ge­stellt wer­den kann wie der HTML-Code der dem Goog­le­bot bereit­ge­stellt wird aussieht.

Wer sich nicht selbst um ein ser­ver­sei­ti­ges Ren­de­ring von Java­Script küm­mern möch­te, kann auf kos­ten­pflich­ti­ge Diens­te wie Prerender.io setz­ten. Nach der erfolg­rei­chen Imple­men­tie­rung des Diens­tes wird die gesam­te Web­sei­te geren­dert und auf dem Ser­ver gespei­chert (Cache). Wie oft der Cache aktua­li­siert wird, hängt von dem jewei­li­gen Dienst­leis­ter ab.

Bei einer Anfra­ge an den Ser­ver wird nun geschaut, wel­cher User-Agent hin­ter einer Anfra­ge steckt. Wenn es sich hier um ein Bot wie z.B. den Goog­le­bot han­delt, wird die­sem der bereits zwi­schen­ge­spei­cher­te, also geren­der­te Code zur Ver­fü­gung gestellt. Damit erspart sich der Craw­ler das Ren­dern von Java­Script bzw. ermög­licht es Craw­lern, die nicht in der Lage sind Java­Script aus­zu­füh­ren die Inhal­te der Web­sei­te zu erfassen.

Einsatz von Prerendering-Diensten für JavaScript-Webseiten im SEO
Abbil­dung 27: Ein­satz von Pre­ren­de­ring für Java­Script-Web­sei­ten im SEO

Um den kor­rek­ten Ein­satz von Pre­ren­de­ring-Diens­ten extern zu tes­ten, emp­fiehlt sich der Ein­satz des Screa­ming Frog SEO Spi­ders. In Abbil­dung 27 sind drei Test-Sze­na­ri­en zu sehen.

  • Test-Sce­n­a­rio: User-Agent: Screa­ming Frog, Ren­de­ring: Text Only. Hier ist zu erken­nen, dass der Craw­ler bis auf die Start­sei­te kei­ne wei­te­ren Urls gecrawlt hat, da das Java­Script nicht aus­ge­führt wurde.
  • Test-Sce­n­a­rio: User-Agent: Goog­le­bot, Ren­de­ring: Text Only. Hier ist zu erken­nen, dass alle Urls gecrawlt wur­den da der Pre­ren­de­ring-Dienst den User-Agent Goog­le­bot erkannt hat und den vor­ge­ren­der­ten Code aus­ge­ge­ben hat
  • Test-Sce­n­a­rio: User-Agent: Goog­le­bot, Ren­de­ring: Java­Script. Auch hier ist zu erken­nen, dass alle Urls gecrawlt wur­den da die Ren­de­ring-Engi­ne vom Screa­ming Frog akti­viert wurde

Zu Ver­mer­ken ist, dass sobald beim Screa­ming Frog die Ren­de­ring-Engi­ne akti­viert wird, der Craw­ler auch Java­Script aus­führt, egal wel­cher User-Agent hin­ter der Anfra­ge steckt.

Tes­ting von Pre­ren­de­ring mit dem User-Agent-Switcher

Einsatz von Prerendering-Diensten für JavaScript-Webseiten im SEO
Abbil­dung 28: Ein­satz von Pre­ren­de­ring für Java­Script-Web­sei­ten im SEO

Neben dem Screa­ming Frog SEO Spi­der eig­net sich auch der Goog­le Chro­me Brow­ser für das Tes­ting von Pre­ren­de­ring-Diens­ten. Hier­für muss das kos­ten­lo­se Add-On „User­Agent-Swit­cher“ instal­liert werden.

Mit dem User­Agent-Swit­cher kann der User-Agent belie­big mani­pu­liert wer­den. Im ers­ten Fall, wel­cher in Abbil­dung 28 zu sehen ist, wur­de der User-Agent auf „Default“ gestellt. Bei der Betrach­tung des Quell­codes ist zu sehen, dass hier kein Java­Script aus­ge­fuhrt wurde.

Im zwei­ten Fall wur­de der User-Agent „Goog­le­bot“ gewählt und die Web­sei­te erneut besucht. Bei der Betrach­tung des Quell­codes ist zu sehen, dass hier der vor­ge­ren­der­te Code an den Brower aus­ge­lie­fert wur­de, da der Pre­ren­de­ring-Dienst den Goog­le­bot als User­Agent erkannt kann.

Bei sol­chen Tests soll­te dar­auf geach­tet wer­den, dass der Cache des Brow­sers bei jeder neu­en Anfra­ge an den Ser­ver gelöscht wer­den sollte.

Dynamic Renderung - Googles Empfehlung für Prerendering
Abbil­dung 29: Dyna­mic Ren­de­rung – Goo­g­les Emp­feh­lung für Prerendering

Spann­den ist, dass Goog­le selbst, zumin­dest laut eige­ner Aus­sa­ge in den meis­ten Fäl­len zu Pre­ren­de­ring rät. Goog­le nutzt hier­für den eigen erfun­de­nen Namen „Dyna­mic Ren­de­ring“, was nichts ande­res ist als das hier ange­spro­che­ne Pre­ren­de­ring, also eine Lösung in dem Java­Script bereits vom Ser­ver geren­dert wird. Goog­le gibt hin­sicht­lich noch den Tipp, dass für das Ren­dern ein sepe­ra­ter Ser­ver genutzt wer­den soll, da das Ren­dern die Ser­ver zu sehr belas­ten kön­ne. Dyna­mic Ren­de­ring wur­de zum ers­ten mal auf der Goog­le I/O 2018 präsentiert:

YouTube

Mit dem Laden des Vide­os akzep­tie­ren Sie die Daten­schutz­er­klä­rung von You­Tube.
Mehr erfah­ren

Video laden

Goog­le nutzt für You­Tube eben­falls Prerendering

Einsatz von Prerendering (Server-Side Rendering) bei YouTube
Abbil­dung 30: Ein­satz von Pre­ren­de­ring (Ser­ver-Side Ren­de­ring) bei YouTube

Inter­es­sant zu beob­ach­ten ist, dass Goog­le für ihre Haus­ei­ge­ne Vido­plat­form You­Tube selbst Pre­ren­de­ring Ein­setzt. Dies lässt sich in dem oben erklär­ten Ablauf ein­fach tes­ten. Mit dem Stan­dard User-Agent von Chro­me und akti­vir­tem JavaSript lädt die Web­sei­te wie gewohnt. Sobald Java­Script im Brow­ser deak­ti­viert wird, sind kei­ne Inhal­te mehr zu sehen, da bei You­Tube alle Vide­os über Java­Script erzeugt wer­den. Sobald der User-Agent zusätz­lich auf Goog­le­bot gestellt wird, ist die vor­ge­ren­der­te Ver­si­on der Web­sei­te zu sehen. Die wich­tigs­ten Inhal­te, auch wenn in einer etwas ande­ren Dar­stel­lung, wer­den angezeigt.

Ob es sich hier­bei wirk­lich um Pre­ren­de­ring han­delt ist nicht sicher. Es ist aber deut­lich, dass Goog­le dem Craw­ler eine geson­der­te Ver­si­on zur Ver­fü­gung stellt, ohne Java­Script ren­dern zu müs­sen. Bei dem täg­li­chen Neu­auf­kom­men von Vide­os eine ver­ständ­li­che Maß­nah­men Sei­tens Google.

Ob beim Ein­satz von Pre­ren­de­ring auf eige­ne Lösun­gen oder kos­ten­pflich­ti­ge Diens­te gesetzt wird, gibt es kei­ne ein­deu­ti­ge Ant­wort und soll­te selbst abge­schätzt wer­den. Beson­ders der Fak­tor kos­ten und Auf­wand spielt hier eine gro­ße Rolle.

Goog­le selbst emp­fiehlt den Ein­satz vom Kos­ten­pflich­ti­gen Dienst wie Prerender.io und als eige­ne Lösun­gen Ren­der­ton oder Pup­pe­teer. Des­wei­te­ren wäre noch Phantom.js zu empfehlen.

In einem Bei­spiel zeigt Jes­se Han­ley was pas­sie­ren kann, wenn der exter­ne Dienst strei­ken soll­te oder es Pro­ble­me bei der Abrech­n­nung gab:

@jessethanley warnt auf Twitter davor, server side rendering zu von Drittanbieter zu nutzen, wenn man bereits React nutzt

Bei all die­sen Vor­tei­len, bringt ser­ver­sei­ti­ges Ren­dern von Java­Script auch eini­ge Nach­tei­le für SEO mit sich. Da dem User und dem Craw­ler unter­schied­li­che Wege bis zum Auf­ruf der Inhal­te prä­sen­tiert wer­den, ent­steht eine Gefahr von Cloa­king. Auch wenn sich die Gefahr in Gren­zen hält, soll­te jeder SEO-Ver­ant­wort­li­che bei der Ent­schei­dung die­sen Punkt mitberücksichtigen.

Des Wei­te­ren ist durch das län­ge­re zwi­schen­spei­chern der Web­sei­te, „Real­time Con­tent“ nur in begrenz­ten Mög­lich­kei­ten ein­setz­bar. Ände­run­gen wer­den dem­entspre­chend erst beim nächs­ten „Caching“ der Web­sei­te für den Craw­ler sicht­bar. Damit erhöht sich die Gefahr von Cloaking.

Durch eine sau­be­re Imple­men­tie­rung von Pre­ren­de­ring auf dem Ser­ver ent­ste­hen grö­ße­re Auf­wän­de. Auch wenn auf exter­ne Pre­ren­de­ring-Diens­te zurück­ge­grif­fen wird, fal­len monat­li­che Kos­ten auf. Die­se Staf­feln sich meist je nach Web­sei­ten­grö­ße und der Fre­quenz der zwi­schen­ge­spei­cher­ten Ver­si­on der Web­sei­te auf dem Server.

Zu wei­te­ren Nach­tei­len gehört, dass die sel­be Ver­si­on einer Web­sei­te für ver­schie­de­ne End­ge­rä­te bereit­ge­stellt wird. Bei der Nut­zung von Respon­si­ve-Design und Respon­si­ve –Con­tent muss der DOM erneut gela­den wer­den, um jeder Bild­schirm­auf­lö­sung gerecht zu werden.

All die­se Nach­tei­le soll­ten bei der Nut­zung von Pre­ren­de­ring in Betracht gezo­gen und vali­diert werden.

Ist Isomorphic JavaScript die Lösung für alle SEO-Probleme?
Abbil­dung 31: Ist Iso­mor­phic Java­Script die Lösung für alle SEO-Probleme?

Iso­mor­phic Java­Script bzw. Uni­ver­sal Java­Script bie­tet hier Abhil­fe und ver­spricht die Wun­der­waf­fe im Zusam­men­spiel von Java­Script und SEO zu sein. Was ist Iso­mor­phic Java­Script und wie­so ist es im Bereich SEO so interessant?

Was ist Iso­mor­phic JavaScript?

Mit dem Ein­satz von Iso­mor­phic-Lösun­gen wird der Java­Script-Code sowohl vom Ser­ver als auch vom Cli­ent aus­ge­führt. Das bedeu­tet, dass dem Cli­ent ein bereits geren­der­ter Code prä­sen­tiert wird. Das span­nen­de dabei ist, dass Java­Script Inhal­te im Brow­ser trotz­dem ver­än­dern kann. Dadurch kön­nen wei­ter­hin dyna­mi­sche Inhal­te abge­bil­det wer­den und der Craw­ler bekommt den geren­der­ten Code prä­sen­tiert. Die­ser „Shared-Code“ wird damit sowohl vom Brow­ser, als auch vom Craw­ler genutzt.

Mit die­ser Lösung wird dem Craw­ler das Ren­dern von Java­Script erspart und der Cli­ent pro­fi­tiert von der bes­se­ren Per­for­mance, da der vor­ge­ren­der­te Code direkt dar­ge­stellt wer­den kann. Damit wären die größ­ten Schwie­rig­kei­ten beim Zusam­men­spiel von Java­Script und SEO gelöst.

Nach­tei­le von Iso­mor­phic JavaScript?

Nur bestimm­te Java­Script-Frame­works eige­nen sich ohne Wei­te­res für den Ein­satz von Iso­mor­phic-Lösun­gen. Ande­re Frame­works las­sen sich nur über Umwe­ge und deut­lich höhe­ren Auf­wand für solch ein Pro­jekt anpassen.

Da die­ses The­men­ge­biet noch sehr neu und uner­probt ist, benö­tigt es ein hohes Maß an Erfah­rung und Know­how auf Sei­ten des Ent­wick­ler-Teams. Beson­ders Tes­ting und Debug­ging von Iso­mor­phic Java­Script benö­tigt eine weit­aus grö­ße­re Auf­merk­sam­keit als her­kömm­li­che Java­Script-Lösung im Bereich SEO. Damit ist die­ser Ansatz für klei­ne­re Pro­jek­te mit gerin­gem Bud­get gänz­lich unattraktiv.

Nicht des­to Trotz, bie­tet Iso­mor­phic Java­Script in Zukunft eine viel­ver­spre­chen­de Lösung um SEO und Java­Script zu verheiraten.

Zur Über­sicht wur­den hier noch­mals alle wich­ti­gen Punk­te die für Pre­ren­de­ring (Ser­ver-Side-Ren­de­ring) für Java­Script-Web­sei­ten wich­tig sind zusammengefasst:

  • Ohne Pre­ren­de­ring wer­den alle ande­ren Such­ma­schi­nen und sozia­le Netz­wer­ke ignoriert
  • Beim Ein­satz von Pre­ren­de­ring wird dem Craw­ler eine bereits vor­ge­ren­der­te (cache) Ver­si­on der Sei­te prä­sen­tiert. Der User pro­fi­tiert somit wei­ter­hin von allen Cli­ent-Side-Ren­de­ring Vor­tei­len von JavaScript
  • Mit dem Screa­ming Frog SEO Spi­der und der Goog­le Chro­me Erwei­te­rung User Agent Swit­cher lässt sich Pre­ren­de­ring extern ein­fach testen
  • Goog­le selbst emp­fiehlt in den meis­ten Fäl­len Pre­ren­de­ring (Dyna­mic Rendering)
  • Sowohl eige­ne Lösun­gen als auch kos­ten­pflich­te Diens­te für Pre­ren­de­ring kom­men in Frage
  • Iso­morhic (Uni­ver­sal) Java­Script bie­tet in fer­ner Zukunft die opti­ma­le Lösung, steckt aktu­ell aber noch in den Kinderschuhen

Abschlie­ßend eini­ge Gedan­ken zu Java­Script SEO, wel­che Punk­te es SEO-Ver­ant­wort­li­chen erschwert Java­Script und SEO unter einen Hut zu brin­gen, wel­che neu­en Ansät­ze geschaf­fen wer­den müs­sen und wo der Weg hin­ge­hen sollte.

Allei­ne die Schwie­rig­keit, dass nur Goog­le als bis­lang ein­zi­ge Such­ma­schi­ne Java­Script ren­dern kann, erschwert es SEO-Ver­ant­wort­li­chen den Umgang mit Java­Script. Auch wenn ande­re Such­ma­schi­nen nach­zie­hen, wer­den die­se sehr wahr­schein­lich ande­re Tech­no­lo­gien und Ren­der­ning-Engi­nes nut­zen, um Java­Script aus­füh­ren zu kön­nen. Zusätz­lich muss mit unter­schied­li­chen Java­Script-Frame­works anders umge­gan­gen werden.

Wie sieht es mit dem Audi­t­ing und Tes­ting aus? Da kaum Tool-Anbie­ter über­haupt das Ren­de­ring von Java­Script anbie­ten, wenn über­haupt, dann mit unter­schied­li­chen Ren­de­ring-Engi­nes, sind die­se Tools kaum bis gar kei­ne vali­den Quel­len auf die sich SEO-Ver­ant­wort­li­che ver­las­sen können.

Auch beim Ein­satz von Best Prac­ti­ce Java­Script SEO Maß­nah­men ist kei­ne Garan­tie für die kor­rek­te Inde­xie­rung gewehr­leis­tet. Ein ers­ter Schritt in die rich­ti­ge Rich­tung sei­tens Goog­le, war das Ver­öf­fent­li­chen des Doku­men­tes „Ren­de­ring von Goog­le Search“ und „Dyna­mic Ren­de­ring. Den Groß­teil der aktu­el­len Res­sour­cen zu Java­Script SEO stammt von sehr enga­gier­ten SEOs aus der gan­zen Welt, die sich die­sem The­ma widmen.

Nach Erfah­run­gen und aktu­el­len Erkennt­nis­sen kann der Ein­satz von Java­Script für die Dis­zi­plin SEO nicht emp­foh­len wer­den. Es gibt zwar Lösun­gen und Wege Java­Script und SEO unter einen Hut zu brin­gen, die­se Wege und Lösun­gen sind aber auf­wen­dig, ris­kant und feh­ler­an­fäl­lig und geben nie eine 100% Garan­tie, ob Goog­le wirk­lich alles so ver­ar­bei­tet wie gewollt. Daher gibt es abschlie­ßend eine kla­re Emp­feh­lung für den Ein­satz von Prerendering.

Abschlie­ßend ein Zitat vom Kol­le­gen Bart­osz: „Ran­king well with CSR Java­Script Web­sites is very hard if not impossible“.

Abschlie­ßen gibt es hier noch­mals die Webi­nar-Auf­zeich­nung bei Search­metrics und die Sli­des zu Vor­trä­gen von der SEO­Komm, dem SEO Day und der SEO Cam­pi­xx zu Java­Script SEO.

YouTube

Mit dem Laden des Vide­os akzep­tie­ren Sie die Daten­schutz­er­klä­rung von You­Tube.
Mehr erfah­ren

Video laden

Kli­cken Sie auf den unte­ren But­ton, um den Inhalt von www.slideshare.net zu laden.

Inhalt laden

Kli­cken Sie auf den unte­ren But­ton, um den Inhalt von www.slideshare.net zu laden.

Inhalt laden

Kli­cken Sie auf den unte­ren But­ton, um den Inhalt von www.slideshare.net zu laden.

Inhalt laden

Wer schreibt hier

Artur Kosch

Geschäftsführender Gesellschafter
Mehr erfahren
Ähnliche Beiträge

SEO Guide für Einsteiger

SEO ist Neuland für dich? Du willst die SEO-Grundlagen lernen und direkt erste SEO-Maßnahmen umsetzen?

  1. 1.Finde heraus wie Suchmaschinen arbeiten
  2. 2.Lerne Maßnahmen kennen mit denen du die Rankings einer Website verbessern kannst
Download SEO Guide

Das könnte dich auch interessieren