Leere Seiten mit Status 200: Soft-404 und falsche Zielseiten aufdecken

Was ein Soft-404 ist – und was Ihr Test feststellen kann

Google beschreibt einen Soft-404 als Seite, die trotz erfolgreicher HTTP-Antwort mitteilt, dass der angeforderte Inhalt nicht existiert. Auch fehlender Hauptinhalt oder eine leere Seite können dazu führen. Eine tatsächlich von Google erkannte Einstufung erscheint im Bericht zur Seitenindexierung. Ein interner Prüfvermerk wie „Inhalt fehlt bei Status 200“ beschreibt dagegen zunächst Ihre eigene Beobachtung.

Diese Unterscheidung hilft bei der Fehlerbehebung. Eine Antwort kann ein sauber gestaltetes Menü, einen langen Footer und einen korrekten Seitentitel enthalten, während die gesuchte Leistung vollständig fehlt. Prüfen Sie deshalb den Bereich, der die konkrete Leserfrage beantworten soll. Eine Wortzahl für das gesamte Dokument würde in diesem Fall vor allem die gemeinsame Seitenvorlage messen.

Umgekehrt kann eine kurze Antwort ihren Zweck vollständig erfüllen. Eine Seite mit einer Wartungsadresse, einem konkreten Ansprechpartner oder einer eindeutigen Kompatibilitätsangabe braucht keine künstliche Textverlängerung. Behandeln Sie geringe Textmenge und typische Fehlerformulierungen als Hinweise zur Sichtprüfung, nicht als automatische Löschregel.

Legen Sie vor dem Abruf den erwarteten Inhalt fest

Erstellen Sie eine kleine Prüfliste aus wichtigen Zielseiten und bekannten Problemfällen. Nehmen Sie je Seitentyp mindestens eine funktionierende Referenz auf, beispielsweise eine Leistungsseite, einen Dokumentationsartikel und eine Kategorie. Ergänzen Sie eine absichtlich nicht vorhandene Adresse. So sehen Sie, ob Ihr System unterschiedliche Situationen wirklich unterschiedlich behandelt.

Notieren Sie zu jeder URL die erwartete Identität und zwei oder drei inhaltliche Merkmale. Bei einem fiktiven Datenblatt könnten das Produktname, unterstützte Version und Download sein; bei einer Leistung Zielgruppe, Leistungsumfang und Einschränkung. Diese selbst festgelegten Merkmale sind Abnahmekriterien für Ihre Website, keine geheimen Signale einer Suchmaschine.

Dokumentieren Sie außerdem, ob die URL öffentlich funktionieren soll, dauerhaft entfernt wurde oder einen konkreten Nachfolger hat. Ein leerer Filter, eine fehlende Detailseite und ein ausgefallener Datenabruf benötigen unterschiedliche Entscheidungen. Lassen Sie unklare Fälle von der inhaltlich verantwortlichen Person einordnen, bevor Sie technisch umleiten oder entfernen.

Erfassen Sie die vollständige Antwort und das tatsächliche Ziel

Rufen Sie jede Adresse zunächst ohne Anmeldung per GET ab und sichern Sie Antwort-Header und HTML. Erfassen Sie bei jeder Weiterleitung Ausgangsadresse, Status und Location-Ziel bis zur abschließenden Antwort. Ein HEAD-Test kann Header prüfen, liefert aber keinen Hauptinhalt. Ein Werkzeug, das nur den letzten Status 200 ausgibt, kann einen fehlerhaften Umweg zur Startseite verdecken.

Öffnen Sie anschließend dieselbe Adresse in einer frischen Browsersitzung. Halten Sie endgültige URL, sichtbaren Hauptinhalt und fehlgeschlagene Inhaltsanfragen fest. Warten Sie auf ein vorher definiertes fachliches Merkmal oder ein dokumentiertes Testzeitlimit. „Die Seite lädt noch“ darf weder unbegrenzt als Erfolg gelten noch nach einem beliebig kurzen Moment als Beweis für einen dauerhaften Fehler.

Vergleichen Sie Rohantwort und gerenderten Zustand. Ein leeres HTML-Gerüst kann nach erfolgreichem JavaScript-Abruf vollständige Informationen enthalten. Umgekehrt kann das Gerüst mit Status 200 erscheinen, während die Inhalts-API einen Fehler meldet. Die beiden Antworten sind getrennt zu protokollieren. Der verlinkte JavaScript-Leitfaden vertieft diese Rendering-Prüfung.

