Was ist JavaScript-SEO?

JavaScript-SEO ist der Teil des technischen SEO, der dafür sorgt, dass eine mit JavaScript gebaute Website durch Crawling, Rendern und Indexierung kommt. Es ist kein eigenes Fach: Es sind dieselben Fragen wie immer, gestellt zu Seiten, deren Inhalt nicht in dem HTML steht, das der Server ausliefert.

Der praktische Unterschied ist einer des Zeitpunkts. Auf einer klassischen Seite bringt das ankommende HTML den Text, die Verweise und die Angaben bereits mit. Auf einer im Browser gebauten kann dieses HTML fast leer sein, und alles Wichtige entsteht danach, wenn der Code läuft.

Das gehört ohne Alarmton gesagt: Google führt JavaScript aus, und es tut das gut. Das Problem ist nicht, dass es nicht könnte, sondern dass es zu einem anderen Zeitpunkt und unter eigenen Bedingungen geschieht — und diese Bedingungen gehören gekannt.

Zuerst gehört gesagt, was es nicht ist. Keine Frage des Frameworks: Dasselbe Framework kann eine bestens crawlbare Website hervorbringen oder eine unmögliche, je nachdem, wie die Auslieferung gebaut wurde. Dem Werkzeug die Schuld zu geben erspart die wichtige Frage — was in der ersten Antwort des Servers ankommt.

Es ist auch kein neues Problem. Geändert hat sich das Verhältnis: Heute führt fast jede Website etwas Code im Browser aus, und der Unterschied zwischen einer gesunden und einer mit Problemen liegt darin, ob dieser Code Dinge ergänzt oder alles Wichtige trägt.

Google beschreibt den Ablauf in drei Phasen: Crawlen, Rendern, Indexieren. Zwischen der ersten und der zweiten liegt eine Warteschlange, und diese Warteschlange ist die Einzelheit, die alles Weitere verändert.

Die Dokumentation ist bei zwei Dingen ausdrücklich. Erstens: Jede Seite, die mit Code 200 antwortet und keine Anweisung gegen das Indexieren trägt, kommt in die Render-Warteschlange. Zweitens: Sie kann dort einige Sekunden bleiben, aber auch länger. Es gibt keine feste Zahl, und deshalb sollte man nicht planen, als gäbe es eine.

Und es gibt einen Rückweg, den kaum jemand zeichnet: Die beim Rendern erscheinenden Verweise werden erneut gelesen und kommen in die Crawl-Warteschlange und verbrauchen Crawl-Budget. Ein Verweis, den es erst nach dem Ausführen des Codes gibt, ist nicht unsichtbar — er wird nur eine Phase später entdeckt als einer, der im HTML steht.

In dieser Beschreibung steht eine Bedingung, die man überliest und die ganze Fälle entscheidet: In die Warteschlange kommen Seiten, die mit Code 200 antworten. Eine, die einen Fehler zurückgibt, oder ein als 200 verkleideter Soft 404 mit leerer Vorlage, wird anders behandelt, bevor ihr Code überhaupt zur Ausführung kommt.

Und eine Folge, die den Rest des Eintrags ordnet: Alles, was entscheidet, ob eine URL in die nächste Phase darf, wird VOR dem Rendern gelesen. Deshalb kommt das X-Robots-Tag, das im Header der Antwort mitreist, immer rechtzeitig an — und eine per Code eingesetzte Anweisung womöglich nicht.

Der erste Fehler, und der teuerste, sind Verweise, die keine sind. Ein Element, das per Programmierung auf einen Klick reagiert, arbeitet für den Besucher und ist für niemanden sonst ein Weg; Google will einen Verweis mit seiner Adresse darin. Genau so wird ein ganzer Bereich zur verwaisten Seite.

Der zweite sind gesperrte Ressourcen. Verhindert die robots.txt das Laden der JavaScript-Dateien, findet das Rendern trotzdem statt, nur ohne sie — und heraus kommt eine indexierte Seite mit dünnem Inhalt. Ein Fall, der sich schnell erkennen lässt und monatelang übersehen wird.

