Soft 404 in JavaScript-Shops: Wenn eine Fehlerseite HTTP 200 liefert

Eine Produktadresse liefert HTTP 200. Im Browser steht trotzdem „Produkt nicht gefunden“. Das passiert in JavaScript-Shops, wenn zunächst eine erfolgreiche Anwendungshülle ausgeliefert wird und erst eine spätere Datenanfrage entscheidet, ob das Produkt überhaupt existiert.

Für die Diagnose musst du drei Zustände getrennt betrachten: den Status der Dokumentantwort, das Ergebnis der Produkt-API und den tatsächlich gerenderten Inhalt. Wer nur die erste Zeile des HTTP-Protokolls prüft, kann eine leere oder fehlerhafte Seite als gesunden Produktaufruf zählen.

Google beschreibt solche erfolgreichen Antworten mit leerem Inhalt oder einer Fehlermeldung in seiner Dokumentation zu HTTP-Statuscodes als mögliche Soft-404-Fälle. Der Status 200 garantiert keine Indexierung. Die passende Korrektur hängt jedoch davon ab, warum die Seite fehlt. Ein gelöschtes Produkt ist etwas anderes als ein Datenbankausfall.

Die Fehlermeldung ist noch keine Diagnose

Beginne mit einer betroffenen URL und prüfe, ob ihr Inhalt tatsächlich existieren soll. Suche dafür im zuständigen Produktbestand nach derselben ID oder demselben Slug. Eine zufällig erratene Adresse und ein weiterhin angebotenes Produkt dürfen nicht in derselben Fehlergruppe landen.

Halte außerdem fest, woher die URL stammt. Wird sie noch aus einer Kategorie verlinkt? Steht sie in einer Kampagne? Ist sie nur ein alter Pfad nach einem Relaunch? Diese Informationen helfen bei der Priorisierung und verhindern, dass ein bewusst entfernter Inhalt durch eine technische Reparatur versehentlich wiederhergestellt wird.

Die Indexierung bewertet nicht nur einen Transportstatus. Dass der Server ein Dokument erfolgreich übertragen hat, sagt noch nichts darüber aus, ob dieses Dokument das angekündigte Produkt enthält. Umgekehrt ist eine echte 404 für eine nicht vorhandene Adresse häufig genau das richtige Ergebnis und kein zu beseitigender SEO-Fehler.

Schreibe deshalb vor der Übergabe die Erwartung auf. „Dieses Produkt existiert und muss seine Details zeigen“ ist ein anderes Entwicklungsziel als „dieser entfernte Pfad soll nicht mehr verfügbar sein“. Ein roter Befund im Crawler entscheidet diese Frage nicht für das Team.

Ein fiktiver Shop mit zwei sehr verschiedenen Fehlern

Das folgende Beispiel ist erfunden. Unter https://example.com/produkte/lampe-72 lädt ein Shop zunächst Navigation, Footer und einen leeren Produktbereich. Die Dokumentantwort hat Status 200. Danach fragt die Anwendung https://example.com/api/products/lampe-72 ab.

Im ersten Fall antwortet die API mit 404, weil die Produkt-ID nicht existiert. Der Browser zeigt „Produkt nicht gefunden“. Die Dokumentantwort bleibt trotzdem die bereits gesendete erfolgreiche Antwort. Ein HTTP-Check ohne Rendering sieht deshalb zunächst keinen Fehler.

Im zweiten Fall existiert die Lampe weiterhin. Die API antwortet aber mit 503 oder läuft in einen Timeout. Ein zu allgemeiner Fehlerhandler zeigt auch dann „Produkt nicht gefunden“. Für Besucher sehen beide Fälle gleich aus. Fachlich sind sie verschieden: Im zweiten Fall kennt die Anwendung den Existenzstatus gerade nicht.

Ein Handler, der jeden Fehler in eine leere Produktliste oder eine Nicht-gefunden-Seite verwandelt, verwischt diese Unterscheidung. Eine korrekt modellierte Anwendung behält mindestens „gefunden“, „bestätigt nicht vorhanden“ und „vorübergehend nicht ermittelbar“ auseinander. Diese Zustände müssen auch im Diagnoseprotokoll erhalten bleiben.

Erst das Dokument, dann die Datenanfrage prüfen

Lade die Adresse vollständig neu und öffne im Netzwerkbereich der Entwicklertools die Anfrage vom Typ Dokument. Notiere deren Status, die endgültige URL und eventuell vorhandene Weiterleitungen. Sichere die Antwort, bevor du die Produktanfrage untersuchst.

Für einen unabhängigen HTTP-Abruf kannst du Header und Body speichern:

bashcurl -sS -D document-headers.txt -o document.html "https://example.com/produkte/lampe-72"

