JavaScript SEO: Warum ist JavaScript eigentlich ein Problem für Suchmaschinen?

Beitrag aus Ausgabe 80 / Oktober 2019
Markus Hövener

ist Chefredakteur des Magazins suchradar und geschäftsführender Gesellschafter der SEO-/SEA-Agentur Bloofusion Germany.

Websites werden immer JavaScript-lastiger und begeben sich damit auf einen schwierigen SEO-Pfad. Denn nicht alles, was im Browser gut funktioniert, kann auch von Google & Co. erkannt werden. Wo liegen denn eigentlich die Probleme?

Früher war doch irgendwie vieles leichter für Suchmaschinen: Erst wurde eine HTML-Seite gecrawlt (also von einem Bot heruntergeladen) und dann indexiert. Durch komplexere Websites ist das so aber nicht mehr sinnvoll: Zwischen Crawling und Indexierung muss jetzt noch das Rendering erfolgen. Also: Neben dem HTML-Code wird auch JavaScript-Code ausgeführt, da dieser ja den Code verändern kann.

So können Inhalte geändert, gelöscht oder hinzugefügt werden. Bei manchen Websites wäre der Verlust gering, wenn man JavaScript nicht ausführen würde. Wenn z. B. nur eine Werbung per JavaScript nachgeladen wird, wäre das in der Regel nicht relevant. Es gibt aber immer mehr Websites, die oft auf Frameworks wie Angular oder React basieren, bei denen es zu grundlegenden Problemen in Bezug auf SEO kommen kann. Warum ist das Rendering von JavaScript in manchen Fällen ein Problem, während es in anderen Fällen problemlos ist?

Das erste Script

Ein einfaches Beispiel für JavaScript findet sich im folgenden HTML-Code:

<html><head>
<title>Alter Titel</title>
</head>

<body>
<script>document.title = "Neuer Titel";</script>
</body>
</html>

Der Seitentitel lautet eigentlich „Alter Titel“. Durch den <script>-Code wird daraus aber „Neuer Titel“. Im Browser ändert sich dadurch direkt der Tab. Aber wie geht Google damit um?

Wie man in Abbildung 1 sieht, wird die HTML-Seite (in diesem Fall durch das Google-Tool „Test auf Optimierung für Mobilgeräte“) nicht einfach nur heruntergeladen. Der JavaScript-Code wird ausgeführt, sodass im HTML-Code auch schon direkt „Neuer Titel“ (rot markiert) steht.

 

Das zweite Script

In einem zweiten Script wird faktisch das Gleiche gemacht. Der einzige Unterschied besteht darin, dass der Seitentitel erst nach 30 Sekunden ausgetauscht wird:

<html><head>
<title>Alter Titel</title>
<script>
function TitelAendern()
{
document.title = "Neuer Titel";
}
</script>
</head>

<body>
<script>setTimeout(                TitelAendern,
30000 );</script>
</body></html>

Wenn man diese HTML-Seite rendern lässt, befindet sich im gerenderten Code der alte Seitentitel. Also: Der Faktor Zeit ist offensichtlich ein kleines Problem in Sachen JavaScript.

Übrigens: Wenn man die Zeitvorgabe hinreichend klein wählt (z. B. 3 Sekunden), dann zeigt das Google-Tool durchaus den geänderten Seitentitel an.

Das dritte Script

Mit dem dritten Script kann man nun zwei grundlegende Probleme bei der Behandlung von JavaScript sehen:

<html><head>
<title>Alter Titel</title>
<script>
function TitelAendern()
{
document.title = "Neuer Titel";
}
</script>
</head>

<body>
<a onclick="TitelAendern()"           href="#">Titel ändern</a>
</body></html>

Es gibt wie beim zweiten Beispiel die Funktion TitelAendern(). Diese wird aber nur aufgerufen, wenn jemand auf den Link „Titel ändern“ klickt. Die Ausgabe vom Google-Tool ist dabei eindeutig: Auch hier wird der alte Seitentitel angezeigt. Die Funktion TitelAendern() wurde nicht ausgeführt.

Das erste grundlegende JavaScript-Problem, das sich hier zeigt: Es wird ein Event benötigt, damit die Aktion passiert. In diesem Fall müsste jemand auf den Link klicken, damit sich der Seitentitel ändern kann.

Das ist natürlich ein sehr simples Beispiel. In der Praxis sieht man das z. B. beim Thema „Endless Scrolling“, das bei Produkt- oder Artikellisten verwendet wird. Eine Shop-Seite zeigt z. B. erstmal nur zwölf Produkte an. Sobald der Nutzer durch Scrollen am Ende der zwölf Produkte angelangt, werden die nächsten zwölf Produkte nachgeladen. Das kann natürlich einige Male passieren. Aber (vereinfacht ausgedrückt): Google scrollt nicht und löst das Event am Ende der ersten zwölf Produkte nicht aus. Die Suchmaschine wird in diesem Fall also immer nur zwölf Produkte „sehen“.

Analog kann es noch viele andere ähnliche Events geben, die Nutzer auf Websites vollziehen, die Google aber nicht ausführt. Hier muss also jeweils geprüft werden, welche Inhalte Google wirklich „sehen“ kann.

Ein anderes Problem: Beim Beispiel oben ist die Änderung der Seite ja nur minimal. Es gibt aber durchaus Seiten, bei denen sich durch JavaScript relativ viel ändert. So könnte z. B. auf der Seite eine Nachricht angezeigt werden; durch den Klick würde diese Nachricht dann durch eine andere Nachricht ersetzt werden.

