Was ist Fehler 404?

Der Code 404 gehört zur 4xx-Familie, die Fehler bündelt, die von der Anfrage des Clients ausgehen, mit einem entscheidenden Unterschied zum Fehler 400: Bei einem 400 ist die Anfrage fehlerhaft aufgebaut, der Server sucht gar nicht erst nach der Ressource. Bei einem 404 kommt die Anfrage sauber an, der Server verarbeitet sie und stellt fest, dass unter dieser URL nichts existiert.

Er ist auch das genaue Gegenstück zum Fehler 500. Bei einem 500 scheitert der Server beim Versuch zu antworten; bei einem 404 funktioniert der Server einwandfrei und antwortet ganz normal, nur lautet die Antwort "hier gibt es nichts". Dieser Unterschied ist wichtig für die Diagnose: Ein Anstieg der 404-Fehler heißt nicht, dass der Server ausgefallen ist, sondern dass Links oder URLs auf Seiten zeigen, die es nicht mehr gibt.

Die häufigsten Ursachen sind einfach: Eine Seite wird gelöscht, ohne eine Weiterleitung zu hinterlassen, jemand vertippt sich bei einer URL, Inhalte ziehen an eine andere Adresse um, ohne die internen Links anzupassen, oder eine Domain-Migration reißt bestehende Routen ein. In all diesen Fällen trifft den Server keine Schuld: Er findet schlicht die angeforderte Ressource nicht.

Nicht jedes "nicht gefunden" wird gleich behandelt. Die Tabelle vergleicht den 404 mit den gängigsten Alternativen, einschließlich des schwierigen Soft-404-Falls.

Der Soft 404 ist der gefährlichste Fall, weil er unbemerkt bleibt: Die Seite zeigt inhaltlich "keine Ergebnisse gefunden" oder Ähnliches an, der Server antwortet aber mit 200, als wäre der Inhalt gültig. Google behandelt solche Seiten trotzdem als 404 für die Indexierung, der Websitebetreiber sieht das in den eigenen Logs aber oft anders, was die Erkennung verzögert.

Sendet ein Browser oder ein Crawler eine Anfrage, verarbeitet der Server sie und sucht die passende Ressource. Ist die Anfrage korrekt aufgebaut, wie bei der großen Mehrheit der 404-Fälle, gelangt der Server bis zur Phase der Ressourcensuche und stellt dort fest, dass unter dieser Route nichts existiert. Er gibt dann den Code 404 zurück, zusammen mit einer Fehlerseite, entweder einer eigenen oder der generischen des Servers.

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:18:47 GMT

Googlebot erhält denselben 404 wie jeder Besucher und interpretiert ihn einheitlich: Er meldet dem restlichen Indexierungssystem, dass der Inhalt nicht existiert. War die URL indexiert, entfernt das System sie mit der Zeit aus dem Index; entdeckt Google sie zum ersten Mal mit einem 404, wird sie erst gar nicht verarbeitet. Die Crawling-Frequenz dieser Route sinkt schrittweise, je öfter sich der Fehler wiederholt, ein anderes Verhalten als bei einem Fehler 500, bei dem Google die URL oft mehrfach erneut versucht, bevor das Crawling gedrosselt wird, weil ein temporärer Fehler vermutet wird.

Der Soft 404 durchbricht diese Logik, weil der HTTP-Code "alles gut" (200) sagt, während der Inhalt das Gegenteil zeigt. Google erkennt diesen Widerspruch, indem es den tatsächlichen Seiteninhalt analysiert, nicht nur den Statuscode, und behandelt die Seite in der Search Console am Ende wie einen 404, obwohl technisch nie dieser Code zurückgegeben wurde. Das praktische Ergebnis ist dasselbe wie bei einem echten 404: Die URL wird nicht indexiert oder entfernt, falls sie es schon war.

Ein einzelner 404 schadet dem Ranking der übrigen Domain nicht; er gehört zum normalen Betrieb einer Website und Google rechnet damit. Problematisch wird es in zwei konkreten Fällen. Der erste: Eine URL, die zuvor rankte und Links erhielt, intern wie extern, gibt plötzlich 404 zurück, ohne dass eine Weiterleitung diese Autorität weitergibt. Der Wert dieser Links geht dann verloren, statt auf eine lebende Seite überzugehen.

Der zweite Fall ist die Menge. Viele angehäufte 404-Fehler, vor allem wenn Googlebot sie über kaputte interne Links findet, verbrauchen Crawl-Budget, das für wichtigere Seiten gebraucht würde. Das drückt nicht das Ranking der gesamten Website, kann aber verlangsamen, wie schnell neue oder aktualisierte Inhalte entdeckt werden.

Die Search Console weist 404-Fehler als eigene Kategorie aus, "Nicht gefunden (404)", innerhalb des Berichts zur Seitenindexierung, etwas, das weder der Fehler 400 noch andere Clientfehler bekommen: Die landen gebündelt in einer Sammelkategorie. Das erleichtert es, die vollständige Liste betroffener URLs zu prüfen, ohne Daten mit den Server-Logs abzugleichen, was bei der Diagnose eines 400 oder eines Fehlers 500 dagegen nötig ist.

• Den Bericht "Nicht gefunden (404)" der Seitenindexierung in der Search Console regelmäßig prüfen, nicht nur nach einer Migration.
• Eine 301-Weiterleitung auf eine inhaltlich passende Seite setzen, nie standardmäßig auf die Startseite: Eine pauschale Weiterleitung verwirrt sowohl Nutzer als auch Google darüber, was sie tatsächlich gefunden haben.
• Eine eigene 404-Seite mit interner Suche und Links zu wichtigen Bereichen gestalten, für die Fälle, in denen keine passende URL zum Weiterleiten existiert.
• Interne Links nach jeder Strukturänderung oder Migration prüfen, bevor Googlebot sie selbst als defekt entdeckt.
• Kontrollieren, dass Vorlagen für "keine Ergebnisse" (interne Suche, Produktfilter ohne Treffer) tatsächlich 404 statt 200 zurückgeben, um einen Soft 404 zu vermeiden.
• Die Kontrolle von 404-Fehlern als festen Teil des technischen SEO der Website behandeln, nicht als einmalige Aufgabe nach einem Launch.

• Alle 404-Fehler auf die Startseite weiterleiten, statt auf eine Seite mit verwandtem Inhalt.
• Eine Vorlage für leere Ergebnisse mit 200 statt 404 antworten lassen und dadurch unbemerkt einen Soft 404 erzeugen.
• 404-Fehler von URLs ohne aktuellen Traffic ignorieren, obwohl einige davon noch wertvolle externe Links haben.
• Den Fehler 400 bei der Diagnose mit dem 404 verwechseln, obwohl die Ursache in jedem Fall eine andere ist.
• Einen Anstieg von 404-Fehlern vorschnell für ein Serverproblem wie einen Fehler 500 halten, statt zuerst interne Links und Rastreo-Quellen zu prüfen.