Warum eine React-Website für Suchmaschinen unsichtbar sein kann
Veröffentlicht am · zuletzt aktualisiert am
Eine moderne Website mit React, Vue oder Angular hat eine Eigenschaft, die im Browser nie auffällt und für Suchmaschinen alles entscheidet: Der Inhalt existiert im ausgelieferten HTML nicht. Was der Server schickt, ist ein weitgehend leeres Dokument mit einem einzigen Container, meist einem div mit der Kennung „root", und einem Verweis auf ein JavaScript-Bündel. Erst dieses Bündel baut die Seite auf.
Für Besucher ist das unsichtbar; es passiert in Millisekunden. Für alles, was HTML liest ohne JavaScript auszuführen, ist die Seite leer.
Wer JavaScript ausführt und wer nicht
Die verbreitete Beruhigung lautet: Google rendert JavaScript, das Problem ist gelöst. Das stimmt zur Hälfte. Googlebot führt JavaScript aus, aber in einem zweiten Durchgang, der zeitlich vom ersten getrennt ist. Zwischen dem Erfassen des HTML und dem Rendern können Stunden oder Tage liegen. Bis dahin kennt der Index eine Seite ohne Inhalt.
Vor allem aber ist Google längst nicht mehr der einzige Abnehmer. Wer heute prüft, welche Systeme eine Website abrufen, findet daneben eine ganze Reihe, die kein JavaScript ausführen:
- Antwortmaschinen und KI-Assistenten, die Quellen für ihre Antworten holen
- Vorschaugeneratoren von Messengern und sozialen Netzwerken: der Kasten mit Titel und Bild, der beim Teilen eines Links erscheint
- Kleinere Suchmaschinen und viele SEO-Werkzeuge
Für diese Gruppe gibt es keinen zweiten Durchgang. Was im ersten HTML nicht steht, existiert nicht.
Ein SEO-Werkzeug ohne JavaScript-Rendering meldet gegen jede SPA „kein Inhalt", „keine Überschrift", „kein strukturiertes Datenformat", und liegt damit falsch. Ein leeres Ergebnis ist erst dann ein Befund, wenn gerendert wurde.
Die drei üblichen Lösungswege
Server Side Rendering
Die Anwendung läuft auf dem Server und liefert fertiges HTML an alle aus, Mensch wie Maschine. Das ist der sauberste Weg, weil es kein Auseinanderfallen von zwei Auslieferungen gibt. Der Preis: Die Anwendung muss dafür gebaut sein. Nachträglich auf SSR umzustellen bedeutet in der Regel einen Umbau, keinen Schalter.
Statische Erzeugung zur Bauzeit
Beim Bauen wird jede Seite einmal zu HTML gerendert und als Datei abgelegt. Ideal für Inhalte, die sich selten ändern. Für Seiten, deren Inhalt pro Aufruf variiert, funktioniert es nicht.
Prerendering für Maschinen
Ein vorgeschalteter Dienst erkennt an der Kennung des Abrufers, ob ein Mensch oder eine Maschine anfragt. Menschen bekommen die Anwendung wie bisher; Maschinen bekommen HTML, das ein Browser ohne Oberfläche zuvor fertig gerendert und zwischengespeichert hat.
Der Vorteil: Es lässt sich vor eine bestehende Anwendung setzen, ohne sie umzubauen. Der Nachteil: Es entstehen zwei Auslieferungswege, die auseinanderlaufen können, und genau daraus entstehen die Fehler, die am schwersten zu finden sind.
Warum der übliche Test nichts beweist
Wer prüfen will, ob eine Seite für Suchmaschinen funktioniert, ruft sie üblicherweise mit der Kennung eines Crawlers ab und schaut auf den Statuscode. Kommt 200 zurück, gilt die Sache als erledigt.
Das ist der Trugschluss. Bei einem Aufbau mit Prerendering sind zwei Dinge unabhängig voneinander: ob die Seite ausgeliefert wird, und ob sie gerendert wird. Fällt nur das Rendern aus, bekommt der Crawler die leere Hülle, mit Statuscode 200. Der Mensch sieht eine vollständige Seite, das Prüfwerkzeug meldet grün, und trotzdem kennt der Index nichts.
Der einzige belastbare Test ist deshalb nicht der Statuscode, sondern der Umfang: Wie viele Wörter stehen im gelieferten HTML, wenn man es mit der Kennung eines Crawlers abruft? Eine zweistellige Zahl bedeutet leere Hülle, unabhängig davon, was der Statuscode sagt. Eine dreistellige bedeutet, dass das Rendern funktioniert hat.
Ein zweiter Punkt, der gern übersehen wird: Zwischengespeicherte Ergebnisse haben eine Haltbarkeit. Wer den Inhalt ändert, neu ausrollt und sofort nachmisst, misst unter Umständen die alte Fassung, und zwar so lange, wie der Zwischenspeicher gültig ist. Nach jeder inhaltlichen Änderung gehört er geleert, sonst ist die Kontrolle einen Tag lang falsch-negativ.
Zwei Fehlerbilder, die typisch sind
Der Renderer ruft sich selbst auf
Der vorgeschaltete Dienst holt die Seite über die öffentliche Adresse statt intern und reicht dabei die Kennung des ursprünglichen Abrufers weiter. Die Weiche vorne erkennt erneut einen Crawler und schickt die Anfrage wieder zum Renderer. Das läuft, bis alle Renderplätze belegt sind. Danach beantwortet der Server jede Crawler-Anfrage mit einer Fehlermeldung, während Menschen weiterhin bedient werden.
Vorbeugen lässt sich das mit zwei einfachen Riegeln: intern anfragen statt über die öffentliche Adresse, und eine Markierung mitschicken, an der die Weiche eine Anfrage des Renderers erkennt und durchwinkt.
Erfundene Adressen belegen die Renderplätze
Liefert die Anwendung für jeden erdachten Pfad die Hülle mit Statuscode 200 aus, hält der Server jede erfundene Adresse für eine gültige Seite und lässt sie rendern. Teuer ist dabei weniger das Abrufbudget der Suchmaschine als die begrenzte Zahl gleichzeitiger Renderplätze.
Die Gegenmaßnahme ist eine ausdrückliche Liste gültiger Adressen: Was nicht darauf steht, bekommt eine Fehlerseite und erreicht den Renderer gar nicht erst. Eine offene Mustererkennung wäre bequemer, ließe aber genau die Lücke offen, die sie schließen soll.
Was das für ein Projekt bedeutet
Wer neu baut und Sichtbarkeit braucht, wählt am besten von vornherein einen Aufbau, der HTML serverseitig erzeugt. Das erspart die gesamte Klasse von Fehlern, in der sich zwei Auslieferungswege auseinanderentwickeln.
Wer eine bestehende Anwendung hat, für die ein Umbau nicht in Frage kommt, fährt mit Prerendering gut, sofern die Kontrolle stimmt. Drei Dinge gehören dann fest zum Vorgehen: an der Wortzahl prüfen statt am Statuscode, den Zwischenspeicher nach jeder Inhaltsänderung leeren, und die Liste gültiger Adressen pflegen, sobald eine Seite dazukommt.
Diese Seite hier ist selbst so gebaut, samt der beschriebenen Riegel. Die Fehlerbilder oben sind keine ausgedachten Beispiele. Wie wir Weboberflächen umsetzen, steht unter Webdesign; wenn es um automatisierte Abläufe dahinter geht, unter Prozessautomatisierung. Was ein solcher Umbau kostet und welche Posten dabei den Ausschlag geben, steht in der Kostenübersicht für Webprojekte.
Aimani Support