• 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

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