Was ein 404-Fehler bedeutet, und warum die gefährlichen unsichtbar sind

Ein 404 ist der eine Fehler auf dieser Liste, der meistens korrekt funktioniert. Der Server hat die Anfrage einwandfrei verstanden, nach dem Gesuchten gesucht, und dort war nichts. Nichts ist abgestürzt und nichts ist falsch konfiguriert. Sie haben nach etwas gefragt, das es nicht gibt, und er hat das gesagt.

Deshalb lohnt ein 404 in der Adresszeile selten die Verfolgung. Der Link war alt, die Seite ist umgezogen, jemand hat sich vertippt. Es ist der langweiligste Fehlschlag im Web.

Die interessanten erreichen die Adresszeile nie.

Der 404, den Sie sehen, gegen den, den Sie nicht sehen

Wenn Sie eine Adresse eintippen und einen 404 bekommen, zeigt der Browser Ihnen eine Seite und die Geschichte ist zu Ende. Sie wissen genau, was passiert ist.

Wenn die Seite, auf der Sie bereits sind, im Hintergrund etwas anfordert und einen 404 bekommt, sagt Ihnen nichts etwas. Ein Stylesheet, das nicht ankommt, lässt das Layout kaputt aussehen, aber gerendert. Ein Skript mit 404 bedeutet, dass eine Funktion still gar nichts tut. Ein fetch nach Daten liefert einen 404-Body zurück, den der Code als JSON zu parsen versucht, und was an die Oberfläche kommt, ist ein TypeError, mehrere Schritte vom eigentlichen Problem entfernt.

Das ist die Version, die den Bericht erzeugt, den jeder Entwickler kennt: “die Seite sieht komisch aus”, oder “der Knopf tut nichts”. Keine Fehlermeldung, weil es keine Fehlerseite gab. Der Fehlschlag passierte im Netzwerkprotokoll, und niemand hat ins Netzwerkprotokoll geschaut.

Zweihundert Anfragen können eine moderne Seite ergeben. Jede einzelne kann einen 404 bekommen, ohne die anderen einhundertneunundneunzig aufzuhalten.

Warum ein Hintergrund-404 meist ein Deploy bedeutet

Ein 404 in der Adresszeile ist jemandes Link. Ein 404 auf ein Asset, das die Seite selbst angefordert hat, ist fast immer der Build.

Eine umbenannte oder mit Fingerabdruck versehene Datei. Asset-Pipelines setzen einen Inhaltshash in den Dateinamen. Wenn das HTML zwischengespeichert ist und auf den alten Hash zeigt, während der neue Deploy einen neuen ausgeliefert hat, fragt der Browser nach einer Datei, die es wirklich nicht mehr gibt. Das klärt sich für die meisten beim Neuladen und bleibt für jeden, der eine zwischengespeicherte Seite hält, weshalb es so oft von einer Person gemeldet und von allen anderen nicht reproduziert wird.

Eine Datei, die nie hochgeladen wurde. Ein Build-Schritt, der still fehlschlug, ein von einer Konfigurationsänderung ausgeschlossenes Asset, ein Pfad, der lokal wegen Groß-und-Kleinschreibung-ignorierender Dateisysteme funktioniert und auf einem Linux-Server scheitert, weil Logo.svg nicht logo.svg ist.

Eine API-Route, die umgezogen ist. Frontend und Backend sind leicht zeitversetzt ausgeliefert worden, und für ein paar Minuten fragt das eine nach einem Endpunkt, den das andere bereits umbenannt hat.

Alle drei sind von der Seite aus unsichtbar. Alle drei sind eine Zeile in einem Netzwerkprotokoll.

Soft 404, die schlimmer sind als 404

Ein Soft 404 ist eine Seite, die einem Menschen sagt, sie habe nichts gefunden, während sie jeder Maschine sagt, alles sei in Ordnung: ein freundliches “tut uns leid, hier ist nichts”, ausgeliefert mit einem 200 OK.

Diese Kombination ist auf eine Weise schädlich, wie es ein echter 404 nicht ist. Suchmaschinen indexieren sie als funktionierende Seite, also bleibt der fehlende Inhalt in den Ergebnissen. Monitoring schlägt nie an, weil Monitoring Statuscodes zählt. Und jeder Code, der response.ok prüft, bevor er parst, nimmt die Fehlerseite als Daten und scheitert irgendwo weiter hinten, mit einer Meldung über die Form des JSON statt darüber, dass die Seite fehlt.

