SEO

Soft 404s für kleine Websites - Status und Seiteninhalt in Einklang bringen

Geschrieben von Adam Muiz 04 Nov 2026 Aktualisiert: 04 Nov 2026 9 Min. gelesen

Ein Besucher ruft eine URL auf, die nie existiert hat. Die Seite sagt deutlich „nicht gefunden“, bietet ein Suchfeld und verweist auf hilfreiche Bereiche. In der Statuszeile steht jedoch 200 OK. Für einen Menschen sieht die Seite wie eine Fehlerseite aus. Für einen HTTP-Client war die Anfrage erfolgreich. Welcher Aussage sollte man vertrauen?

Diese Diskrepanz wird in der Dokumentation von Google Search häufig als Soft 404 bezeichnet. Dabei handelt es sich weder um einen verborgenen HTTP-Statuscode noch um einen Beweis für eine Abstrafung der Website. Es ist eine Diagnose: Der zurückgegebene Inhalt scheint eine fehlende Ressource zu beschreiben, während die Protokollantwort nicht eindeutig mitteilt, dass die Ressource fehlt.

Bei einem kleinen CMS geht es bei der Korrektur meist weniger darum, „SEO zu betreiben“, sondern darum, die Realität konsistent wiederzugeben. Route, Statuscode, sichtbare Seite, Weiterleitung, Sitemap und interne Links sollten dasselbe Ergebnis beschreiben. Das hilft Browsern, Crawlern, Monitoring-Werkzeugen, Caches und Menschen, die Antwort zu verstehen.

Ein Soft 404 ist eine Klassifizierung, keine Protokollfunktion

HTTP besitzt bereits einen Status für eine Ressource, die nicht gefunden werden kann: 404 Not Found. RFC 9110 definiert 404, ohne festzulegen, ob das Fehlen vorübergehend oder dauerhaft ist. Wenn der Server weiß, dass der Zugriff nicht mehr verfügbar und dieser Zustand wahrscheinlich dauerhaft ist, sieht die Spezifikation 410 Gone vor.

„Soft 404“ gehört zu einer anderen Ebene. Google dokumentiert, dass eine erfolgreiche 2xx-Antwort als Soft 404 gemeldet werden kann, wenn ihr Inhalt wie ein Fehler wirkt, leer ist oder anderweitig vermuten lässt, dass keine brauchbare Seite vorhanden ist. Die genaue Klassifizierung ist Googles Bewertung der Antwort; ein anderer Crawler kann andere Begriffe oder Heuristiken verwenden.

Diese Unterscheidung verhindert zwei häufige Missverständnisse. Erstens gibt es keinen hinzuzufügenden soft-404-Header. Zweitens erzwingt eine 200-Antwort nicht die Aufnahme einer Seite in einen Suchindex. Google erklärt ausdrücklich, dass eine 2xx-Antwort die Verarbeitung des Inhalts ermöglicht, aber keine Indexierung garantiert. Ein Erfolgsstatus ist eine Aussage über die HTTP-Anfrage, kein Antrag auf ein Ranking.

Die Antwort nach dem tatsächlichen Vorgang auswählen

Ein Status sollte dem tatsächlichen Zustand der Ressource folgen und nicht der Option, die in einem Dashboard am vorteilhaftesten erscheint. Eine kleine Entscheidungstabelle reicht oft aus:

Zur URL gibt es keine passende Ressource: 404 zurückgeben und eine hilfreiche Not-found-Seite rendern.
Die Ressource wurde absichtlich entfernt und wird wahrscheinlich nicht zurückkehren: 410 kann diese stärkere Tatsache ausdrücken. Wenn die Historie unklar ist, bleibt 404 die ehrliche Wahl.
Die Ressource wurde verschoben und besitzt einen echten Ersatz: auf diesen Ersatz weiterleiten. Eine permanente Weiterleitung nur verwenden, wenn die Verschiebung dauerhaft sein soll.
Die Ressource existiert noch, aber der Server kann sie wegen eines vorübergehenden Fehlers nicht bereitstellen: eine passende 5xx-Antwort verwenden. Einen Ausfall als „nicht gefunden“ zu bezeichnen, verbirgt ein Betriebsproblem.
Die Ressource existiert und wird durch die Antwort repräsentiert: Ein 2xx-Status ist angemessen, auch wenn die Seite nur wenig Text enthält.

