Eigene Fehlerseiten gestalten

Die HTTP/1.1-Spezifikation definiert eine ganze Reihe von Fehlercodes, darunter die Fehler 401 (Unauthorized), 403 (Forbidden) 404 (Not Found) und 410 (Gone). Die im Falle eines Fehlers angezeigten Standardfehlerseiten reichen nicht aus, um Nutzer mit den notwendigen Informationen zur Fehlerbehandlung und weiteren Vorgehensweise zu versorgen. Dieser Artikel zeigt, wie Sie Ihre Besucher auf selbst gestaltete Fehlerseiten leiten und welche Informationen diese enthalten sollten.

Einleitung

Die erste Zeile (Statuszeile) des HTTP-Response eines Webservers entspricht stets folgendem Schema:

HTTP/<Version> <Statuscode> <Statustext>

Bei einer korrekt ausgelieferten Ressource sieht die Statuszeile in den meisten Fällen wie folgt aus:

HTTP/1.1 200 OK

Die HTTP/1.1-Spezifikation definiert in Abschnitt 10 alle in Frage kommenden Statuscodes, darunter auch eine Handvoll Fehlercodes. Ich stelle im Verlauf dieses Artikels vor allem die in der folgenden Tabelle aufgeführten Fehlercodes näher vor und zeige, wie Sie Ihre Besucher auf selbst gestaltete Fehlerseiten leiten und welche Informationen diese enthalten sollen.

Fehlercodes, die Sie entsprechend behandeln sollten
Fehlercode Statustext Beschreibung
401 Unauthorized Der Benutzer benötigt eine Autorisierung, ohne die er keinen Zugriff auf die Ressource hat.
403 Forbidden Nicht öffentlicher Bereich, auf den der Benutzer keinen Zugriff hat.
404 Not Found Die Ressource wurde unter dem angegebenen URI nicht gefunden.
410 Gone Unter dem angegebenen URI ist keine Ressource mehr erreichbar und es ist keine Weiterleitungsadresse bekannt.

Standardfehlerseiten vermeiden

Jeder, der hin und wieder mal im Web surft, kennt (leider) die Standardfehlerseiten, die Browser anzeigen, wenn vergeblich versucht wird, eine vermeintlich vorhandene Ressource aufzurufen oder in einen passwortgeschützten Bereich zu gelangen. Derartige Standardfehlerseiten sollten Sie Ihren Besuchern nicht zumuten, denn diese reichen nicht aus, sie mit den notwendigen Informationen zur Fehlerbehandlung zu versorgen. Gerade unerfahrene Besucher blicken in vielen Fällen ratlos auf die Fehlerseite und wissen nicht, was sie nun tun können, um an die gesuchte Information zu gelangen. Darüber hinaus wirkt das minimalistische Design abschreckend und gibt Besuchern das Gefühl, Ihre Website verlassen zu haben. Viel besser ist es, eigene Fehlerseiten zu gestalten und diese an das Design der Website anzupassen; sie sollten über Kernelemente wie Site Label und Navigation verfügen sowie dem grundsätzlichen Aufbau der Website entsprechen.

Jeder Webserver bietet die Möglichkeit, eigene Fehlerseiten anzulegen. Beim Apache Webserver können Sie diese über die Direktive ErrorDocument sowohl global in der Konfigurationsdatei httpd.conf festlegen, sofern Sie auf diese zugreifen können, als auch in Zugriffskontrolldateien (htaccess-Dateien). Letztere wirken sich nur auf das Verzeichnis aus, in dem sie angelegt werden, sowie auf dessen Unterverzeichnisse.

Die Direktive ErrorDocument

Die ErrorDocument-Direktive hat folgende Syntax:

ErrorDocument <Fehlercode> <Aktion>

Als Aktion können Sie einen externen oder lokalen URI zur einer eigenen Fehlerseite sowie Text angeben, der anstatt der Standardfehlermeldungen angezeigt wird. Dieser Text kann auch Markup beinhalten. Bitte beachten Sie, dass dieser Text im Apache 1.4 durch ein Anführungszeichen (U+0022) eingeleitet und im Apache 2.0 durch Anführungszeichen umfasst wird.

