Soft 404: Wenn die Fehlerseite Status 200 zurückmeldet

Warum ein falscher Statuscode länger schadet als ein kurzer Ausfall

Ein Ausfall ist unangenehm, aber ehrlich. Er wird gemessen, er löst einen Alarm aus, er endet. Ein falscher Statuscode ist das Gegenteil: Er bleibt, weil ihn kaum jemand bemerkt. Der Grund liegt in der Rollenteilung des Web. Menschen lesen den sichtbaren Inhalt einer Seite, Maschinen lesen die erste Zeile der Antwort. Solange beide dasselbe aussagen, funktioniert das Zusammenspiel. Sobald die Statuszeile Erfolg meldet und der Inhalt „Seite nicht gefunden“ zeigt, laufen die beiden Welten dauerhaft auseinander - ohne dass ein einziges Warnsignal entsteht.

Die Folgen sind messbar. Suchmaschinen behandeln eine 200-Antwort zunächst als indexierbaren Inhalt. Google beschreibt in seiner Dokumentation genau diesen Fall: eine Seite, die mit Erfolgscode antwortet, deren Inhalt aber leer oder fehlerartig wirkt, wird als Soft 404 eingestuft und verbraucht Crawl-Budget ohne Gegenwert (Google Search Central). Das kostet doppelt - Abrufe fließen in Seiten ohne Nutzen, und echte Inhalte werden seltener geholt. Auf der französischen Domain der eingangs genannten Fallstudie sanken die täglichen Crawl-Anfragen von 60.000 bis 70.000 auf 20.000 bis 30.000, während sich die Soft-404-Meldungen häuften (Search Engine Land).

Auf der Nutzerseite wirkt derselbe Defekt anders, aber nicht harmloser. Wer aus einer Suche auf eine vermeintlich vorhandene Produktseite klickt und dort einen Hinweistext statt eines Angebots findet, springt ab. Im Handel ist die Abbruchbereitschaft ohnehin hoch: Die durchschnittliche Warenkorbabbruchrate liegt bei rund 70 Prozent (Baymard Institute), und jede zusätzliche Sackgasse verschärft sie. Dass solche Sackgassen mit der Zeit zunehmen, ist gut belegt - 38 Prozent der 2013 erreichbaren Webseiten waren zehn Jahre später nicht mehr abrufbar (Pew Research Center). Websites verlieren Seiten; die Frage ist lediglich, mit welchem Code sie das zugeben.

Was der Standard vorschreibt und was Server tatsächlich senden

Die HTTP-Semantik ist an dieser Stelle eindeutig. Die Statusklasse 2xx bedeutet, dass die Anfrage empfangen, verstanden und erfolgreich bearbeitet wurde (RFC 9110). 404 Not Found besagt, dass für die angefragte Adresse keine Repräsentation gefunden wurde, ohne eine Aussage darüber zu treffen, ob dieser Zustand dauerhaft ist. 410 Gone geht einen Schritt weiter: Die Ressource ist dort dauerhaft verschwunden, und der Server weiß das (RFC 9110). Google behandelt beide Codes als Entfernungssignal und empfiehlt sie ausdrücklich für Seiten, die es nicht mehr gibt und für die kein inhaltlich passender Ersatz existiert (Google Search Central).

In der Praxis weicht das Verhalten oft ab - meist nicht aus Nachlässigkeit, sondern weil ein Framework, ein Reverse-Proxy oder ein Auslieferungsnetz eine eigene Fehlerbehandlung mitbringt. Die folgende Übersicht stellt gegenüber, was der jeweilige Zustand verlangt und was Systeme stattdessen senden.

Die letzte Zeile ist bewusst anders gelagert. Eine Suchergebnisseite ohne Treffer ist technisch kein Fehler - die Anfrage wurde korrekt bearbeitet, das Ergebnis ist eben leer. Problematisch wird sie erst, wenn sie indexierbar ist und in großer Zahl entsteht, etwa weil jede Filterkombination eine eigene Adresse erzeugt. Hier ist nicht der Statuscode falsch, sondern die Indexierbarkeit. Die Gegenmaßnahme unterscheidet sich deshalb: keine 404-Antwort, sondern eine bewusste Steuerung über Meta-Angaben und kanonische Adressen - und eine Prüfung, die leere Trefferlisten überhaupt erst sichtbar macht.