Der Unterschied zwischen 404 und 410 ist ein bedeutungsvoller Teil des HTTP-Vokabulars, sollte aber nicht zu einem Trick für eine schnellere Deindexierung gemacht werden. Googles aktuelle Crawler-Dokumentation sagt, dass gewöhnliche 4xx-Antworten außer 429 in der Indexierungspipeline gleich behandelt werden. 410 sollte gewählt werden, weil eine dauerhafte Entfernung bekannt ist, nicht weil davon ein bestimmter Zeitplan erwartet wird.

Eine hilfreiche Fehlerseite kann weiterhin ein echter Fehler sein

Body und Status beantworten unterschiedliche Fragen. Der Status teilt Software mit, was geschehen ist. Das HTML hilft einem Menschen bei der Entscheidung, was als Nächstes zu tun ist. Eine echte 404-Antwort kann weiterhin die übliche Seitennavigation verwenden, das Problem verständlich erklären, eine Suche anbieten und relevante Bereiche vorschlagen.

Umgekehrt macht eine umfangreiche, sorgfältig gestaltete Seite den Status 200 nicht korrekt. Ein CMS erzeugt häufig Soft 404s, wenn sein Front Controller zunächst das Seitenlayout lädt, den angeforderten Datensatz nicht findet, ein Fehler-Template rendert und den standardmäßigen PHP-Erfolgsstatus nie ändert. Im Browser wirkt das Ergebnis beabsichtigt, weil Browser sowohl bei 404 als auch bei 200 den Response Body darstellen.

Jede unbekannte URL auf die Startseite umzuleiten, erzeugt eine andere Diskrepanz. Die Startseite ist selten ein Ersatz für /articles/a-title-that-does-not-exist. Der Besucher verliert den Kontext der fehlerhaften URL, und automatisierte Clients sehen, wie viele nicht zusammengehörige Adressen auf ein Ziel zusammenfallen. Googles Leitfaden zu Weiterleitungen behandelt Redirects im Zusammenhang mit Inhalten, die tatsächlich verschoben wurden oder einen neuen Ort besitzen. Eine Weiterleitung sollte eine Karte zu einem relevanten Nachfolger sein und kein Mittel, um zu vermeiden, das Fehlen eines Nachfolgers einzugestehen.

Den Status festlegen, sobald das Routenergebnis bekannt ist

In einer nativen PHP-Anwendung sollte der Controller feststellen, dass die Ressource fehlt, bevor er die gemeinsame Fehleransicht rendert. Das PHP-Handbuch dokumentiert http_response_code() zum Lesen oder Setzen des Antwortstatus und weist darauf hin, dass in einer Webserver-Umgebung standardmäßig 200 gilt, wenn kein Code gesetzt wurde.

$post = findPublishedPostBySlug($slug);

if ($post === null) {
    http_response_code(404);
    require __DIR__ . '/views/errors/404.php';
    exit;
}

renderPost($post);

exit ist wichtig, weil die Anwendung nach dem Rendern des Fehlers nicht mit einem Erfolgs-Template fortfahren sollte. Der Status muss außerdem gesetzt werden, bevor die Ausgabe die Response Header festschreibt. Frameworks können für denselben Zweck ein Response-Objekt oder eine Exception bereitstellen; das Prinzip ist wichtiger als diese konkrete PHP-Form.

Routenfamilien sollten getrennt getestet werden. Ein CMS kann einen unbekannten englischen Slug korrekt ablehnen, während sein Fallback für /id/ oder /de/ stillschweigend eine übersetzte Startseite mit 200 zurückgibt. Kategorieseiten, Autorenarchive, Seitenzahlen hinter der letzten Seite, gelöschte Medien und fehlerhafte Kennungen können jeweils andere Controller-Pfade nehmen. Ein korrektes globales 404-Template beweist nicht, dass jede fehlende Route dort ankommt.

Den Status durch Nginx hindurch bewahren

Ein Webserver kann einen Fehler-Body ersetzen, ohne den ursprünglichen Status zu ändern. Die offizielle Nginx-Dokumentation zu error_page zeigt das grundlegende Muster:

error_page 404 /404.html;

location = /404.html {
    internal;
}

Dieses interne Fehlerdokument kann eine einheitliche Seite bereitstellen, während der Client weiterhin 404 erhält. Nginx unterstützt auch eine ausdrückliche Ersetzung des Status. So macht error_page 404 =200 /empty.gif; aus der Antwort absichtlich eine 200-Antwort. Diese Möglichkeit hat legitime Spezialanwendungen, erzeugt bei fehlenden HTML-Seiten jedoch genau die hier behandelte semantische Diskrepanz.

Anwendungen hinter FastCGI oder einem Reverse Proxy benötigen eine End-to-End-Prüfung. PHP kann einen Status wählen, den ein Proxy, eine Cache-Regel, ein eigener Fehlerhandler oder ein Anwendungs-Fallback später ersetzt. Allein durch das Lesen des Template-Codes lässt sich die endgültige Antwort für einen Client nicht erkennen.

