JavaScript SEO Vortrag auf dem SEO-Day 2018 von Artur Kosch - Crawling, Indexierung und Auditing von JavaScript-Websites.

1. JavaScript SEO
SEO-Day Cologne 2018
1
Crawling, Indexierung und
Auditing von JavaScript-Websites

2. Über mich
Artur Kosch
Geschäftsführender Gesellschafter
‣ Über 8 Jahre Erfahrung im Online Marketing
und SEO
‣ Bekannt durch Publikationen, Fachartikel und
Vorträge auf Konferenzen zu Themen Online
Marketing und SEO
‣ Kernkompetenzen im technischen SEO,
strategischen Online Marketing und Kreation
von Content Marketing Strategien
2

4. Wie interagiert der
Crawler mit JavaScript?
1.
4

5. Wie wird JavaScript ausgeführt?
Ausführen von PHP und JavaScript-Rendering zwischen Browser und Server
1. Der Browser stellt eine GET-Anfrage
an den Server
2. Der Server führt das PHP-Script aus (z.B.
beim Einsatz eines CMS)
3. Der Server gibt den HTML-Quellcode
an den Browser zurück
4. Der Browser führt das JavaScript aus
5

6. Quellcode vor dem Rendern
Einblick in den Quellcode vor und nach dem Rendern von JavaScript
‣ Ein Blick auf den Quellcode zeigt keine
Inhalte, die durch JavaScript erzeugt
werden
‣ Rendern findet Clientseitig (im Browser)
statt, daher sind keine Inhalte, die
durch JS erzeugt werden sichtbar
‣ Erst der gerenderte Code, zeigt alle
Inhalte an, die im Browser angezeigt
werden.
6
Post-
Dom
Pre-
Dom

7. Headless Browser
Grundprinzipien eines Headless Browsers an Hand von Headless Chrome
‣ Ein Headless-Browser ist ein Browser
ohne visuelle Komponenten
‣ Der Headless-Browser stellt keine
Inhalte dar, um mit diesen wie ein
Webseitenbesucher zu interagieren
‣ Es werden Befehle ausgeführt, um mit
der Webseite zu interagieren
‣ Ein Headless-Browser beschreibt
relativ gut, wie der Googlebot mit
JavaScript einer Webseite interagiert.
7

8. Automatisierung & Scrapping
Automatisieren und Scrappen mit Headless Chrome
‣ Node.js wird in der, für Chrome
entwickelten, JavaScript-Engine „V8“
ausgeführt
‣ Puppeteer ist eine Node.js Library API
mit der man Headless Chrome steuern
kann
‣ Mit dem Einsatz von Node.js und
Puppeteer kann JavaScript-Code
eingesetzt werden, um Webseiten mit
Headless Chrome zu scrapen
‣ Gerüchten zufolge soll der Headless
Chrome extra für den Google Bot
entwickelt worden sein
8
+
+

9. A Guide to
Automating &
Scraping the Web with
JavaScript
API Documentation für
Puppeteer
Codeburst.io
Github.com
Getting Started with
Headless Chrome
Developers.google.com

10. GoogleBot Rendering
Welche Technologien nutzt der GoogleBot um Webseiten zu rendern?
‣ Die Technik hinter dem Web Rendering
Service (WRS) ist Chrome in der Version 41
- März 2015!
‣ Chrome 41.0.2272.118 ist die Version
aus dem Jahr 2015 und erfüllt etwa 60%
der aktuellen Chrome-Version
‣ Sollte laut Googles Aussagen im Jahr
2018 aktualisiert werden, wurde aber
zurückgestellt.
‣ Damit ist der Chrome 41 neben dem
Abrufen und Rendern Tool der Search
Console das primäre debuging und Testing-
Tool
10

11. GoogleBot Rendering
Welche Technologien und Funktionen werden nicht unterstützt?
‣ Das aktuelle Transfer Protokoll HTTP/2 wird
nicht unterstützt. Lediglich HTTP/1 und FTP
‣ HTTP/2 kann allerdings abwärtskompatibel
konfiguriert werden
‣ Keine Unterstützung für das WebSocket-
Protokoll
‣ IndexedDB und WebSQL-Interfaces zur
Datenhaltung im Browser werden nicht
unterstützt
‣ Inhalte, die nach Zustimmung angezeigt werden,
werden nicht indexiert
‣ Inhalte des Local Storages sowie Session Storages
werden gelöscht und HTTP-Cookies entfernt
11