Die vier Statuscode-Fehler, die im Betrieb am häufigsten auftreten

Wer die Ursachen kennt, findet die betroffenen Adressen deutlich schneller. Vier Muster erklären erfahrungsgemäß den größten Teil der Befunde.

Warum die Verfügbarkeitsprüfung den Fehler nicht sieht

Ein klassischer Verfügbarkeitscheck stellt genau eine Frage: Kommt innerhalb der Zeitgrenze eine Antwort, und liegt ihr Statuscode unterhalb von 400? Beides ist bei einem Soft 404 erfüllt. Die Prüfung meldet grün, der Uptime-Wert bleibt makellos, und der Bericht an den Kunden weist keine Auffälligkeit aus. Genau das macht diesen Defekt so langlebig: Er überlebt jede Kontrolle, die nur die Statuszeile liest.

Bei Anwendungen, die den Seiteninhalt erst im Browser zusammensetzen, verschärft sich die Lage. Der Server liefert eine Grundseite mit 200, das Skript entscheidet danach, ob ein Produkt existiert, und blendet im Zweifel einen Fehlertext ein. Ein reiner Abruf ohne Ausführung sieht davon nichts - weder den Fehlertext noch die leere Trefferliste. Erst eine Prüfung, die die Seite tatsächlich rendert, bringt den Unterschied zutage. Genau dafür gibt es Browser-basierte Checks, die den sichtbaren Zustand nach dem Rendern bewerten statt nur die rohe Antwort.

Soft 404 über Inhaltssignaturen statt über den Statuscode erkennen

Wenn der Statuscode lügt, braucht die Prüfung eine zweite, unabhängige Quelle. Diese Quelle ist der Inhalt selbst. Eine Inhaltssignatur ist nichts anderes als eine Erwartung an den Antwortkörper: Welche Zeichenketten müssen vorkommen, welche dürfen es nicht, und wie groß darf die Antwort sein. In Verbindung mit dem erwarteten Statuscode entsteht daraus eine Aussage, die sich nicht durch eine falsch gesetzte Kopfzeile aushebeln lässt. Sechs Signale haben sich dabei bewährt:

1. Erwarteter Statuscode je Adresse: Hinterlegen Sie nicht „kleiner als 400“, sondern den konkret erwarteten Code. Eine Bestandsseite erwartet 200, eine bewusst entfernte Adresse erwartet 404 oder 410, eine geschützte Ressource erwartet 401. Jede Abweichung ist ein Befund, auch nach oben.
2. Verbotene Textmuster bei Status 200: Formulierungen wie „nicht gefunden“, „Fehler“, „vorübergehend nicht verfügbar“ oder „keine Ergebnisse“ dürfen in einer Erfolgsantwort nicht auftauchen. Ein Treffer ist der zuverlässigste Hinweis auf einen Soft 404, weil er unabhängig vom Kopf der Antwort funktioniert.
3. Erwartete Textmuster als Positivprobe: Umgekehrt sollte eine Produktseite einen Preis, eine Artikelnummer oder einen Bestellknopf enthalten. Fehlt dieses Merkmal bei Status 200, ist die Seite inhaltlich leer, auch wenn sie technisch antwortet.
4. Sprung in der Antwortlänge: Fehlerseiten sind fast durchgängig kürzer als echte Inhalte. Ein plötzlicher Rückgang der Antwortgröße über viele Adressen hinweg deutet auf eine zentral ausgelieferte Ersatzseite hin - ein Muster, das eine einzelne Stichprobe kaum zeigt.
5. Gerenderte Prüfung im Browser: Für Anwendungen mit clientseitigem Aufbau muss die Seite ausgeführt werden, bevor die Signatur greift. Der Browser-Check bewertet den Zustand, den ein Besucher tatsächlich sieht, samt nachgeladener Inhalte.
6. Gegenprobe mit einer erfundenen Adresse: Rufen Sie regelmäßig einen Pfad ab, den es sicher nicht gibt, etwa /diesen-pfad-gibt-es-nicht. Antwortet er mit 200, ist die Fehlerbehandlung der gesamten Website falsch konfiguriert - unabhängig davon, wie viele echte Adressen gerade sauber sind.

