Sie löschen ein Produktblatt, ändern die Struktur Ihrer URLs oder migrieren zu einem neuen CMS. Einige Wochen später zeigt die Google Search Console Dutzende von 404-Fehlern an. Der klassische Reflex besteht darin, alle auf die Startseite umzuleiten. Das ist eine falsche gute Idee, die andere Probleme schafft.
Soft 404 und klassische 404: die Unterscheidung, die Ihre SEO-Strategie verändert
Ein klassischer 404-Fehler sendet einen HTTP-Code 404 (oder 410) an den Browser und Googlebot. Der Server sagt klar: Diese Seite existiert nicht mehr. Google versteht das Signal, entfernt die URL schrittweise aus seiner Crawling-Warteschlange und macht weiter.
Die echte Falle liegt woanders. Ein Soft 404 sendet einen Code 200 OK, obwohl die Seite leer ist oder eine Fehlermeldung anzeigt. Aus der Sicht von Google scheint diese URL zu existieren. Der Bot besucht sie also bei jedem Durchlauf, was unnötig Crawling-Budget verbraucht.
Auf einer Website mit einigen Dutzend Seiten ist der Unterschied vernachlässigbar. Auf einem E-Commerce-Katalog oder einer redaktionellen Website mit Tausenden von URLs verlangsamen die angesammelten Soft 404 die Erkundung der Seiten, die wirklich zählen. Bevor Sie mit Korrekturen beginnen, ist es wichtig zu wissen, wie man einen 404-Fehler bei Google korrigiert, indem man diese beiden Fälle unterscheidet.
Websites, die mit JavaScript-Frameworks (React, Vue, Angular) erstellt wurden, sind besonders anfällig. Wenn eine Route nicht existiert, zeigt die Anwendung eine “Seite nicht gefunden”-Meldung auf der Client-Seite an, aber der Server sendet einen Code 200. Google behandelt dieses Verhalten als Soft 404, und die Seite bleibt in der Crawling-Warteschlange.
Sortieren Sie Ihre 404-Fehler, bevor Sie sie korrigieren: Priorisierungsmethode
Nicht alle 404-Fehler verdienen die gleiche Behandlung. Eine URL, die noch nie einen externen Link erhalten hat, nie Traffic generiert hat und zu veraltetem Inhalt gehört, kann ohne SEO-Schaden 404 bleiben. Google bestätigt dies: Legitime 404 gehören zum normalen Betrieb des Webs.
Haben Sie bereits den Bericht “Seiten” in der Google Search Console aufgerufen, ohne zu wissen, wo Sie anfangen sollen? So klassifizieren Sie Ihre 404 nach Priorität:
- Die URLs, die noch externe Backlinks erhalten: Sie übertragen Autorität. Ohne Weiterleitung verschwindet dieses SEO-Kapital. Identifizieren Sie sie, indem Sie die Daten der Search Console mit einem Crawling-Tool kombinieren.
- Die URLs, die vor ihrer Löschung organischen Traffic generiert haben: Eine 301-Weiterleitung zur inhaltlich nächstgelegenen Seite ermöglicht es, einen Teil dieses Traffics zurückzugewinnen.
- Die URLs, die aus Tippfehlern, Bots oder fehlerhaften URL-Parametern stammen: Lassen Sie sie 404. Diese URLs weiterzuleiten würde unnötige Weiterleitungen schaffen, die Ihre Serverkonfiguration belasten.
Priorisieren Sie die 404, die Backlinks oder historischen Traffic haben. Der Rest kann warten oder niemals behandelt werden.
301-Weiterleitungen und Code 410: die richtige HTTP-Antwort wählen
Die 301-Weiterleitung ist der Standardreflex. Sie funktioniert gut, wenn eine äquivalente Seite auf der Website existiert. Haben Sie eine Kategorie umbenannt oder zwei Artikel zusammengelegt? Die 301 überträgt den Großteil der Linkautorität auf die neue URL.
Wann die 301-Weiterleitung problematisch ist
Eine alte Produktseite auf die Startseite umzuleiten, hilft niemandem. Der Benutzer landet auf einer Seite, die nichts mit seiner Suche zu tun hat, und Google behandelt diese Weiterleitung schließlich als Soft 404. Eine 301-Weiterleitung sollte auf einen thematisch verwandten Inhalt verweisen, nicht auf eine generische Seite.
Der Code 410 zur Anzeige einer endgültigen Löschung
Der HTTP-Code 410 (Gone) zeigt Google an, dass die Seite absichtlich gelöscht wurde und nicht zurückkommt. Google indiziert diese URLs schneller als bei einem einfachen 404. Verwenden Sie den 410 für dauerhaft entfernte Produktseiten, rechtlich problematische Inhalte oder Test-URLs, die niemals indexiert werden sollten.
Der 410 beschleunigt die De-Indexierung im Vergleich zum klassischen 404. Auf einer Website mit einem hohen Volumen an gelöschten Seiten befreit dieser Geschwindigkeitsunterschied das Crawling-Budget schneller.
Benutzerdefinierte 404-Seite: einen Fehler in nützliche Navigation umwandeln
Selbst mit einer rigorosen Weiterleitungsarbeit werden Besucher auf nicht existierende Seiten stoßen. Ein Link, der in einem Forum geteilt wird, eine URL, die aus dem Gedächtnis mit einem Tippfehler eingegeben wird: der 404 Null existiert nicht.
Eine benutzerdefinierte 404-Seite behebt nicht das technische Problem, aber sie begrenzt den Verlust von Nutzern. Damit sie nützlich ist, sollte sie Folgendes bieten:
- Ein sofort sichtbares internes Suchfeld, ohne scrollen zu müssen.
- Links zu den Hauptkategorien oder den meistbesuchten Inhalten der Website.
- Eine klare Nachricht, die bestätigt, dass die Seite nicht existiert, ohne technischen Jargon.
Der technische Punkt, den Sie nicht übersehen dürfen: Ihre benutzerdefinierte 404-Seite muss einen echten HTTP-Code 404 zurückgeben. Wenn Ihr Server oder Ihr CMS für diese Seite einen Code 200 zurückgibt, schaffen Sie genau das Problem der Soft 404, das oben beschrieben wurde. Testen Sie den Antwortcode mit dem URL-Inspektionswerkzeug in der Search Console.
404-Fehler auf einer JavaScript-Website: Überprüfen Sie das Server-Seiten-Rending
Einseitige Anwendungen (SPA) verwalten die Navigation auf der Client-Seite. Wenn ein Besucher auf eine Route zugreift, die nicht existiert, zeigt das Framework ein “Fehler”-Komponente an, ohne dass der Server eingreift. Der HTTP-Code bleibt 200.
Damit Googlebot die Situation korrekt interpretiert, muss die 404-Antwort vom Server kommen. Zwei Ansätze funktionieren: das serverseitige Rendering (SSR), das die Seite mit dem richtigen HTTP-Code generiert, bevor sie an den Browser gesendet wird, oder das statische Vor-Rendering, das HTML-Dateien mit den richtigen Headern produziert.
Eine “Seite nicht gefunden”-Nachricht, die von JavaScript mit einem Code 200 angezeigt wird, wird von Google als Soft 404 behandelt. Überprüfen Sie den tatsächlichen Statuscode im Netzwerk-Tab der Entwicklertools Ihres Browsers oder direkt über die Search Console.
Auf einer klassischen Website unter WordPress oder einem ähnlichen CMS tritt dieses Problem normalerweise nicht auf: Der Server verwaltet nativ den 404-Code. Die Wachsamkeit betrifft vor allem entkoppelte Architekturen (Headless CMS + JavaScript-Frontend).