Wenn Sie eines von dieser Seite mitnehmen: eine Fehlerseite muss einen Fehlerstatus zurückgeben. Eine Meldung, die ein Mensch lesen kann, und ein wahrheitsgemäßer Statuscode sind keine Alternativen zueinander.

404 gegen die Codes, mit denen er verwechselt wird

404 Not Found

Die Anfrage war in Ordnung und unter dieser Adresse ist nichts. Sagt nichts darüber, ob dort je etwas war

410 Gone

Hier war etwas und es ist absichtlich und dauerhaft entfernt. Suchmaschinen lassen es schneller fallen

403 Forbidden

Es existiert und Sie dürfen es nicht. Manche Seiten geben absichtlich stattdessen 404 zurück, damit niemand durch Ausprobieren kartieren kann, was existiert

400 Bad Request

Der Server konnte die Anfrage gar nicht parsen, kam also nie zum Nachschauen

Diese dritte Zeile ist wissenswert, wenn Sie eine fremde API debuggen: ein 404 auf eine Ressource, von der Sie ziemlich sicher sind, dass es sie gibt, kann ein verkleideter 403 sein, der die Existenz der Sache vor einem nicht autorisierten Aufrufer verbirgt. Prüfen Sie, ob Sie authentifiziert sind, bevor Sie annehmen, der Datensatz sei weg.

Wenn es Ihre Website ist

Den 404 vor Ihnen zu beheben ist die leichte Hälfte. Die nützliche Arbeit ist, die zu finden, die niemand meldet.

Das Zugriffsprotokoll des Servers hat jeden einzelnen davon mit der URL und dem Referrer, und der Referrer ist der Teil, den Leute überspringen. Er sagt Ihnen, welche Ihrer eigenen Seiten auf etwas Fehlendes verlinkt, was aus einer Liste von 404ern eine Liste von Fehlern macht. Die Search Console tut dasselbe für alles, was von außen erreichbar ist.

Dann entscheiden Sie, was jeder davon sein soll. Eine umgezogene Seite will eine Weiterleitung auf das, was sie ersetzt hat, nicht auf die Startseite, was Suchmaschinen als Soft 404 behandeln und Leser als Ignoriertwerden erleben. Etwas wirklich Gelöschtes will einen 410. Ein Tippfehler, auf den niemand verlinkt, will gar nichts: 404er sind normal, und eine Website ohne welche ist eine Website, die Dinge weiterleitet, die sie nicht weiterleiten sollte.

Warum die unsichtbaren schwer zu melden sind

Ein Hintergrund-404 lässt die Person, die ihn sieht, ohne etwas zu beschreiben zurück. Sie hat eine Seite, die falsch aussieht, keine Fehlermeldung, und keinen Grund zu denken, dass eine Datei nicht geladen wurde. Also lautet die Meldung “sieht bei mir kaputt aus”, und der Entwickler öffnet die Seite, sieht sie funktionieren, und schließt das Ticket.

Das Netzwerkprotokoll ist hier der ganze Unterschied. Ein 404 auf eine Anfrage, die die Seite gemacht hat, ist auf dem Bildschirm unsichtbar und im Protokoll offensichtlich, also verwandelt ein Bericht, der das Protokoll mitbringt, “sieht komisch aus” in einen Dateinamen und eine Zeilennummer. Das ist meist die ganze Untersuchung.

In einem Absatz

Ein 404 bedeutet, dass der Server Sie verstanden hat und unter dieser Adresse nichts hat, was ihn zu dem einen Fehler macht, der sich meist korrekt verhält. Die in der Adresszeile sind jemandes alter Link und spielen selten eine Rolle. Die, die eine Rolle spielen, sind die Anfragen, die eine Seite im Hintergrund macht, wo ein fehlendes Stylesheet, Skript oder eine fehlende API-Route eine Seite erzeugt, die falsch aussieht und überhaupt keine Fehlermeldung hat, und fast immer auf einen Deploy zurückgeht: ein Dateiname mit Fingerabdruck, eine Datei, die nie hochgeladen wurde, oder eine umgezogene Route. Liefern Sie echte 404er mit einem 404-Status aus statt mit einem freundlichen 200, denn ein Soft 404 täuscht Suchmaschinen und Monitoring gleichzeitig. Und wenn Sie einem nachgehen, ist der Referrer in Ihrem Zugriffsprotokoll das, was aus einer Liste fehlender URLs eine Liste von Seiten macht, die darauf verlinken.