mBaumer

Ich möchte behaupten, fast jeder, der das Internet kennt, weiß, wofür „404“ steht. Meist noch mit Zusatz „Not Found“ oder „Seite nicht gefunden“. Ein Link ist entweder veraltet, es hat sich jemand vertippt, es gibt bei der Serverkonfiguration Probleme, etc. Wer seine Website nur mit einfachen statischen Dateien aufbaut, braucht sich um das Problem nicht zu kümmern, denn der Webserver liefert automatisch eine solche 404-Fehlermeldung, falls eine Datei angefordert wird, die nicht gefunden wird.

Sobald es aber in den dynamischen Bereich geht, muss sich der Website-Betreiber evtl. selbst um die korrekte Fehlerbehandlung kümmern…

Und hier greift manchmal Unwissenheit, der Glaube an falsche Vorraussetzungen, Programmierfehler oder das sich-auf-die-Fremdsoftware-verlassen.

Lesbare URLs

Insbesondere im Bereich Blog- und Content-Management-Systeme, werden Daten typischerweise aus Datenbanken geladen und dynamisch ausgegeben. Meist möchte man dem Besucher eine möglichst einfache „sprechende URL“ anbieten und aus SEO-Gründen (o. ä.) auf eine URL mit Parametern verzichten (z. B. index.php?p=123). Der Apache liefert hierfür z. B. ein einfaches Modul „mod_rewrite“, mit dem sich solche URLs leicht bewerkstelligen lassen. Aus

http://meine-domain.xy/index.php?verzeichnis=abc&datei=123

wird somit einfach

http://meine-domain.xy/abc/123.html

Die Möglichkeiten hierzu sind sehr vielfältig, doch in den meisten Fällen wird dafür gesorgt, dass egal welche URL aufgerufen wird, die Daten direkt an ein Skript weitergeleitet werden, somit die normale 404-Fehler-Behandlung des Servers umgangen wird. Da die Datei (im o. g. Beispiel index.php) in jedem Fall existiert, sich nur die Parameter ändern, liefert der Server standardmäßig den Statuscode „200 OK“. Der Programmierer muss also dafür sorgen, dass – sofern die angefragten Parameter keinem Eintrag in der Datenbank zuzuordnen sind – eine 404-Meldung ausgegeben wird, beispielsweise so:

header("HTTP/1.0 404 Not Found");

Umgehung von 404

Ich kann mir vorstellen, dass so mancher Programmierer denkt „ich möchte aber nicht, dass der Benutzer eine hässliche 404-Fehlermeldung erhält, die womöglich noch im Internet Explorer durch eine hässliche Standardmeldung ersetzt wird“. Somit wird bei nicht gefundenen Artikeln, Produkten, etc. eine hübsche Übersichtsseite gebastelt oder die Startseite ausgeliefert. Es spricht ja nichts gegen eine besondere Fehlermeldung, die dem Benutzer im Design der Seite auf den Fehler aufmerksam macht und ihm eine Hand voll Links präsentiert, auf die ausgewichen werden kann. Es sollte jedoch nicht vergessen werden, den 404-Header mitzuschicken. Sobald die Seite größer als 512 Byte groß ist, zeigt der Internet Explorer auch keine eigene Standardseite an. Somit gibt es für die Suchmaschine einen 404-Fehler, der Benutzer sieht jedoch eine für einen Menschen angepasste Seite.

Natürlich gibt es auch noch andere Fälle, sei es, dass der Website-Betreiber hofft, so ein wenig zu spammen „Wenn ich keine 404-Fehler liefere, habe ich mehr Seiten“ oder einfach nicht dran gedacht wird. Wenn ich jetzt beispielsweise die URL (sorry Martin, dass deine Site herhalten muss ) http://labuschin.com/nudelsalat¹ verlinke, so entspricht die Zielseite optisch der Startseite und auch der Statuscode gibt an, dass hier eine Seite gefunden wird: 200 OK. Wenn jetzt nur ausreichend Links auf diese Seite verweisen würden, bekäme diese eine entsprechende Relevanz und dürfte in den Suchergebnissen auftauchen.

Ein anderes Problem ist zum Beispiel die Software ExpressionEngine, die durch das System der Templates nur bedingt 404-Fehlermeldungen unterstüzt. Somit liefert auch der folgende Link eine gültige „200 OK“-Seite: http://www.bartelme.at/journal/archive/nudelsalat¹. Besonders gut hierbei gefällt mir vor allem der Text (den Umbruch habe ich eingefügt):

0033000000000470000450063000000003900000920005200052000039000
12500000000028000261600000000005100190002600000003600160110 comments so far

Ich benutze selber ExpressionEngine für diese Website und habe mir in den Templates einen abgebrochen, damit hier eine einigermaßen brauchbare 404-Verwaltung existiert (auch wenn die Templates darunter leiden mussten ).

Und die Suchmaschinen? …

Dies alles hat die Suchmaschinenbetreiber wohl dazu gebracht, bewusst 404-Fehler zu provozieren, um zu testen, wie ein Server mit nicht existenten Dateien umgeht.

Google Webmaster Tools

Jeder der sich für die Webmaster-Tools bei Google angemeldet hat und als Autorisierungsmethode eine Kontrolldatei (z. B. „google0123456789abcdef.html“) wählt, findet in seiner Websitestatistik auch einen Zugriff auf eine weitere Datei („noexist_0123456789abcdef.html“). Hier wird überprüft, ob diese Datei einen korrekten 404-Fehler liefert. Sollte dies nicht der Fall sein, scheidet diese Autorisierungsmethode aus. Ansonsten könnte jeder Websites als die eigenen bei Google ausweisen, die konsequent den Statuscode 200 ausliefern.

Yahoo Slurp

Yahoo hingegen fragt nicht nur gezielt Server für die Autorisierung spezieller Tools ab, sondern möchte generell wissen, wie sich ein Webserver verhält. Die abgefragten Dateien können dann z. B. „/SlurpConfirm404/lagana/cwi/blackbutterflypress.htm“ lauten, eine zufällig zusammengewürfelte URI. Laut der Yahoo.de-Hilfe werden die „Antworten des Webservers“ gespeichert, „um veraltete URLs korrekt erkennen“ zu können.

Diese Überprüfung von 404 Meldungen ist kein Bestandteil der routinemäßigen Aktualisierungen durch den Slurp. Daher sind solche Anfragen sehr selten.

Fußnote

¹) Ich habe – auch, wenn ich es ansonsten auf meiner Website vermeide, da ich nichts von dem Attribut halte – für diese Links ein rel="nofollow" gesetzt, denn diese Seiten sollten ja eigentlich gar nicht existieren.