Ihre 404-Seite sieht richtig aus – aber antwortet sie auch mit 404?

Sie tippen eine URL falsch ein. Die Website zeigt sauber „Seite nicht gefunden“, bietet eine Suche an und verlinkt zurück zur Startseite. Auf den ersten Blick ist alles korrekt.

Dann öffnen Sie die Netzwerkansicht und sehen beim ersten Dokument-Request: 200 OK.

Das ist kein kosmetisches Detail. HTTP 200 sagt: Die Anfrage war erfolgreich. HTTP 404 sagt: Für diese Zieladresse wurde keine aktuelle Ressource gefunden. Wenn Inhalt und Statuscode unterschiedliche Geschichten erzählen, entsteht ein Soft 404.

Gerade bei Single-Page Applications, statischen Hosting-Fallbacks und sehr aggressivem Client-Routing passiert das leichter, als viele Teams erwarten.

Die wichtigste Audit-Frage lautet deshalb:

Was antwortet der Server auf eine nicht existierende URL, bevor JavaScript irgendetwas repariert?

Warum eine hübsche 404-Seite nicht genügt

Browser-Nutzer sehen primär das gerenderte Ergebnis. Crawler, Monitoring-Systeme, Proxies und andere technische Clients sehen zusätzlich das HTTP-Protokoll.

Nach RFC 9110 bedeutet 200 OK, dass die Anfrage erfolgreich war. 404 Not Found signalisiert dagegen, dass der Origin-Server keine aktuelle Repräsentation für die angefragte Ressource gefunden hat oder ihre Existenz nicht offenlegen will.

Wenn /produkte/definitiv-nicht-existent mit 200 beantwortet wird und JavaScript später nur einen „Nicht gefunden“-Screen rendert, hat die Anwendung für Menschen einen Fehler dargestellt, auf Protokollebene aber Erfolg gemeldet.

Genau diese Diskrepanz ist der Kern des Problems.

Wie SPAs in diese Falle geraten

Viele Client-Anwendungen benötigen für echte App-Routen denselben HTML-Einstiegspunkt. Deshalb wird auf Hosting- oder Serverebene häufig sinngemäß festgelegt:

• existiert eine echte Datei, liefere sie aus;
• ansonsten liefere index.html;
• der Client-Router entscheidet danach, welche Ansicht gezeigt wird.

Für gültige Routen ist das praktisch. Für ungültige Routen kann es jedoch bedeuten, dass jede beliebige URL zunächst mit 200 beantwortet wird.

Der Router erkennt anschließend zwar, dass keine Route passt. Den Statuscode der bereits ausgelieferten Dokument-Antwort kann er aber nicht rückwirkend in ein echtes HTTP 404 verwandeln.

Ähnliches kann bei dynamischen Detailseiten passieren: Die App-Shell lädt erfolgreich mit 200, danach antwortet eine API mit 404, und erst dann erscheint „Datensatz nicht gefunden“. Für eine interne Anwendung kann dieses Modell völlig legitim sein. Für öffentlich indexierbare URLs sollte man jedoch bewusst entscheiden, welches Signal die URL nach außen geben soll.

Was Google unter einem Soft 404 versteht

Google Search Central beschreibt einen Soft 404 als eine URL, die dem Nutzer vermittelt, dass eine Seite nicht existiert, gleichzeitig aber 200 (success) zurückgibt. Solche Seiten können aus dem Suchindex ausgeschlossen und in der Search Console als Soft-404-Fehler ausgewiesen werden.

Für JavaScript-Websites empfiehlt Google ausdrücklich, aussagekräftige HTTP-Statuscodes zu verwenden. Bei clientseitigen SPAs nennt die Dokumentation zwei Ausweichmuster, wenn ein echter Statuscode an der ursprünglichen Route technisch schwer umzusetzen ist:

1. per JavaScript zu einer URL weiterleiten, die serverseitig mit 404 antwortet;
2. auf der Fehlerseite per JavaScript ein noindex-Meta-Tag setzen.

Das sind nützliche Schutzmechanismen. Sie ersetzen aber nicht die grundsätzliche Architekturfrage: Kann Ihre öffentlich sichtbare Routing-Schicht echte Fehler auch als echte Fehler ausliefern?

Vier Fragen für einen brauchbaren Audit

1. Welchen Statuscode liefert der erste Dokument-Request?

Nicht erst die API-Antwort ansehen. Nicht nur die gerenderte Seite prüfen.

Rufen Sie eine garantiert nicht vorhandene URL direkt in einem neuen Tab auf und prüfen Sie den ersten HTML-Request. Ein visuelles „404“ bei gleichzeitigem 200 OK ist das klassische Soft-404-Muster.

Testen Sie auch tiefe Pfade wie:

• /leistungen/nicht-existent
• /blog/2021/entfernter-artikel
• /de/produkte/falscher-slug
• eine zufällige UUID oder einen eindeutig erfundenen Datensatz-Identifier

So erkennen Sie, ob nur einzelne Templates oder die gesamte Fallback-Logik betroffen sind.

2. Was passiert ohne vorhandenen Client-State?

SPA-Fehler zeigen sich oft nur bei direktem Einstieg.

Ein interner Klick kann funktionieren, weil der Router bereits geladen ist und Daten im Speicher hat. Derselbe Deep Link kann nach Reload, in einem neuen Browserfenster oder bei einem Bot anders reagieren.

Prüfen Sie deshalb mindestens:

• direkten Aufruf;
• Reload auf der Route;
• Navigation innerhalb der Anwendung;
• URL ohne JavaScript, soweit sinnvoll;
• gerenderten DOM und initiale Serverantwort getrennt.

3. Werden verschiedene Fehlerzustände zu einem einzigen 200-Screen zusammengequetscht?