ErrorDocument 401 http://www.example.com/error/401
ErrorDocument 403 /error/403.php
ErrorDocument 404 "<h1>Fehler 404</h1<p>Das Dokument konnte nicht gefunden werden.</p>"

Wenn Sie auf eine externe Ressource verweisen, sollten Sie beachten, dass der Apache Webserver eine Weiterleitung zum Client sendet, um diesem mitzuteilen, wo das Dokument zu finden ist, auch wenn das Dokument letztlich wieder zum gleichen Server führt. Das führt unter anderem dazu, dass der Client zumindest vom Apache 1.3 nicht den Original-Statuscode erhält, sondern stattdessen einen Weiterleitungs-Statuscode. Dies wiederum kann Suchroboter und andere Clients verwirren, die den Statuscode dazu verwenden, herauszufinden ob ein URI gültig ist. Wenn Sie eine Fehlerseite für den Fehlercode 401 anlegen, wird der Client darüber hinaus nicht wissen, dass er den Benutzer zur Eingabe eines Passworts auffordern muss, da er den Statuscode 401 nicht erhält. Sie müssen deshalb stets auf eine interne Ressource verweisen, wenn Sie eine Fehlerseite für 401-Fehler anlegen wollen.

An dieser Stelle zeigt sich mal wieder ein Fehler im Internet Explorer in den Versionen 5.x und 6.x. Wenn Sie auf eine Fehlerseite verweisen, die kleiner als 512 Bytes groß ist, wird die Standardfehlerseite angezeigt. Achten Sie also darauf, dass Ihre Fehlerseiten ausreichend groß sind, sodass sie auch diesen Browsern »auffallen«.

Richtlinien für Fehlermeldungen

Hilfreiche Fehlermeldungen sind auffällig, verständlich und höflich formuliert, beschreiben das Problem präzise und geben konstruktive Hinweise, wie der Fehler zu beheben ist.

Fehlermeldung auffällig gestalten
Die Aufgabe von Fehlermeldungen ist es, den Nutzer darauf aufmerksam zu machen, dass etwas schief gelaufen ist. Gestalten Sie Ihre Fehlerseiten so, dass sich die eigentliche Fehlermeldung deutlich und auffällig präsentiert und klar ausdrückt, dass ein Fehler aufgetreten ist.
Fehlermeldungen verständlich formulieren
Fehlermeldungen sollten auch dann verständlich sein, wenn die technischen Zusammenhänge nicht bekannt sind. Die meisten Benutzer können mit einer allein stehenden Meldung »Fehler 404« nichts anfangen. Besser ergänzen Sie sie durch eine verständliche Ergänzung wie beispielsweise »Seite nicht gefunden«.
Fehlermeldungen höflich formulieren
Wählen Sie bei Ihren Fehlermeldungen eine Formulierung, die den Besuchern nicht das Gefühl gibt, sie hätten einen dummen, vermeidbaren Fehler begangen. »Seite nicht gefunden« beschreibt den vergeblichen Aufruf einer Ressource neutraler als »Fehlerhafte Eingabe« oder eine ähnlich offensive Formulierung.
Fehler präzise beschreiben
Treffen Sie eine klare Aussage darüber, welcher Fehler aufgetreten ist. Es kann einen Unterschied machen, ob eine Ressource unter einem URI noch nie erreichbar war oder lediglich aus irgendeinem Grund nicht mehr erreichbar ist.
Konstruktive Hilfestellungen anbieten
Fehlermeldungen dienen nicht nur dazu, Nutzer darauf aufmerksam zu machen, dass ein Fehler aufgetreten ist, sondern sie sollten dazu beitragen, den Fehler zu beheben.

Dieser Artikel betrachtet im Folgenden die in der Tabelle aufgeführten Fehler und gibt einige Hinweise zur Gestaltung der jeweiligen Fehlerseiten.