12. Google nutzt zum
rendern von Webseiten
3 Jahre alte Technologien!
12

15. Can I use Chrome Status
Caniuse.com Chromestatus.com

16. Crawler rendert nicht, sondern der Indexer
Der Crawler (Googlebot) an sich rendert nicht, sondern der Indexer (Caffeine)
16

17. Verarbeitung von JavaScript vs. HTML
Ausführen von JavaScript im Vergleich zu HTML
1. HTML-Dateien werden runtergeladen
2. CSS- und JavaScript-Daten werden
parallel runterladen
3. WRS wird genutzt (Teil von Caffeine)
um JS auszuführen
4. WRS rendert alle Dateien
5. Caffeine kann nun die Inhalte ggf.
indexieren
6. Erst jetzt kann Googlebot neue Links
crawlen
17
1. HTML-Dateien werden
runtergeladen
2. Links werden aus dem
Quellcode entnommen und
können gecrawlt werden
3. CSS-Dateien werden
runtergeladen
4. Googlebot sendet alle
Rescourcen zu Caffeine
5. Caffeine indexiert ggf. die
Inhalte

20. Googlebot vs. Google Search Console Bot
Abrufen und Rendern mit dem Googlebot und dem Google Search Console Bot
20

21. Umgang der Suchmaschinen mit JavaScript
Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?
21
Are Search Engines Ready
for JavaScript Crawling &
Indexing?
Moz.com

22. Wie sieht es aus mit Bing?
Rendert Bing nur bei großen und wichtigen Seiten JavaScript?
Dan Patraovic

23. Crawling und Indexierung JS-Frameworks
Wie crawlt und indexiert der Googlebot verschiedene JavaScript-Frameworks?
23
Can Google properly crawl
and index JavaScript
frameworks? JavaScript SEO
experiment
elephate.com

24. Crawling und Indexierung JS-Frameworks
Wie crawlt und indexiert der Googlebot verschiedene JavaScript-Frameworks?
24
‣ Ein einfacher Fehler im
Angular 2s Framework
führte dazu, dass
Google selbst Probleme
bei der Indexierung von
Angular 2 hatte.
‣ Am 26. April 2017
wurde dieser Fehler
korrigiert, was die
Indexierungs-
probleme bei Angular
2 beseitigt

25. JS sehr Ressourcenintensiv
Rendering von JS ist sehr von der CPU abhängig
1 100

26. Zusammenfassung der Erkenntnisse
Folgende Erkenntnisse über die Interaktion von Crawlen mit JS können zusammengefasst werden
26
1. Google muss das Rendern von JS
übernehmen
2. Google verwendet zum rendern
Web Rendering Service (WRS)
3. Features und Technologien vom
Googlebot auf dem Stand von
Chrome 41 (2015)
4. Das Rendern übernimmt der Indexer
(Caffeine), nicht der Crawler
(Googlebot).
5. HTTP/2 Transfer Protokoll wird
nicht unterstützt
6. WebSocket-Protokoll, IndexedDB
und WebSQL-Interfaces werden
nicht unterstützt
7. Google interagiert unterschiedlich
mit verschiedenen JS-Frameworks
8. Bis auf Google, rendert kein
Crawler JavaScript

27. Auditing &
Best Practices
2.
27

29. Auditing mit Chrome 41
Rendering-Fehler in den Developer Tools von Chrome 41 einsehen
29
1.
41
3.
Chrome
Developer Tools
öffnen
2.
Client-Rendered
Webseite
öffnen
4.
Fehler aus der
Console
korrigieren

30. Quellcode vor dem Rendern
Einblick in den Quellcode vor und nach dem Rendern von JavaScript
‣ Ein Blick auf den Quellcode zeigt keine
Inhalte, die durch JavaScript erzeugt
werden
‣ Rendern findet Clientseitig (im Browser)
statt, daher sind keine Inhalte, die
durch JS erzeugt werden sichtbar
‣ Erst der gerenderte Code, zeigt alle
Inhalte an, die im Browser angezeigt
werden.
30
Post-
Dom
Pre-
Dom

32. Auditing vom gerenderten Quellcode
Gerenderten Quellcode einsehen und analysieren
1. In einen „leeren Bereich“ der Webseite
rechts-klicken und „Untersuchen“
auswählen
2. Um den gesamten Inhalt zu
erhalten, den HTML-Tag im rechten
Bereich des Browsers auswählen
3. Mit einem Rechtsklick auf den
HTML-Tag auf „Copy“ und „Copy
OuterHTML“ navigieren um den
gesamten Inhalt zu kopieren
4. Der kopierte HTML-Code kann nun
in Textprogramm eingefügt werden, um
den Inhalt einzusehen und zu
analysieren
32

33. Auditing mit GSC „Fetch & Render“-Tool
Abrufen und Rendern mit dem Googlebot und dem Google Search Console Bot
33

34. GSC „Fetch & Render“-Tool agiert anders
„Fetch & Render“-Tool nur für Tests geeignet, ob Googlebot technisch in der Lage ist Seiten zu rendern
34

35. GSC „Fetch & Render“-Tool agiert anders
„Fetch & Render“-Tool nur für Tests geeignet, ob Googlebot technisch in der Lage ist Seiten zu rendern
35

36. Site-Abfrage zur Überprüfung nutzen
Site-Abfrage eher nutzen als den Google-Cache um zu überprüfen ob Content indexiert wurde
36
‣ Google Search Console „Fetch &
Render“-Tool gibt lediglich Auskunft,
ob eine Seite technisch gerendert
werden kann
‣ Timeouts und Performance-Ansprüche des
Googlebots werden nicht
berücksichtigt
‣ Site-Abfrage + Query zur Überprüfung
nutzen, ob Inhalte indexiert werden
können.
‣ Google-Cache zeigt lediglich den
„HTML-Code“ nicht wie Googlebot die
Seite rendert

37. Google Mobile Friendly Tester
Der Google Mobile Friendly Tester (Mobile) besser geeignet zur Betrachtung des gerenderten DOM
37
‣ Laut Google weißt das „Fetch & Render“-Tool der
GSC hier noch Schwächen auf
‣ Veränderungen die durch JavaScript am DOM
nachträglich vorgenommen werden, werden
im Google Rich Media Tester dargestellt
‣ Auch CSS-Anweisungen die die durch
Resizing verursacht werden, werden im
Google Mobile Friendly Tester dargestellt
‣ Dieses „Feature“ ist auch für das GSC „Fetch and
Render“-Tool geplant

38. Google Rich Media Tester
Der Google Rich Media Tester (Desktop) besser geeignet zur Betrachtung des gerenderten DOM
38
‣ Laut Google weißt das „Fetch & Render“-
Tool der GSC hier noch Schwächen auf
‣ Veränderungen die durch JavaScript am
DOM nachträglich vorgenommen
werden, werden im Google Rich Media
Tester dargestellt
‣ Auch CSS-Anweisungen die die durch
Resizing verursacht werden, werden im
Google Rich Media Tester dargestellt
‣ Dieses „Feature“ ist auch für das GSC
„Fetch and Render“-Tool geplant

39. Auditing mit Searchmetrics Crawler
Der Einsatz vom Searchmetrics Crawler zum rendern von JavaScript-Webseiten
39
‣ Der Site-Optimizer (Crawler) von
Searchmetrics bassiert auf den
Technologien vom Google Chrome 41.
‣ Damit wird auch der Web Rendering
Service und PhantomJS (von Google
empfohlen) eingesetzt zum renden.
‣ Sehr nützlich um Rich-JS-Webseiten
auf OnPage-Faktoren zu prüfen.
‣ Da Server-basiert, werden keine
eigenen Ressourcen benötigt

40. Auditing mit Screaming Frog
Der Einsatz des SEO Spider Screaming Frog zum rendern von JavaScript-Webseiten
1. Um JavaScript-Rendering zu
aktivieren folgend navigieren:
2. Configuration » Spider » Rendering »
JavaScript » OK
3. AJAX Timeout auf 5 Sekunden stellen
(Standart-Einstellung)
4. Bilderschirmgröße des Screenshots
nach dem Rendern kann beliebig
gewählt werden
5. Screaming Frog nutzt die
Rendering-Engine vom Chromium
Projekt „Blink„
40

41. Dynamische Inhalte (5 Sekunden Regel)
Load Event und User Event für die Verwendung von wichtigen Inhalten
41
Network
time
Server time Network
time
DOM Processing Page
Rendering
Clientside logic, API calls
DOM Manipulation
Budget
pro
Monat
Initial
Request
Budget
pro
Monat
Server
side
Budget
pro
Monat
Server
Code
finished
Budget
pro
Monat
First
byte
Budget
pro
Monat
DOM
Content
Ready
Budget
pro
Monat
Load
event
Front-end time
i
Der Googlebot erstellt nach etwa 5
Sekunden einen Screenshot der
Webseite. Alle wichtigen Inhalte sollten
in dieser Zwischenzeit geladen sein.

42. Indexierbare Urls
Einblick in den Quellcode vor und nach dem Rendern von JavaScript
‣ Beim Aufruf muss eine neue Url
(HTTP-Status Code: 200) mit
serverseitiger Unterstützung
aufgerufen werden
‣ pushState-Fehler vermeiden,
damit die Original URL mit
serverseitiger Unterstützung
weitergegeben wird.
‣ Kein Einsatz von Hash (#) in der
Url für unique Content
‣ Links über a-href realisieren und
nicht durch User-Event (z.B.
onClick) erzeugen werden
42

43. Einsatz von Canonical-Tags
Google empfiehlt den Canonical-Tag vor dem Rendern auszuliefern
‣ John Müller (Google) empfiehlt den
Canonical-Tag in der prerendered Version der
Webseite auszuliefern
‣ Experiment von Eoghan Henn zeigt, dass
Google auch Canoncial-Tags die per
JavaScript (gerenderte Version) greift.
‣ Im Experiment wurden die
kanonisierten Urls erst 34 Tage danach
indexiert.
‣ Empfehlung weiterhin: Canonical-Tag in
prerenderted Version ausliefern
43

44. Head-Bereich ohne JavaScript?
Wichtige Hinweise für den Head-Bereich von JavaScript-Webseiten
‣ Canonical-Tag und Title-Tag ohne JavaScript
lösen wenn möglich
‣ Weitere Informationen wie Meta-
Description, hreflang-Tag, Open Graph
Angaben ohne JavaScript lösen etc., um
anderen Crawlern Inhalte anzubieten
‣ Strukturierte Daten über JSON-LD lösen
(Grundsätzliche Empfehlung)
44

45. Altes AJAX Crawling Schema wird eingestellt
Google stellt das Crawlen nach dem alten AJAX Crawling Schema noch dieses Jahr einstellen
‣ Google wird nicht aufhören AJAX
(Asynchrinouse JS) zu crawlen
‣ Lediglich das AJAX Crawling
Schema, mit dem Anhand einer
Url “_=escaped_fragment_=to“ werden
nicht mehr vom Googlebot
angefragt
‣ Achtung: Bingbot wird dieses
Schema weiterhin nutzen!
45

46. Lazy Loading für Bilder
Lazy Loading über „noscript“ oder schema.org/image (JSON-JD)
46

47. Zusammenfassung der Erkenntnisse
Folgende Erkenntnisse über das Auditing und Best Practices für JavaScript
47
1. Analyse vom Quellcode (Pre-DOM)
reicht nicht aus. Erst der
gerenderte Code, zeigt alle Inhalte
an
2. Inhalte müssen nach 5 Sekunden
dargestellt werden
3. Inhalte müssen nach dem Load-
Event dargestellt werden.
Inhalte die durch User-Event
erzeugt werden, werden nicht
indexiert
4. GSC dient nur für technische
Anforderungen beim Rendern
5. Rich Media Tester (Desktop) bzw.
Mobil Friendly Tester (Mobile) zum
Betrachten des DOM nutzen
6. Aufruf von Seiten muss eigene
Url erzeugt werden mit
serverseitiger Unterstützung. Kein
Einsatz von Hash (#) oder Hash-
Bang (#!) in der Url
7. Strukturierte Daten mit JSON-LD
realsieren
8. AJAX Crawling Schema wird nicht
mehr unterstüzt
9. Canonical-Tag vor dem Rendern
darstellen.

48. Prerendering
3.
48

49. Was ist mit anderen Suchmaschinen?
Wie crawlen und indexieren verschiedene Suchmaschinen JavaScript?
49
Are Search Engines Ready
for JavaScript Crawling &
Indexing?
Moz.com

50. Wie funktioniert Prerendering?
Einsatz von Prerendering-Diensten für JavaScript-Webseiten im SEO
50
Load Page normally
Pre-Rendered Cache
Request
Bot
Non-Bot
Check User-Agent
Page

51. 51
Einsatz von Prerendering
Einsatz von Prerendering-Diensten für JavaScript-Webseiten im SEO
Screaming Frog Text Only Googlebot Text Only Screaming Frog JavaScript

52. Einsatz von Prerendering
Einsatz von Prerendering-Diensten für JavaScript-Webseiten im SEO
52
BotUser

54. Dynamic Rendering
Daynamic Rendering als Universal JavaScript-Lösung von Google empfohlen
54

55. 55
Prerendering-Dienste oder eigene Lösungen
Prerendering-Dienste zum Empfehlen für JavaScript-Webseiten?

57. YouTube nutzt Prerendering
Google setzt bei der hauseignen Video-Plattform YouTube auf Prerendering
57
Chrome JS AN Chrome JS AUS GoogleBot JS AUS

58. Nachteile von Prerendering
Welche Nachteile bringt Prerendering für SEO mit sich?
58
Load Page normally
Pre-Rendered Cache
Request
Bot
Non-Bot
Check User-Agent
Page
1. User und Crawler erhalten
unterschiedliche Inhalte: Cloaking-
Gefahr!
2. Größere Ressourcen (Server-
Leistung) ist notwendig. Bei
großen Seiten mit aktuellen
Inhalten = Sehr großer Aufwand
3. Seiten werden für längere Zeit
zwischengespeichert: Kein Real-
Time Content!
4. Die selbe Version der Seite wird für
verschiedene Endgeräte
zwischengespeichert
5. Erfordert ein gutes und
kompetentes Entwickler-Team,
um alles sauber zum laufen zu
bekommen
6. komplexeres Debugging nötig und
größerer Aufwand

59. Isomorphic (Universal) JavaScript
Isomorphic JavaScript die Lösung für alle SEO-Probleme?
‣ Mit Isomorphic Applikationen kann
JavaScript-Code sowohl vom Server als auch
vom Client ausgeführt werden
‣ Dadurch kann sowohl dem Crawler, als
auch dem User der selbe Inhalt gezeigt werden
‣ Dynamische Inhalte können weiterhin durch
den Browser verändert werden
‣ Das Rendern von JavaScript wird Crawlern
damit abgenommen
‣ Verbesserung der Performance, da JavaScript
nicht (vom Client) gerendert werden
muss
59
Client Server
Shared
Code

60. Nachteile von Isomorphic (Universal) JavaScript
Welche Nachteile bringt Isomorphic JavaScript für SEO mit sich?
‣ Nur bestimmte JavaScript-Frameworks
eignen sich für eine Isomorphic
Applikation. (Andere nur über
Umwege)
‣ Einrichtung benötigt größeren Aufwand
und ist damit kostspieliger
‣ Erfordert ein hohes Maß an Erfahrung
und Knowhow
‣ Damit für kleine Projekte ungeeignet
60
Client Server
Shared
Code

61. Ist Client-Side Rendered
JavaScript für
SEO zu empfehlen?
61

62. Budget pro Monat
If you search for any competitive keyword terms,
it’s always going to be server rendered sites. And
the reason is because although Google does
index client-side rendered HTML, it’s not perfect
yet and other search engines don’t do it as well.
So if you care about SEO, you still need to have server-
rendered content.

64. Gedanken zu JavaScript & SEO
Welche Punkte erschweren SEO-Verantwortlichen den Umgang mit JavaScript?
64
1. Nicht jeder Crawler rendert JS
(Bing, Facebook, Twitter etc.)
2. Crawler nutzen unterschiedliche
Technologien
3. Tool-Anbieter nutzen
unterschiedliche Technologien
4. Es gibt beim Rendern unterschiede
zwischen JS-Framework
5. Nur wenig Transparenz der
Suchmaschinenanbieter
6. Auch beim Einsatz von „Best
Practice“ Maßnahmen keine
Garantie für korrekte
Indexierung
7. Auditing und Analysen weit aus
aufwändiger und damit
kostspieliger
8. Neue Herausforderungen benötigen
neue Ansätze

65. 65

66. 66

67. Vielen Dank!
@ArturKosch
artur.kosch@koschklink.de@ArturKosch
Artur Kosch
Artur Kosch
Geschäftsführender Gesellschafter