Was ist ein Soft 404?

Ein Soft 404 ist eine Seite, die dem Besucher sagt, dass es nichts gibt, und dem Server, dass alles in Ordnung ist. Der Browser bekommt den Code 200, der Nutzer liest „Produkt nicht verfügbar“ oder „keine Ergebnisse gefunden“, und beide Aussagen widersprechen sich.

Google löst den Widerspruch zugunsten des Inhalts auf. Erkennt es, dass eine 200-Antwort keinen echten Inhalt trägt, behandelt es die Seite, als gäbe es sie nicht: Sie fliegt aus dem Index und wird in der Search Console entsprechend markiert. Der Name sagt es: ein weicher 404, einer, den der Server nicht erklären wollte.

Vom ehrlichen 404-Fehler gehört er getrennt. Der ist kein Problem, sondern die richtige Antwort. Dass eine verschwundene Seite 404 liefert, ist genau, was passieren soll; der Fehler entsteht, wenn sie verschwindet und so tut, als wäre sie noch da.

Der häufigste Fall sieht auf den ersten Blick nicht einmal nach Fehler aus: alles Verschwundene auf die Startseite umleiten. Die lädt, antwortet 200 und ist voller Inhalt, also fällt niemandem etwas auf. Für Google ist es trotzdem ein Soft 404, weil der Nutzer etwas Bestimmtes suchte und etwas anderes bekam.

Der Name täuscht ein wenig, weil er nach einer milden Variante eines Fehlers klingt. Tatsächlich beschreibt er einen Widerspruch: zwischen dem, was die HTTP-Antwort behauptet, und dem, was die Seite enthält. Alles Weitere folgt daraus, auch der Grund, warum Google sich die Mühe macht, es zu erkennen.

Eine Suchmaschine kann sich nicht allein auf den Code verlassen, weil ihn jeder versehentlich falsch setzen kann. Nähme sie die 200 wörtlich, füllte sich der Index mit Seiten, die verkünden, dass es nichts gibt. Deshalb prüft sie den Inhalt, und deshalb besteht die Korrektur nie darin, das Symptom zu verstecken, sondern darin, Code und Inhalt dasselbe sagen zu lassen.

Die vier üblichen Quellen tauchen in fast jeder Prüfung auf, und keine davon wurde absichtlich angelegt.

Kataloge, die leerlaufen. Eine E-Commerce-Kategorie ohne Produkte, ein Filter ohne Treffer, ein Schlagwort ohne Beiträge. Die Vorlage arbeitet weiter und liefert 200, drinnen steht aber nur die Mitteilung, dass es nichts gibt.

Bequeme Weiterleitungen. Alles Unauffindbare geht auf die Startseite oder in eine Sammelkategorie statt auf ein gleichwertiges Ziel. Eingebaut wird das meist in guter Absicht, um „den Nutzer nicht zu verlieren“, und erreicht das Gegenteil.

Fehlerseiten aus JavaScript. Der Server liefert ein leeres Dokument mit 200, die Meldung erscheint erst, wenn das Skript läuft. Wer im Browser misst, sieht alles in Ordnung; der Crawler sieht zuerst eine 200 ohne Inhalt.

Inhalt, der zu dünn ist, um zu zählen. Eine Produktseite mit nur Titel und Preis, ohne Beschreibung und Bilder, kann genauso eingeordnet werden. Hier verschwimmt die Grenze zu Thin Content, und das Mittel ist dasselbe: echten Inhalt geben oder die Seite zurückziehen.

Eine fünfte Quelle verdient eine eigene Erwähnung, weil kaum jemand nach ihr sucht: die Ergebnisseiten der internen Suche. Viele Websites lassen sie indexierbar, und es genügt, dass jemand eine Suche ohne Treffer verlinkt, damit der Crawler sie entdeckt. Jede Wortkombination erzeugt eine eigene URL, und fast alle sind leer.

Das Mittel ist hier nicht technisch, sondern eine Frage der Entscheidung: dass diese URLs für Suchmaschinen nicht existieren sollen. Eine Regel in der robots.txt oder ein Noindex lösen den Fall vollständig und geben nebenbei Crawl-Budget für das frei, worauf es ankommt.

Der Schaden liegt nicht darin, dass die Seite nicht rankt — eine leere Seite soll nicht ranken. Der Schaden ist, was es kostet, das herauszufinden.