Unter Windows PowerShell verwendest du bei Bedarf curl.exe. Der Befehl führt kein JavaScript aus. Er zeigt deshalb nicht, ob die Anwendung nach dem Laden noch Produktdaten bekommt. Suche im gespeicherten Body nach einer konkreten Produktinformation und unterscheide dabei echten Inhalt von einem bloßen Ladeplatzhalter.

Wechsle anschließend zurück in den Browser und öffne die zugehörige Datenanfrage. Erfasse Status, Antwortinhalt und Laufzeit. Eine API kann auch HTTP 200 mit einem Anwendungsfehler im JSON liefern. Deshalb reicht selbst auf dieser Ebene die Statusnummer allein nicht aus.

Prüfe die öffentliche Seite ohne bestehende Anmeldung oder vorbereiteten Warenkorb. Ein persönlicher Sitzungszustand kann den Abruf verändern. Dokumentiere solche Bedingungen, statt einen erfolgreichen eingeloggten Aufruf auf alle Besucher oder Crawler zu übertragen. Bei einem Website-Relaunch ist zudem zu prüfen, ob alte und neue Produktpfade dieselbe Datenquelle erreichen.

Ordne die gespeicherten Antworten der Testzeit und dem geprüften Release zu. Ein später erfolgreicher Abruf zeigt nicht, welchen Inhalt die frühere Fehlerantwort hatte. Bei sporadischen Ausfällen ist die Verbindung zwischen Dokument, Datenanfrage und Release meist aussagekräftiger als eine Sammlung undatierter Screenshots.

Direktaufruf und Client-Navigation vergleichen

Öffne dieselbe Produktadresse nun über einen internen Link aus einer Kategorie. Eine Client-Navigation fordert möglicherweise nur Daten oder ein Framework-Payload an und kein neues vollständiges HTML-Dokument. Die 404 einer API ist dann weiterhin nicht der Status einer neu angeforderten Dokumentseite.

Lade die Zieladresse danach direkt neu. Wenn der Direktaufruf scheitert, der interne Wechsel aber funktioniert, kann das Routing am Server anders aufgelöst werden als im Browser. Funktioniert nur der Direktaufruf, liegt der Verdacht näher am Client-Router, seinem Cache oder seinem Fehlerzustand. Das ist eine Eingrenzung, noch kein Beweis für eine bestimmte Codezeile.

Teste außerdem den Wechsel von einem fehlenden Produkt zu einem existierenden. Bleibt eine Nicht-gefunden-Meldung oder ein gesetztes noindex im Dokument zurück, wird aus einem einzelnen Fehlerzustand ein Problem für die nächste gültige Seite. Prüfe diesen Übergang auch mit Zurück und Vorwärts.

Für das Crawling muss jede relevante URL unabhängig von einer vorherigen erfolgreichen Sitzung erreichbar sein. Ein Klickpfad, der nur mit bereits geladenen Produktdaten funktioniert, ist deshalb keine ausreichende Abnahme.

Beachte auch einen Router, der während des Ladens noch die vorherigen Produktdetails unter der neuen Adresse zeigt. Scheitert die neue Datenanfrage, kann dieser Zwischenzustand bestehen bleiben. Die sichtbaren Details des vorherigen Artikels sind dann kein Beleg für einen erfolgreich geladenen neuen Artikel.

Die Testmatrix braucht auch den Ausfallfall

Stelle die Datenzustände in einer dafür vorgesehenen Testumgebung gezielt her. Lösche keine echten Produkte und unterbrich keine produktive API, um einen Fehler nachzustellen. Ein dokumentierter Testdatensatz und kontrollierte Antwortfälle reichen für die technische Prüfung.

Notiere für jede Zeile die erwartete Reaktion, bevor du den Test ausführst. Ergänze Dokumentstatus, API-Ergebnis, sichtbaren Hauptinhalt und die wirksamen Robots-Angaben. Ein Screenshot allein enthält diese Informationen nicht. So kann ein Entwickler nachvollziehen, ob die Datenzuordnung oder erst die Darstellung korrigiert werden muss.

Den Fehler dort behandeln, wo sein Zustand bekannt ist

Kann der Server vor dem Senden des Dokuments feststellen, dass das Produkt nicht existiert, sollte er diesen Zustand passend ausdrücken. Google empfiehlt aussagekräftige HTTP-Statuscodes. Bei rein clientseitigen Anwendungen nennt die JavaScript-SEO-Dokumentation Alternativen, wenn ein passender Dokumentstatus technisch nicht praktikabel ist: eine Weiterleitung zu einer echten 404-Antwort oder ein per JavaScript gesetztes noindex für die Fehlerseite.

Diese Alternativen brauchen sorgfältige Tests. Die tatsächliche Zielseite einer Weiterleitung muss den vorgesehenen Fehlerstatus liefern. Ein noindex darf beim nächsten gültigen Produktaufruf nicht versehentlich bestehen bleiben. Eine zentrale Metadatenverwaltung ist dabei besser nachvollziehbar als mehrere Komponenten, die unabhängig Robots-Tags anhängen.