Nun stellt sich die Frage, ob es für diese Seite auch eine URL gibt. Wie beim Beispiel oben: Es gibt keine URL für die Seite mit dem Seitentitel „Neuer Titel“. Suchmaschinen – und vor allem Google – arbeiten aber immer URL-basiert. Ob Crawling oder Indexierung: Die Basis besteht immer aus URLs. Und wenn es für die Seite mit der zweiten Nachricht keine URL gibt, wird Google auch nur die erste Nachricht crawlen und indexieren können.

Komplexere Probleme

Die Code-Beispiele in diesem Artikel waren absolut trivial. In der Praxis ist der JavaScript-Umfang in der Regel deutlich größer. Und genau da kann es natürlich weitere Probleme geben.

Dabei ist vor allem schwierig, dass manchmal Funktionen zum Einsatz kommen, die im Browser sinnvoll sein können, die von Google aber konzeptbedingt nicht unterstützt werden. So kann man aus einem Browser heraus durchaus auf die Camera API zugreifen, um Fotos zu machen. Google hat allerdings keine Kamera, auf die zugegriffen werden könnte. Auch Cookies und lokal gespeicherte Dateien (z. B. localStorage) werden nicht gespeichert, sodass es keine sogenannte Persistenz gibt. Jede Seite wird einzeln geladen, ohne dass sie auf Spuren anderer Seiten zurückgreifen kann.

Evergreen

In der jüngeren Vergangenheit gab es zudem das Problem, dass Google für seinen Crawler eine veraltete Chromium-Version nutzte. Es konnte also durchaus einige JavaScript-Funktionen geben, die im Chrome-Browser bereits unterstützt wurden, die der Googlebot aber nicht kannte.

Vor einigen Wochen hat Google das geändert und dem Googlebot ein „Evergreen Chromium“ spendiert (webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html). Das bedeutet, dass der Googlebot immer auf der aktuellen Chrome-Version basiert. Welche Version das gerade ist, kann man übrigens auf der Seite valentin.app/render.html erfahren.

Ein kleines Problem gibt es aber noch: Die anderen Google-Tools sind noch nicht auf „Evergreen“ umgestellt (twitter.com/g33konaut/status/1158419668140347392, siehe Abbildung 2). Wer also z. B. auf das Tool „URL-Prüfung“ in der Google Search Console zurückgreift, wird damit nicht exakt prüfen können, wie der Googlebot später die Inhalte erkennt. Es kann also in Einzelfällen dazu kommen, dass bei der „URL-Prüfung“ wg. des Fehlens einer bestimmten JavaScript-Funktionalität Content nicht sichtbar ist, während der Googlebot diese problemlos erkennen kann. Wie Martin Splitt von Google in seinem Tweet aber auch schreibt, ist die Umstellung auf „Evergreen“ noch nicht erfolgt, was aber wohl nur noch eine Frage der Zeit ist.

 

Crawler

Auch die beliebten Crawling-Tools wie der Screaming Frog SEO Spider oder auch Ryte mussten sich an die Entwicklung anpassen. Viele Crawler unterstützen mittlerweile auch JavaScript und rendern die Inhalte.

Beim Screaming Frog SEO Spider muss man das zunächst aktivieren (Configuration > Spider > Rendering > JavaScript). Wer dann auch noch einstellt, dass der HTML-Code gespeichert werden soll (Configuration > Spider > Advanced > Store HTML), der kann den Code vor und nach dem Rendern sehen (siehe Abbildung 3).

 

Auch hier gilt aber leider, dass die jeweilige Chromium Engine nicht immer der aktuellen Version entsprechen muss. Unter „Help > Debug“ kann man die jeweilige Version einsehen. Im Einzelfall kann es also Unterschiede zwischen dem SEO Spider und dem Googlebot geben.

Nicht nur Google

Gerade wer eine internationale Website betreibt, sollte sich dem Thema JavaScript nicht nur aus Google-Sicht nähern. Auch Suchmaschinen wie Bing und Yandex können durchaus Traffic-relevant sein.

So hat ein mittlerweile zwei Jahre alter Test von Bartosz Góralewicz (moz.com/blog/search-engines-ready-for-javascript-crawling) gezeigt, dass Google zwar durchaus mit vielen JavaScript-Frameworks gut umgehen kann. Für Bing, Yandex oder auch Baidu galt das allerdings gar nicht. Sicherlich hat sich seitdem einiges verbessert. Die Unterstützung scheint aber bestenfalls ansatzweise an das heranzureichen, was Google bietet.

Hilfe von Google

Zu dem Themenkomplex „JavaScript und SEO“ gibt es auch von Google einige relevante Hilfeseiten:

Grundlagen von JavaScript-SEO
developers.google.com/search/docs/guides/javascript-seo-basics

Für die Suche relevante JavaScript-Probleme beheben
developers.google.com/search/docs/guides/fix-search-javascript

Dynamisches Rendering implementieren
developers.google.com/search/docs/guides/dynamic-rendering

Fazit

JavaScript kann in Bezug auf SEO zu ernsthaften Problemen führen – aber vor allem dann, wenn JavaScript sehr tief in der Implementierung der Website verankert ist. In jedem Fall muss also vor der Entwicklung einer Website geprüft werden, wie diese für den Googlebot sauber abgebildet werden kann.

Spannend? Dieser Artikel ist im suchradar #80 erschienen

Lesen Sie weitere spannende Artikel aus der Ausgabe „JavaScript: Der Code-Baukasten für SEO, SEA & Co.“! Entweder online oder als PDF-Magazin.

Kostenlos als PDF-Version Alle Artikel aus der Ausgabe ansehen