Halten Sie Zeitpunkt, Browser, Testumgebung und Anmeldung zusammen mit den Belegen fest. Wenn ein Fehler nur zeitweise auftritt, wiederholen Sie den betroffenen Fall gezielt. Dokumentieren Sie die unterschiedlichen Ergebnisse, statt einen erfolgreichen zweiten Abruf rückwirkend zum Beweis für eine stets funktionierende Seite zu machen.

Acht lokale Testfälle für Status und Hauptinhalt

Für diesen Beitrag haben wir am 27. September 2026 acht selbst erstellte Fälle über einen lokalen HTTP-Server und einen isolierten Chrome-Browser geprüft. Die Inhalte und Fehler wurden bewusst konstruiert. Der Test vergleicht definierte Soll-Inhalte mit ausgelieferten Antworten; er ist keine Untersuchung produktiver Websites oder von Googles Klassifizierung.

Die folgende Gegenüberstellung beschreibt die ausgeführten Fälle. Das Textprotokoll und das vollständige Beispielpaket mit Quellcode, Rohantworten und Ergebnissen stehen unter den Quellen bereit.

• Kurze hilfreiche Seite: Status 200 und der vorher festgelegte fachliche Inhalt sind vorhanden. Der Fall besteht die Inhaltsprüfung trotz geringer Textmenge.
• Fehlende Detailseite mit Erfolgscode: Status 200, aber statt des erwarteten Gegenstands erscheint eine Nicht-gefunden-Meldung. Status und tatsächlicher Seitenzweck passen nicht zusammen.
• Seitengerüst mit ausgefallener Inhalts-API: Das Dokument antwortet mit 200, die Inhaltsanfrage mit 503. Im gerenderten Hauptbereich fehlt die erwartete Information. Ein erfolgreicher Dokumentabruf verdeckt hier den Ausfall.
• Seitengerüst mit erfolgreicher Inhalts-API: Das Dokument antwortet ebenfalls mit 200; nach dem Abruf ist der erwartete Inhalt vorhanden. Diese Gegenprobe verhindert, dass jedes anfänglich leere Gerüst pauschal als Fehler gilt.
• Fehlende Detailseite zur Startseite umgeleitet: Je ein Fall mit 301 und 302 endet bei einer 200-Antwort. Die Startseite funktioniert, ersetzt aber den gesuchten Gegenstand nicht. Erst Zieladresse und Inhaltsprüfung machen die Fehlzuordnung sichtbar.
• Korrekte Nicht-gefunden-Antwort: Die entfernte Seite liefert 404 und einen verständlichen Fehlertext. Die fehlende Ressource wird als fehlend ausgewiesen; ein technischer QA-Check darf diesen vorgesehenen Zustand akzeptieren.
• Vorübergehende Nichtverfügbarkeit: Status 503 und ein Retry-After-Header kennzeichnen den konstruierten Ausfall. Das ist eine andere Situation als eine dauerhaft entfernte Seite und kein erfolgreicher Inhaltsabruf.

Wählen Sie die Korrektur nach der tatsächlichen Ursache

Soll der Inhalt weiterhin vorhanden sein, stellen Sie zuerst seine Auslieferung wieder her: Prüfen Sie Datenquelle, Veröffentlichung, Routenauflösung und benötigte Ressourcen. Vergleichen Sie eine betroffene URL mit einer funktionierenden Seite derselben Vorlage. Das grenzt ein, ob ein einzelner Datensatz, die gesamte Vorlage oder eine gemeinsame Abhängigkeit ausfällt.

Ist eine Seite entfernt und gibt es keinen passenden Ersatz, nennt Google 404 oder 410 als korrekte Antwort. Eine hilfreiche Fehlerseite kann trotzdem Navigation und alternative Einstiege anbieten. Ändern Sie nicht bloß den sichtbaren Text: Der tatsächliche HTTP-Status muss zur Entscheidung passen.

Bei einem dauerhaften Umzug zu einem passenden Nachfolger verwenden Sie eine dauerhafte Weiterleitung. Google dokumentiert dafür unter anderem 301 und 308. Prüfen Sie anschließend den Nachfolger gegen die ursprüngliche Leseraufgabe. Unser redaktionelles Kriterium lautet: Wer eine konkrete Integrationsanleitung sucht, muss die passende Anleitung erreichen; eine allgemeine Startseite erfüllt diese Abnahme nicht.

Bei zeitweiliger Überlastung oder Wartung beschreibt RFC 9110 den Status 503; Retry-After kann einen Zeitpunkt oder eine Wartezeit bis zu einem erneuten Versuch angeben. Wählen Sie Fehlercodes nach der realen Ursache und beheben Sie den Ausfall. Google weist darauf hin, dass länger anhaltende Serverfehler zum Verlust bereits indexierter URLs führen können. Ein 503 ist deshalb kein dauerhafter Ersatz für funktionierende Inhalte.