Gestaltung der Fehlerseiten

Die Standardfehlerseiten, die Browser anzeigen, wenn Sie keine eigenen Fehlerseiten definieren, geben kaum Hilfestellung, wie Nutzer an die gewünschten Informationen gelangen, und wirken aufgrund ihres reduzierten Designs wie ein Fremdkörper und nicht wie ein Teil Ihrer Website. Fehlerseiten sollten sich daher stets am Design Ihrer Website orientieren, also Kernelemente wie Logo, Site Label, grundlegenden Aufbau und Navigationsstruktur übernehmen. Besonders wichtig ist ein Link zur Homepage sowie zur Sitemap. Dadurch kann der Besucher sich schnell orientieren und die gesuchte Ressource vielleicht auf anderem Wege finden. Falls Ihrer Website aus mehr als nur einer Handvoll Seiten besteht, Sie allerdings keine Sitemap anbieten, dann erstellen Sie einfach eine! Jakob Nielsen verrät in seiner Alertbox Site Map Usability, wie eine solche auszusehen hat.

Ein Suchformular oder ein Link dorthin sollte auf keiner Fehlerseite fehlen. Das setzt natürlich voraus, dass Sie auf Ihrer Site eine Suchfunktion anbieten. Eventuell erfüllt die Einbindung einer externen Suchmaschine wie beispielsweise Google den gleichen Zweck, aber dann sollten Sie prüfen, ob alle von der Suchmaschine gelisteten URIs korrekt sind. Es wäre denkbar unglücklich, wenn ein Nutzer durch eine Trefferliste einer Suchmaschine auf Ihre Site gelangt und dort mit einer 404-Fehlerseite begrüßt wird, die ihn wieder zurück schickt.

Darüber hinaus gilt es, je nach Art des Fehlers, besondere Kriterien zu beachten.

401 – Unauthorized

Eine 401-Fehlerseite dient dazu, einen Nutzer aufzufangen, wenn er vergeblich versucht hat, sich mit Benutzernamen und Passwort auf einer Website anzumelden.

Stellen Sie sich vor, ein Nutzer klickt auf einen Link, der zu einem passwortgeschützten Bereich Ihrer Site verweist. Er wird sich mit hoher Wahrscheinlichkeit nicht anmelden können, den Anmeldedialog nach einigen Versuchen abbrechen und auf diesem Weg zur Fehlerseite gelangen. Oder ein bereits registrierter Nutzer hat seine Zugangsdaten vergessen bzw. das Passwort mehrfach falsch eingetippt. Wenn Sie sich nun in die Lage des ratlosen Nutzers hineinversetzen, kommen Sie schnell darauf, was eine 401-Fehlerseite enthalten sollte:

  • Eine eindeutige Fehlermeldung,
  • eine Erläuterung der Inhalte, die den Nutzer im passwortgeschützten Bereich erwarten, um ihm die Entscheidung zu ermöglichen, ob sich eine Anmeldung lohnt oder nicht,
  • einen Link zur Anmeldung,
  • einen Hinweis zur korrekten Eingabe der Benutzerdaten sowie
  • die Möglichkeit, sich die Zugangsdaten erneut zusenden zu lassen.

403 – Forbidden