Streaming verändert außerdem den Zeitpunkt, an dem der Status feststeht. Die aktuelle Next.js-Dokumentation zu not-found beschreibt beispielsweise eine 404 vor Beginn des Streams, während nach Streaming-Beginn der Status 200 bleibt und die Nicht-gefunden-Ansicht mit noindex erscheint. Prüfe die eingesetzte Framework-Version. Eine Fehlerkomponente allein beweist keinen 404-Status der Antwort.

Leite aus einem verzögerten API-Fehler daher nicht pauschal ab, dass nur eine andere sichtbare Fehlermeldung nötig sei. Kläre, ob das Framework den Existenzstatus früher bestimmen kann und welche Indexierungsregel für den gewählten Auslieferungspfad vorgesehen ist. Bereits gesendete Header lassen sich nicht durch einen späteren Text im Browser ersetzen.

Prüfe die Korrektur deshalb auch mit einer frischen Dokumentanfrage. Ein reparierter Browserwechsel kann die Serverantwort unverändert lassen. Umgekehrt kann ein korrigierter Serverpfad anschließend wieder von einer Browser-Komponente überschrieben werden. Beide Wege gehören zur Abnahme.

Ein Timeout ist keine dauerhafte Löschung

Wenn die Produktdaten vorübergehend nicht verfügbar sind, ist die Aussage „dieses Produkt existiert nicht“ unbelegt. Ein pauschales noindex für jeden Timeout kann deshalb die falschen Seiten treffen. Dasselbe gilt für eine dauerhafte Weiterleitung, die nur aufgrund eines kurzzeitigen Backend-Fehlers angelegt wird.

Behandle den Ausfall als eigenen Betriebszustand. Falls der Server die gewünschte Seite wegen einer vorübergehenden Störung nicht liefern kann, braucht die Antwort eine dazu passende Fehlerbehandlung. Falls eine brauchbare zwischengespeicherte Produktseite ausgeliefert wird, prüfst du zusätzlich, welche Informationen darin noch verlässlich sind. Preise und Verfügbarkeit dürfen nicht durch den Wunsch nach einem grünen SEO-Test erfunden werden.

Auch eine leere Kategorie verdient eine eigene Entscheidung. Google empfiehlt für Kategorien ohne nützlichen Inhalt gegebenenfalls noindex und nennt 404 als Möglichkeit, wenn eine leere Kategorie aus Suche und Navigation entfernt wird. Das erläutert die Dokumentation zu Shop-URLs. Ein API-Ausfall, der nur fälschlich null Produkte liefert, ist keine bestätigte leere Kategorie.

Ein Canonical Tag ersetzt diese Zustandsentscheidung nicht. Eine kaputte Produktseite pauschal auf die Kategorie zu kanonisieren, stellt weder die fehlenden Daten wieder her noch macht es aus der Fehleransicht eine gleichwertige Inhaltskopie.

Nach der Reparatur auf zurückgebliebene Signale achten

Wiederhole zuerst dieselben Matrixfälle in derselben Umgebung. Prüfe bei gültigen Produkten den tatsächlichen Inhalt, bei fehlenden Produkten die vorgesehene Fehlerbehandlung und bei Ausfällen den getrennten Betriebszustand. Vergleiche zusätzlich Direktaufruf und Browsernavigation, damit eine Korrektur nicht nur einen der Wege abdeckt.

Der Site Audit von Crawl Foundry hilft, technische Befunde auf einen klaren URL-Umfang zu beziehen. Ergänze für Soft-404-Untersuchungen die gespeicherten Dokumentantworten und die zugehörigen Datenzustände. Ein reiner Statuscode-Export kann den späteren Fehler im gerenderten Inhalt nicht vollständig beschreiben.

Entfernte Produktadressen sollten nicht weiter als gewünschte Suchseiten in der XML-Sitemap stehen. Prüfe gleichzeitig die internen Verweise. Eine saubere Fehlermeldung macht einen weiterhin prominent verlinkten, versehentlich gelöschten Artikel nicht automatisch richtig.

In der Google Search Console beobachtest du anschließend den betroffenen Befund und den Zeitpunkt der letzten Verarbeitung. Die aktuelle Live-Prüfung und ein älterer Indexstatus können vorübergehend unterschiedliche Zustände zeigen. Das ist kein Anlass, dieselbe unveränderte Korrektur immer wieder zu veröffentlichen.

Bleibt eine gültige Seite stattdessen gecrawlt, aber nicht indexiert, untersuchst du diese Meldung gesondert. Der technische Erfolg hier ist konkret: Existierende Produkte liefern ihren Inhalt, bestätigte fehlende Produkte werden korrekt behandelt und ein vorübergehender Datenfehler wird nicht mehr als dauerhafte Löschung ausgegeben.