Sonderfälle nicht mit einer pauschalen Regel lösen

Eine absichtlich leere Suchansicht kann für Besucher verständlich sein, ohne als eigenständige Suchzielseite sinnvoll zu sein. Entscheiden Sie zuerst, welche Funktion die konkrete URL erfüllen soll, und prüfen Sie ihre Indexierungs- und Statusregeln separat. Ein allgemeines „alle Seiten ohne Treffer auf 404 setzen“ kann ebenso falsch sein wie „jede Ergebnisansicht dauerhaft mit 200 in der Sitemap behalten“.

Für rein clientseitig geroutete Anwendungen beschreibt Google zwei Möglichkeiten, Fehlerseiten vom Index fernzuhalten: eine JavaScript-Weiterleitung auf eine URL mit echtem 404-Status oder ein per JavaScript gesetztes noindex auf der Fehlerseite. Das sind dokumentierte Lösungen für diesen Sonderfall. Sie stellen fehlenden Fachinhalt nicht wieder her und ersetzen keine Prüfung der tatsächlich sichtbaren Fehlerantwort.

Setzen Sie noindex deshalb nicht wahllos auf reguläre Seiten, nur weil zeitweise eine API ausfällt. Ebenso wenig repariert ein Canonical-Verweis zur Startseite eine verlorene Detailinformation. Bei widersprüchlichen robots.txt- und noindex-Regeln hilft der verlinkte Spezialartikel; für Änderungen ganzer URL-Strukturen der Relaunch-Leitfaden.

So wird aus dem Befund ein überprüfbares Arbeitsticket

Ein gutes Ticket enthält die genaue URL, das erwartete Ergebnis, den beobachteten Statusverlauf, den fehlenden Inhaltsbaustein und einen Vorher-Beleg. Ergänzen Sie vermutete Ursache und bestätigte Ursache als getrennte Angaben. Ordnen Sie eine verantwortliche Person und ein nachprüfbares Abschlusskriterium zu.

Ein ausdrücklich fiktives Beispiel: „Die Anleitung zur Schnittstelle A fehlt. GET liefert 200; der Hauptbereich enthält nur die Nicht-gefunden-Meldung. Der entsprechende Datensatz ist veröffentlicht. Verantwortlich: Webentwicklung. Abnahme: exakte Anleitung ohne Anmeldung sichtbar; eine absichtlich unbekannte Dokument-ID liefert weiterhin 404.“ Das beschreibt eine überprüfbare Reparatur und schützt zugleich den korrekten Fehlerfall.

Priorisieren Sie nach belegter Bedeutung und Reichweite: Ist eine wichtige Kundenaufgabe betroffen, betrifft der Fehler viele URLs derselben Vorlage, und tritt er weiterhin auf? Nutzen Sie nur tatsächlich vorhandene Nutzungsdaten. Aus unseren acht konstruierten Fällen lässt sich weder eine Fehlerquote für Websites noch eine geschäftliche Wirkung ableiten.

Nach der Reparatur Inhalt und Google-Stand getrennt prüfen

Wiederholen Sie den identischen GET- und Browser-Test und sichern Sie die Nachher-Belege. Testen Sie auch die funktionierende Referenz und die absichtlich fehlende Adresse erneut. Dadurch erkennen Sie etwa eine Reparatur, die nun zwar die gewünschte Seite liefert, aber sämtliche unbekannten URLs ebenfalls mit demselben Inhalt beantwortet.

Mit autorisiertem Search-Console-Zugriff können Sie zusätzlich die gespeicherte Indexansicht und einen aktuellen URL-Livetest vergleichen. Googles Dokumentation unterscheidet diese Zeitstände ausdrücklich. Untersuchen Sie verfügbare HTML-, Ressourcen- und Darstellungsinformationen; ein positives Live-Ergebnis garantiert keine Indexaufnahme und deckt nicht alle Indexierungsbedingungen ab.

Ohne solchen Zugriff endet Ihre Aussage bei der belegten technischen Korrektur. Für diesen Beitrag wurden keine Search-Console-Daten erhoben und keine Veränderungen von Rankings, KI-Zitaten oder Indexzuständen gemessen. Ein präziser Abschluss lautet dann: „Erwarteter Inhalt und Status nach Reparatur bestätigt; erneute Verarbeitung durch Google noch nicht nachgewiesen.“