Fehler der Art 403 begegnen Ihnen, wenn Sie ein Verzeichnis aufrufen (http://www.example.com/foo/), in dem es keine Datei gibt, die als Verzeichnisindex angegeben ist (index.htm, index.html, index.php oder andere), also kein Dokument automatisch aufgerufen werden kann, und für das auch kein automatischer Verzeichnisindex angezeigt werden soll. Das Verzeichnis einer Website, in dem alle Grafiken abgelegt sind, ist ein Kandidat für ein solches Verzeichnis, denn in den meisten Fällen möchte man unerwünschten Besuchern derartige Einblicke »unter den Rock« der eigenen Website verwehren. Sie sollten in jedem Fall klar formulieren, dass der Zugriff auf das Verzeichnis nicht erlaubt ist und den Besucher stattdessen zu einem Besuch Ihrer Website »vor der Absperrung« einladen.

404 – Not Found

Wer kennt das nicht? Man ruft eine Web-Ressource auf – und vollkommen unerwartet findet man sich im Niemandsland des Web wieder. Dafür kann es folgende Gründe geben:

  • Der URI der Ressource wurde falsch eingetippt; entweder in der Adresszeile oder beim Anlegen des Links.
  • Der Autor der Site wusste nicht, dass coole URIs sich nicht ändern und hat die Ressource gelöscht oder verschoben. Dadurch stimmen Lesezeichen, Links auf die Site sowie Einträge in Suchmaschinen nicht mehr.

404-Fehler entdecken und beheben

Fehler der Art 404 müssen Sie auf jeden Fall auffangen, schließlich handelt es sich dabei um die am häufigsten auftretende Art von Fehler im Web. Vorbildlich ist die 404-Fehlerseite der Initiative Einfach für Alle der Aktion Mensch. Die Seite ist im Design der Website gehalten, schlägt einen sehr freundlichen Ton an und ist um konkrete Hilfestellung und Problemlösung bemüht.

Um stets auf dem Laufenden zu bleiben, welche 404er auf Ihrer Site auftreten, können Sie Ihre Besucher auf der Fehlerseite um eine Mail mit einer genauen Fehlerbeschreibung bitten, wie die 404-Fehlerseite der Initiative »Einfach für Alle« schön demonstriert – aber wie oft haben Sie eine solches Fehlerformular bereits ausgefüllt? –, oder Sie lassen sich (zusätzlich) bei jedem Aufruf der Fehlerseite eine automatisch generierte Mail zusenden. Letzteres ist wesentlich effektiver.

Viele moderne Programmiersprachen bieten Mailfunktionen, die beispielsweise bei Kontaktformularen eingesetzt werden, um die gesammelten Informationen an eine Mailadresse zu verschicken. Im folgenden Beispiel wird die PHP-Funktion mail() verwendet, um sich über jeden Zugriff auf die 404-Fehlerseite per Mail informieren zu lassen. Die Syntax der Funktion ist denkbar einfach:

mail ( string Empfänger, string Betreff, string Nachricht
  [, string Header [, string Parameter]]);

Empfänger enthält dabei die E-Mailadresse des Empfängers. Betreff stellt die Betreffzeile der E-Mail dar. Message enthält den eigentlichen Körper der Nachricht. Header ist optional und bietet die Möglichkeit, die Header-Informationen der E-Mail zu verändern. Ein vierter String Parameter kann seit PHP 4.0.5 unter Umständen dazu verwendet werden, zusätzliche Parameter an das Programm zu übergeben

Das folgende Beispiel-Skript verwendet für die ersten vier Argumente der Funktion eine Variable und stellt so die konkreten Inhalte, insbesondere den des Nachrichten-Körpers, individuell zusammen. Dabei hilft der Konkatenationsoperator (.=), den Quelltext übersichtlich zu gestalten. Mit ihm ist es möglich, zusätzliche Inhalte an das Ende eines in einer Variablen abgelegten Strings anzuhängen. Die Kommentare sollten für das Verständnis ausreichend sein.

Einzige Besonderheit ist die Verwendung von Server-Variablen, die allesamt in dem Array $_SERVER[] zur Verfügung stehen. In diesem Skript werden folgende Variablen verwendet:

  • $_SERVER["SERVER_NAME"] gibt den Servernamen zurück, (z.B. www.example.com),
  • $_SERVER["REQUEST_URI"] gibt den aufgerufenen URI ausgehend vom Root-Verzeichnis zurück (z.B. /index.html),
  • $_SERVER["HTTP_USER_AGENT"] gibt den Identifikationsstring des User-Agents zurück (z.B. Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0) und
  • $_SERVER["HTTP_REFERER"] schließlich gibt den URI des aufrufenden Dokuments zurück.
<?php
  // Fehlercode
  $fehlercode = "404";

  // Adresse, an welche die E-Mail versendet werden soll
  $empfaenger = "mail@example.com";
  $betreff = "[" . $_SERVER["SERVER_NAME"] . "] Fehler " . $fehlercode;

  // Nachricht zusammenbauen.
  $message = "Auf der Website http://" . $_SERVER["SERVER_NAME"] . " ist ein Fehler " . $fehlercode . " aufgetreten.\n\n";
  $message .= "Aufgerufene Ressource:\n";
  $message .= "http://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"]."\n\n";
  $message .= "User-Agent:\n";
  $message .= $_SERVER["HTTP_USER_AGENT"];
  if($_SERVER["HTTP_REFERER"] != "") {
    $message .= "\n\nAufgerufen von der Adresse:\n";
    $message .= $_SERVER["HTTP_REFERER"];
  }

  // Header-Informationen
  $header = "From: Error Agent <erroragent@" . $_SERVER["SERVER_NAME"].">n";
  $header .= "Content-Type: text/plain";

  // Mail zusammenstellen und absenden
  @mail($empfaenger, $betreff, $message, $header);