Die Gegenprobe aus dem letzten Punkt ist der schnellste Einzeltest überhaupt und lohnt sich vor jeder größeren Umstellung. Sie deckt auch einen benachbarten Fall auf, der ähnlich unauffällig verläuft: Seiten, die zwar korrekt antworten, aber alten Inhalt ausliefern. Warum das nach einer Veröffentlichung besonders häufig passiert, beschreibt der Beitrag zu Cache-Fallen nach dem Deploy und veralteten Inhalten.

Wartung, Drosselung und Rechtssperren korrekt auszeichnen

Nicht jeder Sonderzustand ist ein Fehler, aber jeder Sonderzustand hat einen passenden Code. Für geplante Arbeiten ist das 503 Service Unavailable: Der Dienst existiert, ist aber vorübergehend nicht erreichbar. Entscheidend ist der begleitende Retry-After-Header, der entweder eine Sekundenzahl oder einen konkreten Zeitpunkt nennt (RFC 9110). Google nennt dafür eine klare Obergrenze: Als kurzfristige Drosselung sind 503 oder 429 für ein bis zwei Tage vorgesehen; sieht der Crawler diese Codes über mehrere Tage auf derselben Adresse, kann sie aus dem Index fallen (Google Search Central). Eine Wartungsseite mit Erfolgscode dagegen wird als regulärer Inhalt behandelt - im ungünstigen Fall landet der Satz „Wir sind gleich zurück“ als Beschreibung im Suchergebnis. Wie sich geplante Arbeiten sauber vom echten Vorfall trennen lassen, behandelt der Beitrag zu Wartungsfenstern und Fehlalarmen im Monitoring.

Für Drosselung gilt Vergleichbares. 429 Too Many Requests sagt aus, dass der Client sein Kontingent erschöpft hat und es später erneut versuchen soll (RFC 6585); auch hier gehört ein Retry-After dazu. Wer stattdessen mit 403 antwortet, behauptet fehlende Berechtigung, und wer mit 200 antwortet, behauptet Erfolg - beides führt den Client in die Irre. Ein Sonderfall ist 451 Unavailable For Legal Reasons: Der Code kennzeichnet Inhalte, die aus rechtlichen Gründen nicht ausgeliefert werden dürfen, und wurde eigens dafür standardisiert (RFC 7725). Er ersetzt keine juristische Bewertung, macht die Sperre aber nachvollziehbar, statt sie hinter einer 404 zu verstecken. Bleiben 5xx- oder 429-Antworten über längere Zeit bestehen, können betroffene Adressen aus dem Index verschwinden (Google Search Central) - der temporäre Code darf also nicht zum Dauerzustand werden.

Statuscode-Drift nach dem Deploy früh bemerken

Falsche Statuscodes entstehen selten am ersten Tag. Sie entstehen bei einer Veröffentlichung, die eine Routing-Regel ändert, bei einer neuen Umschreibungsregel im Webserver, bei einer Regel im Auslieferungsnetz oder beim Wechsel des Frameworks. Gestern hat /produkte/artikel-4711 noch mit 404 geantwortet, heute mit 200 und einer generischen Seite. Genau dieser Übergang heißt Statuscode-Drift, und er ist gut messbar - vorausgesetzt, jemand vergleicht die Antwort mit dem Zustand davor. Die Grafik weiter oben zeigt genau diesen Verlauf: vier Prüfungen mit korrektem 404, dann eine Veröffentlichung, danach 200.

Die Tabelle macht deutlich, dass keine einzelne Prüfart genügt. Erst die Kombination aus erwartetem Code, Inhaltssignatur und gerendertem Zustand deckt das Feld ab. Ergänzend hilft ein Blick auf die Darstellung: Ein visueller Vergleich der Seitenstände zeigt, wenn aus einer gestalteten Fehlerseite plötzlich eine leere Fläche wird. Und weil nicht jede Störung über HTTP sichtbar wird, gehört die Erreichbarkeit der darunterliegenden Dienste ebenfalls dazu - der Beitrag zur Portüberwachung von Diensten jenseits der Webseite beschreibt, wie sich diese Ebene absichern lässt.

