JavaScript SEO Basics

Geschrieben am: 23. April 2018 | Zuletzt aktualisiert: 27. August 2022 | Lesezeit: ca. 8 Min.

JavaScript SEO

Bereits 2016 wurde ich auf den Artikel “Does Google execute JavaScript?” aufmerksam. Darin werden verschiende JavaScript Szenarien durchgespielt und geprüft wie Google damit umgeht. Da der Autor so freundlich war die Testdaten auf Github zu veröffentlichen, habe ich mal ein paar eigene Tests diesbezüglich aufgesetzt um den Umgang Goolges mit JavaScript besser zu verstehen.

Ausgangslage

Jahrelang war der Inhalt des Seitenquelltextes ausschlaggebend über das was von Google und den anderen Suchmaschinen gelesen werden konnte. Seit einiger Zeit sind die Suchmaschinen jedoch dazu übergegangen nicht nur den Quelltext auszuwerten, sondern auch JavaScript auszuführen. Da durch den Einsatz von JavaScript nicht nur optische Effekte, sondern auch Änderungen am Seiteninhalt vorgenommen werden können, liegt eine korrekte Ausführung von JS auch im Intresse der Suchmaschinen.

Testaufbau

Um ein besseres Verständnis zu bekommen welche Auswirkungen die Verwendung von JavaScript auf SEO hat habe ich ein paar einfache JavaScripte – analog des oben erwähnten Tests – an den Google Index geschickt. Jedes dieser Scripte verändert beim Ausführen einen Teil der Texte auf der Seite.

Das HTML

Unter https://www.michaelhohenleitner.de/js-test/ habe ich eine HTML Datei erstellt, die im Body des Quelltextes folgendes enthält:

<h1>JavaScript SEO Test</h1>
<div id="content-load-intern">
<p style="color: red;">JS Wird nicht ausgeführt</p>
</div>
<div id="content-load-head">
<p style="color: red;">JS nach load wird nicht ausgeführt</p>
</div>
<div id="content-load">
<p style="color: red;">JS DOMContentLoaded von extern wird nicht ausgeführt</p>
</div>
<div id="content">
<p style="color: red;">JS nach load wird nicht ausgeführt</p>
</div>
<div id="content-robots">
<p style="color: red;">Via Robots.txt gesperrtes JS Wird nicht ausgeführt</p>
</div>
<div id="content-timeout">
<p style="color: red;">Warten auf timeout...</p>
</div>
<div id="ajax">
<p style="color: red;">Warten auf ajax.</p>
</div>

Ein Aufruf der Website mit deaktiviertem JavaScript ergibt also folgendes Bild:

Die 7 Container zeigen 1:1 den Inhalt aus dem HTML Quelltext.

Mit JavaScript

Am HTML wunde nun nichts mehr verändert. Lediglich JavaScript wurde im Browser aktiviert und einige Scripte eingefügt.

Internes JavaScript

Als leichteste Übung wurden nun im Header zwei JavaScripte eingefügt die

• Mit DOMContentLoaded Event den Inahlt des ersten Containers austauschen
• Mit dem Load Event den Inhalt des zweiten Containers austauschen

Das DOMContentLoaded Event wird abgefeuert soblad das DOM vollständig geladen wurde. Das Load Event hingegen wartet auch noch das vollständige Laden verlinkter JavaScript und CSS Dateien ab.

<script> 
document.addEventListener('DOMContentLoaded', function() {
document.getElementById('content-load-intern').innerHTML =
'</p>
<p>
</p>
<h2 style="color:green">Ich stehe im Head und komme mit dem Event DOMContentLoaded</h2>
<p>
</p>
<p>';
}, false);
</script>
<script>
window.addEventListener("load", function(event) {
document.getElementById('content-load-head').innerHTML =
'</p>
<p>
</p>
<h2 style="color:green">Ich stehe im Head und komme mit dem Event load</h2>
<p>
</p>
<p>';
}, false);
</script>

Der Inhalt der beiden ersten Boxen sieht im Browser bei aktiviertem JavaScript nun wie folgt aus:

Bereits jetzt ist der Blick in den Quelltext (sofern man die Scripte im Head nicht beachtet) nicht mehr ausreichend um den Seiteninhalt nachzuvollziehen.

Externe JavaScripte

Im nächsten Schritt wurden einige externe JavaScripte in die Seite eingebunden:

• Ersetzen des Inhalts in Container 3 mit dem Event DOMContentLoaded
• Ersetzen des Inhalts in Container 4 mit dem Event load
• Ersetzen des Inhalts in Container 5 mit dem Event load, die verlinkte JavaScript Datei ist jedoch per Robots.txt gesperrt
• Ersetzen des Inhalts in Container 6 nach einem 3 Sekunden Timeout

Die Container 3-6 präsentieren sich nun im Browser wie folgt:

Die Veränderung des Inhalts nachzuvollziehen ohne einen Blick in die eingebundenen Datein zu werden ist so nicht mehr möglich.

Asyncrones JavaScript

Zu guter Letzt wurde noch ein asyncrones JavaScript eingebunden. Der Content im untersten Container kommt also weder aus dem Quelltext noch aus der JavaScript Datei sondern aus einer Textdatei die via JavsScript serverseitig geladen wird.

Aus

<div id="ajax">
<p style="color: red;">Warten auf ajax.</p>
</div>

wird dadurch:

<div id="ajax">
<h2 style="color: green;">Ich bin ein asyncrones JavaScript.</h2>
</div>

Zwischenfazit