?>

Das Feld From des E-Mail-Headers erwartet die Angabe der Mailbox des Absenders, also eine E-Mailadresse. Um dennoch einen Individuellen Absendernamen angeben zu können, ist folgende Notation notwendig:

From: Name <E-Mailadresse>

Das @ vor dem Aufruf der Funktion mail() bewirkt, dass Rückmeldungen, insbesondere Fehlermeldungen der Funktion, unterdrückt werden. Somit erhalten Sie auch dann keine störende Fehlermeldung, wenn auf localhost kein Mail-Server vorhanden oder etwas anderes schief gelaufen und PHP so konfiguriert ist, Fehler auf der Webseite auszugeben.

Dieses Skript funktioniert auch für andere Fehlercodes, beispielweise für Fehler der Art 403. In diesem Fall brauchen Sie nur den Wert der Variable $fehlercode zu ändern. Alternativ können Sie für mehrere Fehlerarten das gleiche Fehlerdokument verwenden, indem Sie dem URI bei der ErrorDocument-Direktive einen Parameter mitgeben und diesen der Variable $fehlercode zu Beginn des Skripts mit

$fehlercode = $_GET["errorcode"];

entsprechend zuweisen:

ErrorDocument 403 /error/document?errorcode=403
ErrorDocument 404 /error/document?errorcode=404

410 – Gone

Wenn Sie Ressourcen komplett aus Ihrer Website entfernt haben (natürlich nur, wenn es einen guten Grund gibt), sollten Sie keinen 404er, sondern Fehlercode 410 senden. Im Apache Webserver erreichen Sie dies über die Zeile

Redirect Gone /foo/bar

in der Zugriffskontrolldatei. Dadurch wird unmissverständlich klar, dass es die angeforderte Ressource unter diesem URI zwar mal gegeben hat, sie aber nicht aufgrund eines Versehens oder Fehlers vorübergehend nicht verfügbar ist, sondern bewusst aus dem Netz genommen wurde. Wählen Sie eine Formulierung wie »Das angeforderte Dokument ist nicht mehr verfügbar« oder ähnliches.