Clientseitiges Routing hat eine schwierigere Grenze

Eine Single-Page Application kann ihr HTML-Grundgerüst mit 200 erhalten, bevor JavaScript feststellt, dass das angeforderte Objekt nicht existiert. Eine Textänderung im Dokument schreibt den Status der bereits abgeschlossenen Netzwerkantwort nicht um. Deshalb kann eine clientseitig gerenderte „nicht gefunden“-Ansicht ein Soft 404 bleiben.

Googles Leitfaden zur Behebung von JavaScript-Problemen beschreibt die Weiterleitung zu einer URL, die 404 zurückgibt, oder das Hinzufügen von noindex, wenn eine SPA fehlende Inhalte erkennt. Bei einer öffentlichen Content-Website ist es gewöhnlich klarer, bekannte Routen auf dem Server aufzulösen und bereits in der ersten Antwort den richtigen Status zu senden. Eine noindex-Anweisung kann die Indexierung beeinflussen, macht aber aus einer erfolgreichen HTTP-Antwort keine 404-Antwort und sollte nicht als gleichwertige Protokollsemantik dargestellt werden.

Das Unbekannte testen, nicht nur die gestaltete Seite

Das Öffnen von /404 im Browser testet möglicherweise nur eine Demonstrationsroute. Eine stärkere Prüfung ruft einen zufälligen Pfad auf, der nicht absichtlich konfiguriert worden sein kann:

curl -sS -o /dev/null -w '%{http_code}\n' \
  https://example.com/definitely-missing-7f3a9c/

curl -sS -I https://example.com/definitely-missing-7f3a9c/

Der erste Befehl zeigt den endgültigen Status nach Weiterleitungen. Mit dem zweiten lassen sich die Response Header leicht prüfen. Ein robuster Test sollte jedoch zusätzlich einen normalen GET ausführen, weil manche Anwendungen HEAD anders behandeln. Ein neues zufälliges Suffix verhindert, dass nur eine zwischengespeicherte oder speziell behandelte URL getestet wird.

Ein praktisches Audit nimmt Stichproben verschiedener Ergebnisse, statt einer perfekten Anzahl nachzujagen:

Unbekannte Artikel-, Kategorie-, Autoren-, Sprach-, Paginierungs- und Asset-URLs aufrufen.
Prüfen, ob jede fehlende Route 404 oder eine bewusst begründete Alternative zurückgibt.
Sicherstellen, dass der gerenderte Body den Fehler weiterhin erklärt und hilfreiche Navigation anbietet.
Eine verschobene Seite testen und prüfen, ob ihre Weiterleitung beim konkreten Ersatz endet und nicht bei einer allgemeinen Startseite.
Veraltete interne Links und Sitemap-Einträge entfernen; eine korrekte 404-Antwort macht einen defekten internen Link nicht wünschenswert.
Sowohl über den öffentlichen Proxy oder das CDN als auch direkt am Origin testen, weil jede Schicht eine Antwort verändern kann.

Für Google-spezifische Berichte empfiehlt Search Console, Beispiele zu untersuchen und die Live-URL-Prüfung zu verwenden. Der Bericht ist ein diagnostischer Hinweis und kein Punktestand, der null erreichen muss. Zufällige Tippfehler oder extern verlinkte URLs dürfen berechtigterweise 404 zurückgeben. Entscheidend ist, ob eine wichtige vorhandene Seite falsch klassifiziert wurde oder ob das Routing der Website eine Erfolgsantwort für Ressourcen liefert, die sie nicht besitzt.

Status und Seite sollten dieselbe Geschichte erzählen

Ein Soft 404 ist meist das Symptom einer unklaren Grenze: Die Anwendung weiß, dass kein Datensatz existiert, aber dieses Wissen erreicht die HTTP-Antwort nicht. Die dauerhafte Korrektur besteht darin, die Entscheidung ausdrücklich zu machen. Für eine unbekannte Ressource gilt 404, 410 nur für eine bekannte dauerhafte Entfernung, eine Weiterleitung für einen echten Nachfolger und 5xx, wenn ein bestehender Dienst ausgefallen ist.

Nichts davon garantiert Indexierung oder Ranking, und nicht jede 404-Antwort muss „repariert“ werden. Manche URLs existieren schlicht nicht. Das Ziel ist kleiner und besser begründbar: Menschen sollten eine hilfreiche Erklärung erhalten, während Software einen Status bekommt, der dieselbe Realität beschreibt.