Ein Prüfplan für korrekte Statuscodes

Aus den vorangegangenen Punkten wird ein Ablauf, der sich in einem Vormittag einrichten lässt und danach ohne weiteren Aufwand läuft.

• Bestandsaufnahme: Rufen Sie eine erfundene Adresse, eine bewusst entfernte Adresse und eine echte Bestandsseite ab und notieren Sie die tatsächlichen Statuscodes. Drei Abrufe zeigen bereits, ob die Fehlerbehandlung grundsätzlich stimmt.
• Erwartungen festschreiben: Legen Sie je überwachter Adresse den erwarteten Code fest, statt pauschal alles unterhalb von 400 zu akzeptieren.
• Verbotene Muster hinterlegen: Definieren Sie eine kurze Liste von Fehlerformulierungen, die in einer 200-Antwort nicht vorkommen dürfen - abgestimmt auf die eigene Oberfläche und deren Wortwahl.
• Positivprobe ergänzen: Hinterlegen Sie für die wichtigsten Vorlagen ein Merkmal, das vorhanden sein muss, etwa die Artikelnummer auf Produktseiten oder das Absendefeld im Formular.
• Wartungsantwort prüfen: Testen Sie im nächsten geplanten Fenster, ob tatsächlich 503 mit Retry-After ausgeliefert wird - und nicht 200 mit einem Hinweistext.
• Gerenderte Prüfung für dynamische Seiten: Richten Sie für Bereiche mit clientseitigem Aufbau einen Browser-Check ein, der den sichtbaren Endzustand bewertet.
• Änderungen protokollieren: Halten Sie über Bildschirmfotos und ein automatisches Änderungsprotokoll fest, wie Fehler- und Wartungsseiten zu jedem Zeitpunkt aussahen - das verkürzt die Ursachensuche nach einer Veröffentlichung erheblich.
• Alarm auf Abweichung, nicht auf Ausfall: Konfigurieren Sie die Benachrichtigungen so, dass bereits eine Statuscode-Abweichung meldet - nicht erst der vollständige Ausfall.

Ein Hinweis zur Auswertung in den Werkzeugen der Suchmaschinen: Die dortigen Soft-404-Berichte sind eine nützliche Ergänzung, aber kein Ersatz für eigene Prüfungen. Ihre Meldegenauigkeit wurde zwischenzeitlich überarbeitet, weshalb ältere Zahlen nicht direkt mit neueren vergleichbar sind (Google Search Central); zudem wird die Einstufung an der mobilen Fassung einer Seite vorgenommen (Google / John Mueller). Vor allem aber melden diese Berichte erst nach dem Crawl - eine eigene Prüfung meldet innerhalb von Minuten.

Statuscodes mit XICTRAQ verlässlich prüfen

Ein Soft 404 ist kein exotischer Randfall, sondern die vorhersehbare Folge einer Prüfung, die nur eine Zeile der Antwort liest. Sobald die Erwartung an den Statuscode ausformuliert und um eine Aussage über den Inhalt ergänzt wird, verschwindet der blinde Fleck - und aus einem unsichtbaren Dauerzustand wird ein Befund mit Zeitstempel.

Genau darauf ist das Verfügbarkeits-Monitoring von XICTRAQ ausgelegt: Jede Prüfung kann auf einen erwarteten Statuscode festgelegt werden, ergänzt um erwartete und verbotene Textmuster im Antwortkörper. Für Anwendungen, die erst im Browser fertig werden, bewerten gerenderte Checks den sichtbaren Endzustand. Für Schnittstellen übernimmt das API-Monitoring dieselbe Logik auf Feldebene, sodass eine Antwort mit Status 200 und leerem Ergebnisobjekt ebenfalls auffällt. Visueller Vergleich und Änderungsprotokoll halten fest, wann sich das Verhalten geändert hat, und die Alarmierung greift bereits bei der Abweichung.

Prüfen Sie im kostenlosen Test, welchen Statuscode Ihre Fehlerseite heute wirklich sendet - der Abruf einer erfundenen Adresse dauert wenige Sekunden. Wer die Einrichtung von Inhalts-Assertions und gerenderten Checks lieber gemeinsam durchgehen möchte, vereinbart eine persönliche Demo.