Der Blick in den Quelltext bietet mittlweile keine Sicherheit darüber was der User im Browser angezeigt bekommt. Um den Seitenquelltext sinnvoll auszuwerten muss er mit einem Enwickler Tool wie Firebug betrachtet werden, da hier der finale Quelltext nach vollständigem Laden des Document Object Model (DOM) ausgegeben wird.

Zur Veranschaulichung hier noch der Vergleich zwischen Seitenquelltext und der Ansicht in der Entwicklerkonsole mit gerendertem DOM:

Welche Auswirkungen hat das auf SEO?

Das JavaScript den Seiteninhalt verändern kann ist keine Neuheit. Interessant zu beobachten ist nun wie die Suchmaschinen damit umgehen. Um einen ersten Eindruck zu bekommen wurde die Testseite in der Search Console gerendert.

Wir sehen: alle Boxen werden, mit ausnahme der per Robots.txt gesperrten, korrekt dargestellt. In der Spalte “So hätte ein Besucher Ihrer Website die Seite gesehen” nimmt es die Search Console mit der Robots.txt nicht mehr so genau und stellt auch diesen Bereich korrekt gerendert dar.

SEO Hilfe gesucht?

In einem kostenlosen Erstgespräch besprechen wir deine Situation und wie wir die SEO-Potenziale deiner Website nutzen können.

Jetzt unverbindlich Kontakt aufnehmen

Dadruch kann Google beurteilen wie wichtig einzelne Scripte für die Darstellung sind und die Meldung “Der Googlebot konnte nicht alle Ressourcen für diese Seite abrufen” entsprechend priorisieren. Auf “verstecken” von Inhalten auf URLs die mit der Robots.txt gesperrt sind sollte man also lieber verzichten.

Wie sieht der Google Cache aus?

Da Google auch in seinem Cache die Möglichkeit bietet eine gerenderte Vorschau zu betrachten werfen wir auch darauf einen Blick. Unmittelbar nach der Indexierung sind lediglich die Scripte aus dem Head ausgeführt worden. Das deckt sich mit dem ursprünglichen Test und lässt sich wohl auf die noch nicht gecrwalten JavaScript Dateien zurückführen.

In der reinen Text Version wird keines der Scripte ausgeführt:

Nach dem die JavaScript Dateien ebenfalls über die Search Console eingereicht wurden, werden nun auch die anderen Scripte gerendert. Bis auf das Ajax:

Was rankt?

Stellt sich noch die Frage ob der Content der gerendert wird auch über die Suche auffindbar ist.

Die Inhalte der beiden Scripte aus dem Header sind, wie zu erwarten war, auffindbar:

Auch bei den extern eingebundenen Scripten sieht es gut aus:

Der über die Robots.txt gesperrte Inhalt wird korrekterweise nicht ausgegeben:

Der Content nach dem drei Sekunden Timeout macht Google auch keine Probleme. Lediglich der Inhalt des asyncronen JavaScipts lässt sich nicht über die Google Suche finden:

Hier ergibt sich eine Abweichung zum Test auf stephanboyer.com. Jedoch wurde auch bei seinem Test der AJAX call erst geraume Zeit später ausgeführt:

New Years Update (1/1/2017): Apparently some time after I did this experiment Google re-indexed the page and did the AJAX call this time.Quelle

Zusammenfassung

Der Test zeigt, dass Google mit einfachen JavaScripten keine Probleme zu haben scheint. Unabhängig davon ob die Inhalte über ein externes Script kommen oder nicht. Die Analyse wird durch die unterschiedlichen Ansichten im Google Cache und der Search Console jedoch erschwert.

Wie testen?

Die SEO Software Screaming Frog bietet schon seit längerem die Möglichkeit Seiten zu Rendern:

This looks like a neat way to check JavaScript-based sites (PWA, Angular, React, etc). I don't use it, but it's cool to see tools like this! https://t.co/lJZzegmgE4

— John ☆.o(≧▽≦)o.☆ (@JohnMu) 5. Januar 2017

Das Ergebnis der gerenderten Seite in Screaming Frog deckt sich jedenfalls mit der Ansicht in der Search Console und bildet damit die über die Websuche auffindbaren Inhalte ab.

JavaScript und das Canonical Tag

Auf der diesjährigen Entwicklerkonferenz Google I/O gab Google interessante Einblicke in das Crawl und Indexierungsverhalten von JavaScript Seiten:

Datenschutzhinweis zum Abspielen von Youtube-Videos.

In diesem Video fällt auch die Aussage, dass Google die Caninical Tags ausschließlich aus dem ungerenderten HTML Code ausliest und Canonicals die via JavaScript (beispielsweise mit dem Google Tag Manager) eingefügt werden nicht berücksichtigt werden. Die wurde jedoch kürzlich in einem Test widerlegt.

Fazit

JavaScript und SEO schließen sich mitlerweile nicht mehr aus. Das nicht immer nachvollziehbare Verhalten in den Cache und Search Console Ansichten erhöhen allerdings die Komplexität.

• Reines auslesen des Quelltextes reicht nicht mehr um einen Eindruck vom Seiteninhalt zu bekommen
• Je komplexer die Integration der Inhalte ist desto höher ist das Risiko, dass sie von Suchmaschinen nicht mehr ausgelesen werden (können)
• Tools erleichtern das Testen, sind aber keine Garantie dass Suchmaschinen das Selbe Verhalten zeigen

Falls ihr ähnliche/andere oder ergänzende Erfahrungen mit dem Thema habt, schreibt gerne in die Kommentare.