Und der dritte sind Angaben, die zu spät kommen. Ein per Code eingesetztes Canonical oder Noindex wirkt womöglich nicht wie erwartet, weil die Entscheidung über die Render-Warteschlange vorher fällt, anhand dessen, was im ersten HTML stand. Was zählt, gehört in das HTML, das der Server ausliefert.

Ein vierter Fehler taucht in Listen auf: eine nur mit Code gebaute Blätterung. Liegt hinter dem Knopf zur nächsten Seite keine eigene Adresse, existiert die Paginierung für den Crawler nicht — und mit ihr verschwindet die Hälfte des Katalogs, so tadellos jede Produktseite auch sein mag.

Und ein fünfter, schwerer zu sehen: Inhalt, der beim Scrollen oder beim Öffnen eines Reiters nachgeladen wird. Dieselbe Familie wie ein schlecht gebautes Lazy Loading; erscheint etwas erst bei einer Handlung, steht es nicht auf der Seite, die Google rendert — denn währenddessen scrollt und klickt niemand.

Die Grundprüfung vergleicht zwei Fassungen derselben Seite: das HTML, das der Server ausliefert, und das HTML nach dem Ausführen des Codes. Ist das erste fast leer, weißt du bereits, dass alles an der zweiten Phase hängt.

Die URL-Prüfung der Search Console zeigt genau das, was Google gerendert hat, samt der Ressourcen, die es nicht laden konnte, und der Fehlermeldungen. Sie ist die einzige Quelle, die für Google spricht und nicht für eine Nachbildung; sie gehört vor jedes fremde Werkzeug.

Und eine Prüfung, die kaum jemand macht: im ersten HTML nach den Hauptverweisen der internen Verlinkung suchen. Stehen sie nicht darin, hängt die Entdeckung der ganzen Website an der Render-Warteschlange — und das zeigt sich zuerst bei neuen Bereichen, die länger brauchen, bis sie im Index auftauchen.

Ein billiges Verfahren für die tägliche Durchsicht: Fordere die Seite so an, wie es ein Programm ohne Browser täte, und suche in dieser Antwort die Überschrift, einen Absatz aus dem Text und drei Verweise der Navigation. Findest du sie, hängt diese Seite nicht an der zweiten Phase. Eine Prüfung von einer Minute, die die Hälfte aller Verdachtsfälle erledigt.

Für alles, was diese Probe nicht besteht, ergänzt die Logfile-Analyse den fehlenden Teil: Sie zeigt, ob der Crawler die JavaScript-Dateien überhaupt angefordert hat und wie oft es wiederkommt. Ein sprechendes Muster ist, dass die URLs als gecrawlt auftauchen, die zum Rendern nötigen Ressourcen aber so gut wie nie.

Der erste ist der Schluss, Google führe JavaScript nicht aus. Es führt es aus, und die umgekehrte Behauptung führt zu teuren Entscheidungen — etwa eine ganze Website neu zu bauen, wo es gereicht hätte, die Verweise zu reparieren.

Der zweite ist das Gegenteil: anzunehmen, weil es ausgeführt wird, gebe es nichts zu beobachten. Die Warteschlange besteht, Ressourcen sperren sich mit der Zeit von selbst, und per Code gesetzte Angaben kommen weiterhin zu spät.

Und der dritte ist, nur auf die Startseite zu sehen. Sie ist meist die bestgepflegte Seite der Website, die mit der geringsten Klicktiefe, und steht nicht für den Rest; die Renderprobleme sammeln sich auf den seriell erzeugten Detailseiten — besonders im E-Commerce, wo genau sie den Traffic bringen.

Ein vierter Fehler ist, mit dem falschen Werkzeug zu messen und ihm zu glauben. Jeder Dienst, der mit einem anderen Browser, einem anderen Netz und anderen Wartezeiten rendert, kann zu einem anderen Ergebnis kommen als Google; er taugt zur Orientierung, nicht zum Schluss. Für Google spricht die URL-Prüfung.

Und der letzte, auf Dauer teuerste: es einmal lösen und nie wieder hinsehen. Eine Veröffentlichung, die ändert, wie die Verweise erzeugt werden, genügt, damit ein ganzer Bereich nicht mehr entdeckt wird — und das schlägt nirgends Alarm. Die Website arbeitet für jeden, der sie mit einem Browser besucht, einwandfrei weiter; genau deshalb merkt es niemand.