Individuelle 404-Seiten und Soft 404s: die Fehlerseite mit dem Fehlerstatus ausliefern

Worum es geht

Googles Dokumentation zur Fehlerbehebung definiert einen Soft 404 als eine URL, die eine Seite zurückgibt, die den Nutzenden mitteilt, die Seite existiere nicht, dabei aber gleichzeitig einen 200-Status liefert, und nennt Ursachen wie eine fehlende Include-Datei, eine unterbrochene Datenbankverbindung, eine leere Suchergebnisseite oder eine fehlende JavaScript-Datei; solche Seiten werden von der Suche ausgeschlossen. Dieselbe Dokumentation empfiehlt, für verschwundene Inhalte 404 oder 410 zurückzugeben, und beschreibt eine gute individuelle 404-Seite als eine, die klar sagt, dass die Seite nicht gefunden werden kann, das Erscheinungsbild und die Navigation der Website beibehält, auf beliebte Seiten und die Startseite verlinkt und eine Möglichkeit bietet, einen defekten Link zu melden. Die Dokumentation zu den Statuscodes ergänzt, dass Inhalte aus 4xx-Antworten nicht verwendet werden und dass eine zuvor genutzte URL, die nun 4xx liefert, mit der Zeit fallen gelassen wird, wobei die Crawling-Häufigkeit sinkt.

Auf dem Server legt nginx' error_page über einen internen Redirect fest, welche URI bei bestimmten Fehlern angezeigt wird, wobei die Methode bei Nicht-GET-Anfragen auf GET geändert wird. Dieselbe Direktive kann den Status mit =response ändern; das eigene Beispiel der Dokumentation, error_page 404 =200 /empty.gif;, zeigt, wie aus einem 404 ein 200 wird. Single-Page-Anwendungen, die für jeden Pfad index.html ausliefern, erzeugen denselben Effekt konstruktionsbedingt.

Warum es wichtig ist

Ein Soft 404 verschwendet Crawling-Anfragen, hält tote URLs in Indizes, versteckt defekte Links vor dem Monitoring (alles ist 200) und verwirrt Werkzeuge, die Statuscodes als Wahrheit behandeln. Ein harter 404 mit einer nackten Server-Standardseite verliert stattdessen den Besuchenden.

So wird es angewendet

• Die Fehlerseite (error_page 404 /404.html;) ohne =200 konfigurieren und mit curl -I https://example.com/no-such-page bestätigen, dass die Statuszeile 404 zeigt und der Body die eigene Seite ist.
• Bei Single-Page-Anwendungen für dem Router unbekannte Pfade 404 vom Server zurückgeben, oder die Anwendung einen Fehlerzustand rendern lassen und, sofern das Framework es unterstützt, den Status auf der serverseitig gerenderten Antwort setzen.
• Die Seite in sich abgeschlossen gestalten: kritische Styles inline einbetten oder fingerprintete Assets über absolute Pfade referenzieren, da die fehlschlagende URL in einem tiefen Verzeichnis liegen kann.
• 404-Antworten mit Referrer loggen und durchgehen; die häufigen verdienen einen Redirect, der Rest eine Korrektur auf der verlinkenden Seite.
• Für bewusste Entfernungen 410 verwenden, um Endgültigkeit auszudrücken; die verlinkte offene Frage behandelt, wie Clients damit umgehen.

Stolpersteine

Alle unbekannten URLs auf die Startseite umleiten (ein Soft 404 mit einem 302). Fehlerseiten, die Ressourcen über relative Pfade laden und in Unterverzeichnissen kaputtgehen. Fehlerseiten, die für ihre eigenen Assets selbst 404 liefern, oder 500, weil ein Template Daten braucht, die einer Nicht-gefunden-Anfrage fehlen.

Single-Page-Anwendungen ohne serverseitige Routentabelle

Die meisten Single-Page-Anwendungen können für unbekannte Routen kein 404 vom Server zurückgeben, weil der Server die Routentabelle nicht kennt und parametrisierte Routen einen Datenabruf benötigen. Googles Dokumentation zu JavaScript-SEO nennt zwei Alternativen, die der Crawler respektiert: eine Umleitung aus JavaScript auf eine URL, die der Server mit 404 beantwortet (zum Beispiel /not-found), oder das Hinzufügen von <meta name="robots" content="noindex"> zum Dokument aus JavaScript, sobald die Anwendung feststellt, dass die Seite nicht existiert. Beides hält die Seite aus dem Index, doch keines gibt dem Monitoring einen Statuscode – deshalb, sofern vom Framework unterstützt, Prerendering oder serverseitiges Rendern des Nicht-gefunden-Zustands mit einem echten 404 bevorzugen und die JavaScript-Methoden für den Rest nutzen.