Nicht jeder Fehler bedeutet dasselbe.

Eine unbekannte öffentliche URL, ein fehlender Datensatz, eine geschützte Route, ein temporärer Backend-Ausfall und ein absichtlich entfernter Inhalt sind unterschiedliche Zustände. Sie sollten nicht automatisch alle als „200 plus irgendeine Fehlermeldung“ enden.

Das heißt nicht, dass jede interne Anwendung für jeden Zustand eine perfekt semantische Dokument-Antwort braucht. Es heißt: Das Team sollte wissen, welche Schicht welchen Fehler besitzt und welche Statuscodes Nutzer, Crawler, APIs und Monitoring tatsächlich sehen.

4. Würde Ihr Monitoring den Fehler überhaupt bemerken?

Wenn ein externer Check nur fragt „Antwortet die URL mit 2xx?“, kann ein Soft 404 wie ein gesunder Endpunkt aussehen.

Ein sinnvoller Website-Check kombiniert deshalb Statuscodes mit Inhalt und erwarteter Funktion. Beispiele:

• Soll eine bekannte Landingpage 200 liefern und einen bestimmten Marker enthalten?
• Soll eine erfundene URL 404 liefern?
• Soll ein entfernter Inhalt 404 oder bewusst 410 liefern?
• Soll eine geschützte Ressource in Ihrem konkreten Sicherheitsmodell anders reagieren?
• Liefert die öffentliche Fehlerseite selbst stabile Assets, Navigation und Kontaktwege?

Ein Statuscode ist ein Signal. Ein Audit muss prüfen, ob dieses Signal zur tatsächlichen Seite passt.

Ein pragmatischer Implementierungsweg

Server-rendered oder hybrid: Fehler am Server entscheiden

Wenn Routing und Datenzugriff serverseitig stattfinden können, sollte „nicht gefunden“ möglichst dort entschieden werden, wo die HTTP-Antwort noch kontrolliert werden kann.

Dann erhält der Nutzer weiterhin eine gestaltete Fehlerseite, aber die Antwort trägt den passenden Status.

Das ist meist die sauberste Variante für öffentlich erreichbare Inhalts-, Produkt-, Profil- oder Magazinseiten.

Reine Client-SPA: Fallback bewusst begrenzen

Bei einem rein statischen SPA-Deployment ist ein Catch-all oft unvermeidbar. Dann sollte geprüft werden, ob:

• öffentlich indexierbare Bereiche separat serverseitig behandelt werden können;
• bekannte Fehlerpfade auf eine echte 404-URL führen;
• Fehlerseiten zuverlässig noindex erhalten, wenn Google sie nicht indexieren soll;
• Sitemaps, Canonicals und interne Links nur gültige URLs erzeugen;
• das Hosting nicht jede unbekannte Asset- oder Dokument-URL ebenfalls in die App-Shell verwandelt.

Besonders der letzte Punkt ist gern übersehen: Ein fehlendes JavaScript-Bundle oder JSON-Dokument sollte nicht plötzlich HTML mit Status 200 zurückbekommen, nur weil eine globale SPA-Rewrite-Regel zu breit greift.

API-Fehler nicht mit Dokument-Status verwechseln

Eine App kann beim Dokument 200 liefern und später bei /api/products/123 korrekt 404 erhalten. Das ist technisch nicht automatisch falsch.

Die Audit-Frage ist, was die öffentliche URL repräsentiert.

Wenn /produkte/123 als eigenständige, indexierbare Produktseite gedacht ist, sollte ein nicht vorhandenes Produkt anders behandelt werden als eine rein interne App-Ansicht hinter Login. Architektur, SEO-Anforderungen und Betriebsmodell müssen zusammenpassen.

Regressionstests, die wenig kosten und viel finden

Soft 404s gehören in automatisierte Smoke- oder End-to-End-Tests.

Ein kleines Set reicht oft schon:

1. bekannte gültige URL → erwartet 200;
2. eindeutig erfundene URL → erwartet 404 oder bewusst definierte Alternative;
3. gelöschter Datensatz → erwarteter Fehlerstatus;
4. falscher Slug einer dynamischen Route → kein stilles 200;
5. fehlendes Asset → kein HTML-Fallback mit 200;
6. Fehlerseite → enthält sinnvolle Navigation und keinen widersprüchlichen Canonical;
7. falls noindex als SPA-Fallback genutzt wird → nach dem Rendern tatsächlich vorhanden.

Nach Relaunches, Hosting-Wechseln, Router-Upgrades und CDN-Regeländerungen sollten diese Tests erneut laufen. Gerade Rewrite-Regeln können sich ändern, obwohl am sichtbaren 404-Design niemand gearbeitet hat.

Was Website-Pflichtencheck dabei prüfen würde

Bei einem technischen Website-Check betrachten wir nicht nur, ob eine Fehlerseite „schön“ aussieht.

Geprüft werden können unter anderem:

• echte HTTP-Statuscodes bei gültigen und ungültigen URLs;
• SPA-, CDN- und Hosting-Fallbacks;
• dynamische Routen und entfernte Inhalte;
• initiale HTML-Antwort gegenüber nachgeladenen API-Fehlern;
• noindex, Canonical und Sitemap-Konsistenz;
• fehlende Assets und Rewrite-Nebenwirkungen;
• Monitoring-Signale;
• mobile und clientseitige Navigation;
• Regressionen nach Deployments.

Das Ziel ist keine theoretisch perfekte Statuscode-Matrix. Das Ziel ist, dass Browser, Suchmaschinen und Betriebssysteme dieselbe grundlegende Wahrheit über eine URL erhalten.

Wenn Ihre 404-Seite nur im Text „404“ sagt, ist der wichtigste Teil des Tests noch nicht erledigt.