Michael Jendryschik
10 Kommentare
  1. Tamer
    Tamer sagte:

    Ich habe diese Anleitungen heute eingebaut und freue mich das ich eine Anleitung gefunden habe die auch auf anhieb funktioniert. Auch wenn der Beitrag noch so Alt ist, von der Aktualität hat sie nicht verloren.
    Dankeschön

    Antworten
  2. Felix Berthold
    Felix Berthold sagte:

    Vielen Dank für diese sehr guten Infos zum Error-Handling.

    Ich hatte bei einer Website, die ich betreue (http://www.presse-schwitzgebel.de), Probleme mit den relativen Pfaden zu den Fehler-Seiten in der .htaccess (z.B. ErrorDocument 404 /404.html), hier bekommt man nämlich Darstellungs-Schwierigkeiten mit fehlerhaften URLs wie http://www.domain.tld/verzeichnis1/verzeichnis2/test-fehler/ , weil die relativen Pfade der internen Links und die Links zu CSS-Files nicht mehr stimmen, wenn die Error-Seite im Wurzelverzeichnis liegt, zumindest wenn man (wie ich) in der Error-Seite im <head/> vergessen hat <base href=“http://www.domain.tld“ /> einzufügen. Seit ich die Zeile ergänzt habe, klappt’s wunderbar.

    Vielleicht ist diese ergänzende Info auch für andere Leute von Interesse. Denn allzuoft werden Fehlerseiten in der .htaccess immer noch absolut referenziert (also z.B. ErrorDocument 404 http://www.domain.tld/404.html, was, wie im Artikel bemerkt, zu einem unerwünschten Redirect führt: also erst eine 303 (Redirect) und dann eine 200 (ok), weil die Fehlerseite stattdessen korrekt ausgeliefert wird. Vom Nichtvorhandensein der Seite merken Suchmaschinen also nichts, weil kein 404 im HTTP-Header ausgeliefert wird. Dieses Verhalten ist aus SEO-Perspektive unerwünscht.

    Ergänzend würde ich noch empfehlen im <head/> der Fehlerseite folgende Zeile zu ergänzen: <meta name=“robots“ content=“noindex,follow“ />, damit Suchmaschinen die Fehler-Seite nicht indexieren, trotzdem aber weiter den Links auf der Seite folgen. Dies kann man zusätzlich auch in der robots.txt vermerken: Disallow: /404.html

    Antworten
  3. Marce Reckel
    Marce Reckel sagte:

    Email wird wunderbar verschickt nur leider bekomme ich anstatt der nicht gefundenen URL die URL von der Fehlerseite zurück… Was zur Optimierung der nicht beiträgt.

    Was habe ich falsch gemacht?

    Antworten
  4. dlogic
    dlogic sagte:

    Sehr nützlich und wird so verwendet 🙂 Wie Felix bereits geschrieben hat, bekommen die Suchmaschinen nicht viel mit von einer fehlenden Seite weil die Fehlerseite so kein 404 Header zurückgibt. Dies kann man jedoch noch am Anfang der Fehlerseite einbauen:

    <?php
    $errorcode = $_GET['errorcode'];
    header('HTTP/1.1 '.$errorcode.'');
    echo "“;
    ?>

    Antworten
    • Felix Berthold
      Felix Berthold sagte:

      @DLOGIC Das geht aber nur, wenn man dynamischen Webspace mit PHP hat. Ansonsten ist die Lösung über einen relativen Pfad zur 404-Fehlerseite in der .htaccess und <base href=“http://www.domain.tld“ /> im Head-Bereich der Fehlerseite sicher ein guter Weg, um den Suchmaschinen einen 404-Fehler (not found) für eine nicht vorhandene Seite/URL zu übermitteln.

      Gruß
      Felix

      Antworten
  5. Kermetderfrosch
    Kermetderfrosch sagte:

    Jetzt habe ich endlich die Zugriffskontrolldatei „verstanden“. Diese lag über viele Jahre auf dem Server herum, natürlich mit einem Standardinhalt. Jetzt im Jahr 2020 habe ich eine 404-Fehlerseite erstellt und diese .htacces-Datei entsprechend angepaßt. Der User steht somit nicht mehr im Regen, sondern weiß ab sofort, was er tun kann. Vielen Dank für diesen Artikel aus dem Jahr 2005…!!!

    Antworten

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlassen Sie mir einen Kommentar!

Ihre Kommentareingaben werden zwecks Anti-Spam-Prüfung an den Dienst Akismet gesendet. Darüber hinaus nutze ich die eingegebene E-Mail-Adresse zum Bezug von Profilbildern bei dem Dienst Gravatar. Weitere Informationen und Hinweise zum Widerrufsrecht finden sich in der Datenschutzerklärung.

Schreibe einen Kommentar zu Felix Berthold Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert