JavaScript und Suchmaschinenoptimierung waren sich lange Spinne Feind. Der Grund dafür war einfach: Google und andere Suchmaschinen konnten JavaScript nicht ausführen und daher Inhalte, die per JavaScript geladen oder nachgeladen wurden, auch nicht finden.

Mittlerweile aber werden JavaScript basierte Frameworks wie Angular, ReactJS, ember, vueJS usw. immer beliebter. Auf diese Weise können Programmierer Webseiten viel schneller und einfacher umsetzen. Große Entwickler-Communities sorgen dafür, dass beliebte Funktionen und wiederkehrende Muster bereits fertig bereitstehen und auch kontinuierlich weiterentwickelt werden.

JavaScript is here to stay

Mit der wachsenden Beliebtheit von JavaScript Frameworks kommt man auch als SEO nicht mehr darum herum, sich den Kopf darüber zu zerbrechen, wie man solche Seiten für Googlebot & Co zugänglich macht.

Um zu verstehen, wo die Probleme bei JavaScript Websites aus SEO Perspektive liegen, muss man zunächst einmal die grundsätzliche Funktion solcher JavaScript Frameworks verstehen und zum anderen das Konzept, wie Google Seiten crawled, indexiert und rankt kennen.

JavaScript Single Page Web Apps & SEO

Beim Aufruf einer „normalen“ Seite passiert – sehr vereinfacht ausgedrückt – folgendes: Der Client, also im Normalfall der Browser des Users, fragt beim Server nach dem HTML Quellcode, lädt diesen vom Server und fragt dann nach allen weiteren Ressourcen (CSS Dateien, JS, …), die in diesem HTML Dokument gelistet werden, um dann die Seite anzuzeigen.
Ob das HTML Dokument jetzt „fertig“ am Server liegt, oder dynamisch z.B. mit PHP serverseitig zusammengestellt wird, ist dabei gleich. Grundsätzlich sind Struktur und Inhalte aber jedenfalls schon im HTML Quellcode enthalten. Klickt sich der User durch die Seite wird bei jedem Seitenaufruf wieder eine HTML-Datei vom Server geladen.

Bei JavaScript Frameworks, wie Angular, React & Co ist diese Funktionsweise ein wenig anders. Sie basieren auf dem Single Page App Modell. Das heißt – auch wieder sehr grob skizziert – folgendes: Beim ersten Seitenaufruf wird zwar auch ein HTML-File geladen, das auch auf CSS und JS-Ressourcen verweist. In dieser HTML-Datei ist aber keinerlei Inhalt zu finden. Dieser wird ausschließlich per JavaScript hinzugefügt.

Als Beispiel kann man sich die Default App von Googles Angular Framework ansehen. Auf der „Welcome“ Seite sieht der User im Browser einen einfachen Header, ein Logo, sowie einen Content Bereich mit drei Links. Sieht man sich aber den HTML Code der Seite an, findet sich im, also dem sichtbaren Bereich, lediglich ein leeres Tag sowie fünf Scripte:

Angular App - Quellcode

Welche Inhalte angezeigt werden und wie die Seite dann aussieht, wird mit den Daten die das JavaScript übergibt erst im Browser „errechnet“. Statt ein fertiges HTML-Dokument auszuliefern, entsteht der HMTL-Quellcode bei diesem Client-Side Rendering erst im Browser. Durch JavaScript lässt sich in Folge über das DOM (Document Object Model) das HTML dynamisch verändern, ohne dass ganze Seiten neu geladen werden müssen. Statt bei jeder Interaktion immer eine neue HTML Datei zu laden, werden nur noch die benötigten Informationen nachgeladen.

Wird der gesamte Inhalt einer Seite aber auf diese Weise geladen, sieht ein Suchmaschinen-Crawler, der nur den HTML-Code einer Seite ausliest, nichts. Wovon diese Seite handelt und auf welche anderen Seiten sie verlinkt, kann die Suchmaschine nicht nachvollziehen. Wie lösen Suchmaschinen das Problem, bzw. wie können wir als SEOs helfen, das Problem zu lösen?

Dazu müssen wir zunächst den Prozess verstehen, wie Google Webseiten findet und wie die Suchmaschine versteht, wovon eine Seite handelt.

Crawling, Indexing… und Rendering

Bis Google seine selbstgesetzte Aufgabe erfüllen kann – dem User das relevanteste Ergebnis anzuzeigen – sind verschiedene Schritte notwendig. Vor allem geht es darum Webseiten zu finden und deren Inhalt korrekt zu interpretieren. Erst dann können die so in Googles Index gelangten Seiten gerankt werden.

Dazu zieht Googlebot, also der Crawler, durch das Web, indem er Hyperlinks folgt. Seine Aufgabe ist das Auffinden aller URLs. Weil – zumindest theoretisch – jede URL im Web auf irgendeine Weise miteinander verlinkt ist, kommt der Bot auch irgendwann auf jede einzelne URL.
Der Crawler hat eine einfache Parser-Funktion, um den HTML-Quellcode auszulesen und ein paar grundlegende Dinge herauszuziehen. Etwa Robots Meta-Anweisungen oder Canonical Tags, vor allem aber Links, über die er auf weitere Seiten kommt. Außerdem gibt der Crawler jede gefundene und indexierbare Seite und die wichtigsten Ressourcen (CSS, Bilder,..) an den Indexer weiter. Dieser Teil des Google-Algorithmus versucht nun den Inhalt der Seite zu verstehen.

Und in diesem Prozess taucht jetzt ein Problem bei JavaScript basierten Seiten auf. Würden Crawler und Indexer lediglich das geladene HTML-Dokument verarbeiten wären alle Seiten relativ leer. Damit Google das sieht, was der User sieht, muss daher der Indexer nun auch die Arbeit des Browsers übernehmen und die Seite rendern. Erst dann kann der Indexer den Inhalt verarbeiten. Und auch erst dann werden weitere Links „sichtbar“, die der Indexer wieder an den Crawler zurückgeben muss, damit dieser auf weitere Seiten kommt.

Zwischenfazit: Zwischen Crawlen und Indexieren muss eine Seite durch den Algorithmus nunmehr auch gerendert werden.

Können Suchmaschinen JavaScript rendern?

Google sagt seit 2014 von sich, dass der Google Bot mittlerweile JavaScript so gut rendern kann, wie ein moderner Browser. Seit Dezember 2017 ist man sich sogar so sicher, dass der Googlebot dem alten AJAX Crawling Schema nun nicht mehr folgen wird. Tatsächlich wissen wir, dass der Indexer einen Web Rendering Service (WRS) nutzt, der auf Google Chrome Version 41 (ein doch schon älterer Browser!) basiert. Voraussetzung dafür ist, dass keinerlei JavaScript und CSS Ressourcen durch die robots.txt Datei blockiert werden.

Um herauszufinden, wie Google eine JS basierte Website rendert, kann man auf die „Abruf wie durch Google“ (Fetch as Google) Funktion in der Search Console zurückgreifen. Hier sieht man einerseits, wie Google die Seite tatsächlich rendert, andererseits kann man auch den Quellcode einsehen.

Trotzdem tauchen immer wieder Berichte, Tests und Experimente auf, die vermuten lassen, dass Google JavaScript Applikationen doch noch nicht so gut versteht. Dazu kommt, dass schon kleine Fehler im JavaScript dazu führen können, das Google Inhalte nicht mehr sehen kann. Das mussten auch die Hauptentwickler von Angular feststellen, als die angular.io Website zwischenzeitlich aus dem Google-Index fiel. Zur Info: Angular wurde von Google selbst entwickelt 😉

Crawler anderer Suchmaschinen sowie Bots sozialer Netzwerke oder Messaging Services, die auf Seiten zugreifen um z.B. die Vorschaubox dazustellen, tun sich mit JavaScript aber immer noch sehr schwer und können solche Seiten meist (noch) nicht rendern.

Zwischenfazit: Google kann wohl JavaScript meist rendern, andere Bots tun sich sehr schwer.

Server Side Rendering!

Dazu kommt die Tatsache, dass auch wenn GoogleBot anscheinend in der Lage ist Angular, React & Co clientseitig zu rendern, JavaScript den Suchmaschinen das Leben deutlich schwerer macht! Denn Rendering braucht enorme Ressourcen. Dadurch wird der an sich recht reinfache Prozess des Crawlens und Indexierens enorm aufwendig und ineffizient. Wie John Müller und Tom Greenway in einem Vortag auf der Google I/O `18 bestätigen, kann sich im Crawl- und Indexierungsprozess das Rendering solange verzögert, bis entsprechende Ressourcen dafür frei sind.

Ganz abgesehen von den Problemen der Bots kann client-seitiges Rendering auch für User Nachteile mit sich bringen. Zumindest der Initial Page Load, also das Laden der ersten Seite, dauert in der Regel deutlich länger, weil das Rendering komplett vom Client übernommen werden muss. Zusätzlich hängt die Ladezeit von der Qualität und Rechenleistung des jeweiligen Endgeräts ab.

Deshalb lautet das Zauberwort um JavaScript Frameworks SEO tauglich zu machen: Server-Side-Rendering. Statt den HMTL-Code erst auf Client-Seite errechnen zu lassen, wird die Seite schon serverseitig „vor-gerendert“ (pre-rendering) und fertig ausgeliefert. Dazu gibt es verschiedene Lösungen, die PhantomJS, headless Chrome oder einen anderen headless Browser nutzen, um die Seiten bereits auf dem Server zu rendern.

Vergleich client-side rendering & server-side rendering

Nun gibt es aber mehrere Möglichkeiten, wann und wie Browsern (also normalen Usern) und Crawlern serverseitig vorgerenderte Seiten ausgespielt werden sollen.

1. Server-Side Rendering für Alle

Sowohl Browser als auch Crawler bekommen direkt das serverseitig vorgerenderte HTML ausgespielt. Alles JavaScript das nötig ist um die Seite grundsätzlich zu rendern läuft bereits auf dem Server. Client-seitig wird nur noch JavaScript ausgeführt, das von Nutzer-Interaktionen her rührt. Große Erfolge mit dieser Technik verbuchte Netflix, die durch die Umstellung auf server-seitiges Rendering die Ladezeiten der Netflix Seite sich um 50% verbessert konnten:

2. Dynamic Rendering

Bei dem Modell, dass Google „Dynamic Rendering“ nennt wird zwischen Browser und Crawler unterschieden. Während ein normaler Browser die JS Version der Seite ausgeliefert bekommt und diese clientseitig rendern muss, bekommen Crawler eine pre-rendered Version.
Dabei braucht es eine Middleware, die unterscheidet ob der Zugriff von einem normalen Browser oder eben einem Bot kommt. Hier wird einfach der User-Agent ausgelesen und gegebenenfalls auch die IP-Adresse verifiziert, von der ein Bot üblicherweise zugreift. Dazu erwähnt John Müller im Google I/O `18 Talk auch, dass diese Variante nicht als Cloaking gewertet wird.

3. Hybrid Rendering (Isomorphic Rendering)

Google empfiehlt eine Hybrid Rendering Lösung, bei der sowohl normale User, als auch Suchmaschinen eine vorgerenderte Version der Seite ausgeliefert bekommen. Erst wenn der User beginnt mit der Seite zu interagieren, beginnt das JavaScript über das DOM den Quellcode zu verändern. Teilweise wird JS also bereits auf dem Server ausgeführt, für weitere Aktionen wird JS erst clientseitig ausgeführt.

Für das Angular Framework gibt es aber mit Angular Universal schon ein Modul, das ein solches Setup erleichtern soll. Trotzdem scheint es aber sehr aufwendig zu sein ein solches Setup sauber aufzusetzen.

Bekommt Google Bot die richtige Version?

Um zu testen, ob Google nun eine pre-rendered Version der Seite ausgeliefert bekommt, kann man wieder auf die „Fetch as Google“ Funktion in der Search Console zurückgreifen und sich den Quellcode ansehen. Der Googlebot sollte dann den komplett gerenderten HTML Code sehen, während im Browser der minimalistische HTML Quellcode der JS Version zu sein scheint. Zwei weitere Tools, um zu sehen welche Source der Googlebot zu sehen bekommt, sind der Mobile-First Test, für die mobile Seiten und der Rich Results Test für Desktop Ansicht.
Natürlich kann man auch andere Tools einsetzen, wie den SEO Crawler Screaming Frog (der auch JavaScript Rendering beherrscht und man sich Original und Rendert HTML ausgeben lassen kann) oder SEO Online Tools wie das Technical SEO Fetch & Render Tool

 

Bildnachweis: Alle Bilder sind Screenshots aus dem Vortrag von John Müller und Tom Greenway auf der Google I/O `18, Headerbild: Eigene Collage

Die SMX in München ist ein Pflichttermin für alles SEOs. Es ist ein großartiges Event mit hochkarätigen Vortragenden, Informationen über die neuesten Entwicklungen in der Branche und tollen Gelegenheiten für Networking und Austausch mit Experten.

Auch 2019 ist die SMX München wieder die wichtigste Konferenz rund um die Themen SEO & SEA im deutschsprachigen Raum. Auch wir sind wieder dabei, um uns die neuesten Inputs zu holen.

Das Programm steht zwar noch nicht fest, wir sind uns aber sicher, dass es auch 2019 wieder sehr gute Vorträge und viel Information geben wird.

Jetzt mit unserem Rabattcode 15% sparen

Der Rabattcode lautet KLOOSSMX. Jetzt buchen und 15% Rabatt auf die Tickets bekommen!

Hier geht’s direkt zur Buchung für 2019: https://smxmuenchen.de/anmelden/

 

Ein Google MyBusiness Listing ist für viele lokale Unternehmen essentiell. Der Eintrag wird nicht nur prominent für eindeutige Suchen nach dem Unternehmen oder der Marke selbst angezeigt, sondern kann auch für generischere Suchanfragen im sogenannten „Localpack“, den lokalen Suchergebnissen und natürlich auf Google Maps auftauchen.

Weiterlesen

Der 25. Mai 2018 soll in Sachen Datenschutz in der Europäischen Union eine Zeitenwende einläuten. Denn an diesem Tag wird die neue Datenschutzgrundverordnung (DSGVO) der EU in Kraft treten. Und anders als EU-Richtlinien wird die DSVGO als Verordnung direkt zu geltendem Recht und muss nicht erst von den einzelnen Mitgliedsstaaten in nationales Recht umgesetzt werden.

Die DSGVO wird viele Rechtsbereiche – vom Arbeitnehmer-Datenschutz bis hin zu Videoüberwachung – betreffen und vor allem besondere Auswirkungen auf die Online Welt haben. In Folge zur DSGVO soll auch eine neue ePrivacy-Verordnung kommen, die die bisher geltende ePrivacy-Richtlinie (RL 2002/58/EG) und auch die sogenannte Cookie-Richtlinie (RL 2009/136/EG) ablösen soll.

Als Website Betreiber interessiert mich natürlich, wie sich die User auf den Seiten verhalten. Das gilt für alle: Betreiber von großen Online-Shops über Dienstleistungsunternehmen bis hin zu Bloggern. Woher sie kommen, was sie tun und vielleicht sogar wer sie sind? Am häufigsten wird dazu Google Analytics eingesetzt. Aber darf man das ab Mai überhaupt noch?

Google Analytics nach DSGVO erlaubt?

Die neue Datenschutzgrundverordnung ist nach dem Prinzip aufgebaut, dass jede Verarbeitung personenbezogener Daten grundsätzlich verboten ist, außer wenn das Gesetz sie ausdrücklich erlaubt (sog. Verbot mit Erlaubnisvorbehalt).

Zu diesen Ausnahmen (Art. 6f, DSGVO) gehören unter anderem, wenn:

  • der Nutzer seine Einwilligung zu einer Verarbeitung seiner Daten abgibt.
  • eine Verarbeitung für die Erfüllung eines Vertrags oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist.
  • eine Verarbeitung zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist.
  • eine Verarbeitung zur Wahrung der berechtigten Interessen des Verantwortlichen oder eines Dritten erforderlich ist und keine schutzwürdigen Interessen des Betroffenen überwiegen.

Neben der Einwilligung des Nutzers dürfte vor allem die letzte Ausnahme für die Nutzung von Google Analytics interessant sein.

Besuchertracking als berechtigtes Interesse

Ein normales Besuchertracking, also die Aufzeichnung und Verarbeitung pseudonymisierter Daten für statistische Zwecke (also Google Analytics in der Standard-Version), zählt damit wohl als „berechtigtes Interesse des Webseite Betreibers“, das von keinen schutzwürdigen Interessen der User überwogen wird. So schreibt der deutsche Datenschutz-Anwalt Dr. Thomas Schenke in seinem Blog sogar, dass „im Ergebnis […] Onlinemarketingmaßnahmen damit zulässig [sind], wenn der Schutz der Privatsphäre der Nutzer nicht höher wiegt.“

Damit man Google Analytics aber wirklich rechtssicher einsetzen kann, müssen folgende vier Punkte erfüllt sein (die auch bisher schon empfehlenswert waren, um Analytics datenschutzsicher zu nutzen).

  1. Auf jeden Fall muss die IP-Adresse der User anonymisiert werden. Dabei werden die letzten Stellen der IP gelöscht, bevor die Daten auf Google-Servern gespeichert werden, sodass eine eindeutige Zuordnung zu einem Gerät nicht mehr möglich ist.
  2. In der Datenschutzerklärung müssen User über die Verwendung von Google Analytics und die Funktionsweise hingewiesen werden, aufgelistet werden, welche Arten von Daten erfasst werden. Ein Muster für eine solche Datenschutzerklärung bietet etwa die Wirtschaftskammer an: Datenschutzerklärungsmuster
  3. Dem User muss die Möglichkeit des Opt-Out angeboten und aufgezeigt werden.
  4. Weil rechtlich gesehen die Datenverarbeitung durch einen Dritten – im Fall von Google Analytics durch Google – stattfindet, muss man als Webseitenbetreiber einen Vertrag zur Auftragsdatenverarbeitung abschließen.

Google Analytics datenschutzkonform einrichten – So geht’s

 

Nachdem im Schatten der Snowden-Enthüllungen der europäische Gerichtshof im Herbst 2015 das bis dahin gültige Safe Harbor für ungültig erklärt hat, wurde im Juli 2016 das Privacy Shield Abkommen zwischen EU und USA (sowie zwischen der Schweiz und den USA) verabschiedet. Seit September 2016 ist Google gemäß dieses Abkommens zertifiziert, sodass die Übertragung von Daten auf Google Server in den USA gedeckt ist.

Diese Auftragsdatenverarbeitung wird auch nach der DSGVO zukünftig erlaubt bleiben. Das heißt, dass jeder der auf seiner Seite Google Analytics einsetzt einen Vertrag zur Auftragsdatenverarbeitung mit Google abschließen muss.
Während deutsche Websitebetreiber dazu (bisher) explizit den von Google bereitgestellten Vertrag ausdrucken, unterzeichnen und per Post nach Irland zu Google schicken müssen, reicht es in anderen EU-Ländern und der Schweiz online den „Zusatz zur Datenverarbeitung“ zu akzeptieren. Sobald die Datenschutzgrundverordnung schlagend wird, also mit 25.Mai können dann auch deutsche Websitebetreiber die elektronische Zustimmung nutzen. (Dazu einfach in der Verwaltungsansicht auf Kontoebene in den Kontoeinstellungen ganz unten auf „Zusatz anzeigen“ klicken, dann auf „Zustimmen“ und schließlich abspeichern.)

Cookies

Laut der aktuell noch heiß diskutierten ePrivacy-VO (sie dürfte wohl nicht vor 2019 schlagend werden) dürfen Cookies auf den Endgeräten der User nur noch dann gesetzt werden, wenn diese ihre ausdrückliche Einwilligung geben. Nur wenn ein Cookie technisch notwendig ist, wie etwa ein Session Cookie, das sich den Login Status merkt, darf es ohne die Einwilligung des Users gesetzt werden.

Nun setzt aber Google Analytics auch Cookies, etwa um User innerhalb einer Sitzung wiederzuerkennen und so Verhaltensmuster aufzuzeichnen. Nach der aktuellen Fassung würde die ePrivacy-Verordnung tatsächlich auch das Setzen von Cookies für Webanalyse und Reichweitenmessung, sofern diese selbst durchgeführt wird, ohne Einwilligung erlauben. Mit der Vereinbarung über eine Auftragsdatenverarbeitung (damit führt der Betreiber die Messung rechtlich selbst durch) wären damit Google Analytics Cookies erlaubt, ohne, dass der User gefragt werden müsste.

Update – 13.4.2018:  Mit 12.April launchte Google eine Steueroption zur Datenaufbewahrung ( Data Retention Control). Damit kann man als Webmaster festlegen, nach welcher Zeit Nutzerdaten automatisch von den Google Servern gelöscht werden sollen. Per default scheint dieser Wert auf 26 Monate gesetzt zu sein.

Außerdem wurde ein Tool angekündigt, um in Zukunft alle Daten, die einem einzelnen User zugeordnet werden können aus Analytics zu löschen.

 

Disclaimer: Achtung! Wir haben diesen Artikel nach ausgiebiger Recherche und Gesprächen mit Spezialisten nach besten Wissen und Gewissen geschrieben, sind aber keine Rechtsanwälte. Wir übernehmen keine Haftung für eventuell resultierende Schäden aus der Nutzung bzw. Nichtnutzung der Informationen dieses Blogs. Für detaillierte und rechtsichere Informationen zum Thema DSGVO, ePrivacy oder allgemeinen datenschutzrechtlichen Fragen sollten Sie einen fachkundigen Rechtsanwalt für Datenschutz aufsuchen.

Bildnachweis: Photo by Scott Webb on Unsplash

Mehr als ein Viertel aller Internetseiten laufen mittlerweile mit WordPress. Die ehemalige Blogging-Software hat sich damit zum erfolgreichsten Content-Management-System aller Zeiten entwickelt. Vom persönlichen Blog, über Shopsysteme bis hin zum großen Nachrichtenmedium lässt sich auf WordPress Basis nahezu alles umsetzen.
Weiterlesen

Oft scheitern meine SEO Angebote nicht am Preis, sondern vielmehr am Aufwand, der auf den Kunden zukommt. Wenn man SEO richtig macht, dann bedeutet das sehr viel Arbeit. Ein Teil dieser Arbeit fällt auf den Kunden, außer er hat genug Kapital um auch dafür eine Agentur oder einige Freelancer zu beauftragen. Eine gut durchdachte SEO Strategie kombiniert alle Ressourcen und es entsteht Arbeit auf mehreren Gebieten: Presseaussendungen, das Schreiben von Inhalten, Blogging, Soziale Medien, Web Design und Web Development.

Der nötige Aufwand hängt hauptsächlich von der Konkurrenz ab. Wenn ein Kunde eine Website mit 15 Seiten hat und die Konkurrenz 500 Seiten im Google Index gelistet hat, dann muss ich dem Kunden sagen, dass sich einige Leute seines Teams ernsthaft mit dem Erstellen neuer Inhalte beschäftigen müssen – in der Größenordnung von 50 bis 100 Seiten pro Monat – um konkurrenzfähig zu werden. Für viele Website Betreuer klingt das natürlich sehr erschreckend, aber wenn sie in ihrer Nische zur Autorität werden möchten, dann ist es notwendig viele und vor allem gute Inhalte zu haben.

Es gibt etliche SEO Agenturen, die den Prozess und den Aufwand beschönigen und herunterspielen nur um den Auftrag zu bekommen. Mir ist es aber lieber gleich zu scheitern, als erst nach 3 Monaten, wenn die versprochenen Resultate noch nicht eingetroffen sind. Es gibt einfach keine Abkürzungen bei einer guten Suchmaschinenoptimierung. Der Kunde muss von Anfang an ganz genau informiert werden, was an Änderungen und Erweiterungen notwendig sein wird und auch davon, welchen Teil er zu übernehmen hat.

Heutzutage ist SEO nicht mehr rein technisch und schnell erledigt, sondern es beinhaltet das Stärken des Firmennamens, Netzwerke, Public Relations, etc. Wundermittel gibt es keine – oder sie bringen einen kurzlebigen Erfolg vor einem totalen Absturz.

Ich denke, dass Kunden Ehrlichkeit sehr schätzen. Daher halte ich nichts von SEO Firmengeheimnissen und dergleichen, sondern bemühe mich, meine Kunden aufzuklären und ihnen beizubringen, was man tun muss um erfolgreich zu sein.