Jeder Soft 404 verbraucht Crawl-Budget: Der Crawler fordert die Seite an, bekommt 200, verarbeitet sie vollständig und schließt erst danach, dass nichts da war. Ein ehrlicher 404 ist mit einer kurzen Antwort erledigt, und das System kommt nicht wieder. In einem Katalog mit tausenden Filterkombinationen entscheidet dieser Unterschied, welche echten Seiten unindexiert bleiben — siehe Indexierung.

Außerdem verschmutzen sie die Diagnose. Ein Abdeckungsbericht voller Soft 404 verdeckt die wirklichen Probleme, und das Team gewöhnt sich an eine rote Übersicht. Das ist die schlechteste Lage überhaupt: Wo alles markiert ist, sieht niemand mehr hin.

Für den Besucher schließlich ist es eine Frage der Redlichkeit. Eine gut gemachte Fehlerseite mit Suche und Verweisen auf nahe Kategorien rettet den Besuch. Eine Weiterleitung auf die Startseite zwingt zum Neuanfang und endet meist in der Absprungrate.

Eine Folge zeigt sich außerhalb des technischen Berichts: Soft 404 verderben die Statistik. Eine Seite, die 200 antwortet, zählt in jedem Werkzeug der Web-Analyse als normaler Besuch, der Verkehr auf leeren Seiten mischt sich also unter den nützlichen. Die durchschnittliche Conversion sinkt, ohne dass jemand weiß, warum.

Ein erklärter 404 lässt sich dagegen filtern, messen und priorisieren: Man sieht, wie viele Besuche dort landen, woher sie kommen und was sie suchten. Dieser Unterschied macht aus einem unsichtbaren Problem eine nach Wirkung sortierte Aufgabenliste.

Die Regel ist kurz: Der Code soll die Wahrheit über den Inhalt sagen. Von da an gibt es drei Wege, je nach Fall.

Gibt es die Seite nicht mehr und kein Gegenstück, liefere 404, oder 410, wenn die Rücknahme endgültig ist. Die 410 sagt Google, dass ein erneutes Nachsehen unnötig ist, und gibt Crawling früher frei.

Gibt es ein gleichwertiges Ziel, eine 301-Weiterleitung unmittelbar dorthin, nicht auf die Startseite und ohne Kette dazwischen. Gleichwertig heißt, dass es dieselbe Absicht bedient, nicht dass es im selben Bereich liegt.

Soll die Seite bestehen bleiben und ist nur gerade leer, gib ihr echten Inhalt: verwandte Produkte, eine Erklärung der Kategorie, eine Suche. Eine Katalogkategorie, die saisonal leerläuft, muss nicht verschwinden, aber sie muss etwas anbieten.

Danach die Kontrolle: Der Bericht in Search Console listet die markierten Seiten, und man sieht sich je Typ eine von Hand an, zusätzlich mit einer direkten Anfrage — dasselbe Symptom kann in verschiedenen Vorlagen verschiedene Ursachen haben.

Ein Hinweis zur Reihenfolge. Bevor man Vorlagen anfasst, gruppiert man die markierten URLs nach Muster, statt sie einzeln durchzugehen. In einem Katalog sind zwanzigtausend Soft 404 meist drei falsch gesetzte Regeln; diese drei zu korrigieren erledigt die ganze Liste, während Seite für Seite nie endet.

Und eine Warnung zur Kontrolle danach: Der Bericht braucht Zeit, weil er davon abhängt, dass Google erneut crawlt. Eine Liste, die drei Tage nach der Korrektur noch voll ist, heißt nicht, dass die Korrektur misslang, sondern dass noch nicht nachgesehen wurde — wie bei den Felddaten in Search Console.

• Alles Nichtvorhandene auf die Startseite umleiten, weil „so verliert man niemanden“: Man verliert ihn trotzdem, und obendrein entsteht ein Soft 404.
• Den 404 für einen Fehler halten, der aus dem Bericht verschwinden muss. Er ist die richtige Antwort, wenn es etwas nicht mehr gibt.
• Nur im Browser prüfen, wo die Fehlermeldung per JavaScript erscheint und alles normal aussieht, statt den Antwortcode direkt anzusehen.
• Die Vorlagen korrigieren und die internen Links weiter auf die leeren URLs zeigen lassen, sodass der Crawler weiter dort ankommt.
• Filterkombinationen indexierbar lassen, die fast immer leer sind, statt zu entscheiden, welche überhaupt existieren sollen.