Nicht gefunden (404)

TL;DR — „Not found (404)“ in der Search Console bedeutet, dass Google Ihren Server nach einer Seite gefragt und eine „Not found“-Antwort erhalten hat, sodass es sie nicht indexiert hat. Google hat die URL selbst gefunden – normalerweise über einen Link irgendwo oder weil die Seite früher existierte – was beschreibt, wie sie entdeckt wurde, nicht den Beweis, dass sie in Ihrer aktuellen Sitemap fehlt. Das ist normal und in der Regel in Ordnung, aber nur für URLs, die tatsächlich verschwinden sollen. Sie müssen es nur beheben, wenn die URL funktionieren sollte; in diesem Fall bringen Sie die Seite zurück oder leiten sie auf den richtigen Ersatz weiter.

Was „Not found (404)“ bedeutet

Diese Bezeichnung bedeutet, dass Google beim Anfordern der URL einen HTTP-404-Status erhalten hat. Evidence for this claim Google reports Not found 404 when the page returned a 404 response when requested. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google behandelt anhaltende 4xx-Antworten außer 429 so, als ob der Inhalt nicht existiert. Evidence for this claim Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Öffnen Sie den Bericht Seitenindexierung in der Google Search Console, und Sie sehen eine Liste von Gründen, warum Seiten nicht indexiert werden. „Not found (404)“ ist einer davon. Es bedeutet, dass Googlebot die URL angefordert hat und Ihr Server mit einem HTTP-404 (Not Found) geantwortet hat – die Standardantwort „Diese Seite existiert nicht“. Da die Seite einen 404-Status zurückgab, hat Google sie nicht indexiert.

Der Teil, der überrascht: Google sagt, es habe diese URL ohne eine explizite Anfrage von Ihnen gefunden. Das beschreibt, wie Google sie entdeckt hat – normalerweise an einer der beiden folgenden Stellen – keine Garantie, dass sie in Ihrer aktuellen Sitemap fehlt. Wenn dieselbe URL noch in einer Sitemap steht, die Sie einreichen, ist das ein separates, behebbares Problem (ein veralteter Sitemap-Eintrag), kein Widerspruch zu dem, was der Bericht Ihnen mitteilt:

• Ein Link. Etwas im Web verlinkt auf diese URL – eine Ihrer eigenen Seiten oder eine Seite auf einer anderen Website – und Google ist dem Link gefolgt.
• Eine Seite, die früher existierte. Die URL war früher live und indexiert, dann haben Sie sie gelöscht oder die URL geändert. Google erinnert sich noch daran und prüft sie erneut.

Schaden 404er meinem SEO?

Das ist die Frage, die wirklich alle beantwortet haben wollen, also hier vorweg: Nein, nicht automatisch. 404er sind ein normaler Teil der Funktionsweise des Webs. Seiten werden entfernt, URLs ändern sich, und andere Websites verlinken gelegentlich auf Adressen, die nie existiert haben. Eine Seite, die einen 404 zurückgibt, wenn sie wirklich weg ist, ist das korrekte Verhalten – Googles eigene Dokumentation sagt, dass 4xx-Antworten außer 429 die Crawl-Rate Ihrer Website nicht beeinflussen, und ein korrekter 404 ist keine Strafe für den Rest Ihrer Website.

Dieses „korrekt“ gilt jedoch nur für URLs, die tatsächlich verschwinden sollen. Ein 404 auf einer Seite, auf die Sie noch verlinken, die in Ihrer Sitemap steht oder auf die andere Websites noch verlinken, ist nicht harmlos, nur weil er technisch gültig ist – es ist ein toter Link, verlorene Link-Equity oder ein Besucher, der in einer Sackgasse landet. Für wirklich tote Seiten, auf die nichts verweist, ist „Not found (404)“ in Ihrem Bericht also kein Grund zur Panik. Für den Rest lohnt sich ein Blick – siehe nächster Abschnitt.

Wann ein 404 wirklich behoben werden sollte

Die 404er, die Ihre Aufmerksamkeit verdienen, sind die für URLs, die funktionieren sollten:

• Eine Seite, auf die Sie weiterhin aus Ihrer eigenen Navigation oder Ihrem Inhalt verlinken (ein toter interner Link).
• Eine URL, die in Ihrer Sitemap steht (das sollte sie nicht – Sitemaps sind für live, indexierbare Seiten).
• Eine Seite, auf die andere Websites verlinken (Sie würden diese Links verschwenden).
• Eine URL, die weiterhin Traffic erhält oder die Leute offensichtlich erreichen wollten.

Dafür haben Sie zwei gute Optionen:

1. Bringen Sie die Seite zurück, wenn sie versehentlich gelöscht wurde.
2. Leiten Sie sie weiter auf die relevanteste Live-Seite (eine 301-Weiterleitung). Das führt Besucher zu etwas Nützlichem und, wichtig, gibt den Wert aller Links auf die alte URL weiter.

Eine Sache, die Sie nicht tun sollten: Leiten Sie nicht jede tote URL auf Ihre Startseite weiter. Google behandelt eine solche irrelevante Weiterleitung als „Soft 404“ – das ist ein eigenes Problem. Leiten Sie auf eine tatsächlich verwandte Seite weiter oder lassen Sie es einfach bei 404.

Möchten Sie die vollständige Version – 404 vs. 410 vs. 301 vs. noindex, wie Sie herausfinden, was auf eine 404 verlinkt, und wie lange diese im Bericht verbleiben? Wechseln Sie zur Registerkarte Erweitert.

TL;DR – „Not found (404)“ bedeutet, dass Googlebot eine URL angefordert hat, die Google als selbst entdeckt beschreibt – über einen Link oder eine zuvor indexierte Seite – nicht durch eine explizite Anfrage von Ihnen, und eine 404 erhalten hat, sodass sie nicht indexiert ist. Diese Beschreibung erklärt die ursprüngliche Entdeckung, nicht den Beweis, dass die URL nicht in Ihrer aktuellen Sitemap enthalten ist. 404s sind ein normaler Teil des Webs, und Googles eigene Dokumentation besagt, dass 4xx-Antworten außer 429 die Crawl-Rate nicht beeinflussen; eine 404 für eine entfernte Seite ohne Ersatz ist korrekt und keine seitenweite Strafe – aber eine 404 auf einer URL, die existieren sollte (intern verlinkt, in einer Sitemap, mit Backlinks oder mit Traffic), kostet Sie dennoch defekte Links, verlorene Equity oder verlorene Nutzer. Für diese: Stellen Sie die Seite wieder her oder leiten Sie sie per 301 auf eine wirklich relevante Live-Seite weiter – priorisieren Sie diejenigen mit eingehenden Links, um Equity zurückzugewinnen. Lassen Sie den Rest als 404. Meiner eigenen Erfahrung nach fällt 410 tendenziell etwas schneller, obwohl Google 4xx-Codes außer 429 gleich behandelt. Leiten Sie nicht massenhaft auf die Startseite weiter (Soft-404-Risiko). Googlebot überprüft alte 404s weiterhin mit abnehmender Häufigkeit, weshalb sie im Bericht verbleiben – das ist normal, keine Strafe.

Was Google Ihnen tatsächlich mitteilt

Der Bericht stellt die beobachtete 404 fest; er erklärt nicht von sich aus, welcher Link, welche historische URL oder welche Anwendungsroute sie verursacht hat. Evidence for this claim Google reports Not found 404 when the page returned a 404 response when requested. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Googles allgemeine 4xx-Dokumentation beschreibt das Indexierungsverhalten. Evidence for this claim Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Googles Definition dieses Status ist kurz: „Diese Seite hat beim Anfordern einen 404-Fehler zurückgegeben.“ Der umgebende Kontext ist der Teil, der zählt – Google hat die URL ohne explizite Anfrage oder Sitemap von Ihnen entdeckt. Das unterscheidet „Not found (404)“ von den Indexierungsfehlern, die Sie selbst eingereicht haben.

Dieser Satz beschreibt, wie Google die URL ursprünglich gefunden hat – er ist keine Behauptung, dass die URL nie in einer Ihrer Sitemaps aufgetaucht ist oder sich nicht derzeit darin befindet. Wenn Sie eine Live-Sitemap prüfen und dieselbe URL dort weiterhin aufgeführt ist, ist das ein echtes (und separates) Problem, das es zu beheben gilt – ein veralteter Sitemap-Eintrag – kein Widerspruch zu dem, was der Bericht Ihnen über die Entdeckung mitteilt.

Die URL stammt also aus einer dieser Quellen:

• Ein interner oder externer Link. Google extrahiert Links beim Crawlen. Ein Tippfehler in einem internen Link, ein alter Link auf einer fremden Website oder ein Link in einem Kommentar können Googlebot auf eine URL lenken, die eine 404 zurückgibt.
• Eine zuvor indexierte Seite, die Sie gelöscht oder deren URL Sie geändert haben. Google merkt sich URLs, die es gesehen hat, und fordert sie über einen langen Zeitraum erneut an.
• Gescrapete, fehlerhafte oder erfundene URLs. Andere Websites verunstalten manchmal Ihre URLs, hängen Müll an oder erfinden Pfade. Google kann sie ausprobieren. Keiner dieser Fälle ist Ihre Schuld, und keiner erfordert Maßnahmen.

Der letzte Punkt ist wichtig zu verinnerlichen: Eine 404 in diesem Bericht zu finden, bedeutet nicht, dass Sie etwas falsch gemacht haben. Google entdeckt URLs aus dem gesamten Web.

Schadet „Not found (404)“ dem SEO? (zuerst das Urteil)

Nein – nicht automatisch, und das ist das größte Missverständnis über den Bericht. 404s sind die Art, wie das Web funktionieren soll, wenn Inhalte verschwunden sind, und Googles eigene Crawl-Dokumentation besagt, dass 4xx-Statuscodes außer 429 keinen Einfluss auf die Crawl-Rate einer Website haben. Eine korrekt zurückgegebene 404 auf einer wirklich entfernten Seite ist keine seitenweite Strafe.

Das ist jedoch eine engere Aussage als „404s sind nie wichtig“. Eine 404 zieht den Rest Ihrer Website nicht von selbst nach unten, aber eine 404 auf einer URL, die funktionieren sollte – mit internen Links, externen Backlinks oder echtem Traffic – kostet Sie dennoch etwas Konkretes: einen defekten Link, verlorene Link-Equity oder einen Besucher, der in einer Sackgasse landet. Der Bericht selbst ist nicht das Problem; die 404s, die nicht existieren sollten, unkorrigiert zu lassen, ist es.

Das entspricht auch meiner eigenen Auffassung von HTTP-Statuscodes im Allgemeinen: 4xx-Antworten führen dazu, dass die betreffende Seite aus dem Index fällt, aber das ist ein sauberes Verschwinden der Seite – keine Strafe für Ihre Domain. Die Seite, die einen 404 liefert, ist einfach nicht mehr im Index; alles andere bleibt unberührt.

Auch in Googles eigenen Hilfedokumenten wird dieser Punkt zum Indexieren im Allgemeinen gemacht: Es ist in Ordnung, wenn eine URL aus den richtigen Gründen nicht indexiert wird, und “a 404 for a page that you’ve removed and have no replacement for” ist ausdrücklich einer dieser richtigen Gründe. Ein 404 auf einer wirklich toten Seite ist der korrekte Endzustand, keine offene Aufgabe.

Was Google intern mit einem 404 macht

Aus Googles HTTP-Status-Dokumentation geht hervor, dass die Mechanik klar ist: Bei einer zuvor indexierten URL entfernt die Indexierungs-Pipeline sie aus dem Index. Neu entdeckte 404s werden einfach nicht verarbeitet – es gibt nichts zu indexieren. Und Googlebot vergisst die URL nicht sofort: Er fragt sie weiterhin erneut ab, wobei die Crawling-Häufigkeit im Laufe der Zeit allmählich abnimmt.

Dieses erneute Überprüfen ist der Grund, warum alte 404s noch lange nach der Bearbeitung in Ihrem Bericht auftauchen. Google bestätigt regelmäßig, dass die Seite weiterhin nicht existiert, falls sie zurückkommt. Das ist kein Zeichen für ein Problem und verschwendet bei einer normal großen Website kein nennenswertes Crawl-Budget.

Wann ein 404 behoben werden sollte – und wann nicht

Die Entscheidungsregel ist einfach: Beheben Sie den 404 nur, wenn die URL existieren sollte. Die Anzeichen dafür, dass eine URL “existieren sollte”:

• Sie verlinken intern darauf (ein defekter Link in Navigation, Inhalt oder Footer).
• Sie steht in Ihrer Sitemap (das sollte sie nicht – Sitemaps sollten nur Live- und indexierbare URLs auflisten).
• Es gibt externe Backlinks, die darauf zeigen.
• Sie erhält weiterhin Traffic oder entspricht eindeutig dem, wonach Menschen suchen.

Wenn keines dieser Kriterien zutrifft – die Seite ist wirklich weg und nichts Wertvolles zeigt darauf – lassen Sie sie als 404 bestehen. Das ist die korrekte Antwort, und es gibt nichts zu tun.

So beheben Sie die, die wichtig sind

Für URLs, die auflösbar sein sollten, haben Sie eine kurze Auswahl:

• Stellen Sie die Seite wieder her, wenn sie versehentlich entfernt wurde oder Sie gleichwertigen Inhalt zum Zurücksetzen haben.
• Leiten Sie sie per 301 auf die relevanteste Live-Seite weiter. Das ist der übliche Schritt für eine entfernte Seite mit sinnvollem Ersatz. Wie ich bereits zu Seiten mit 4xx-Status gesagt habe: In den meisten Fällen müssen Sie jede dieser URLs nur per 301 auf eine relevante Seite weiterleiten. Die Weiterleitung führt Nutzer zu etwas Nützlichem und überträgt den Ranking-Wert aller Links auf die neue URL.
• Lassen Sie sie als 404 (oder verwenden Sie 410), wenn die Seite wirklich weg ist und keinen guten Ersatz hat. Das ist kein Fehler – es ist die richtige Antwort.

Priorisieren Sie nach eingehenden Links. Die wertvollsten 404s sind die mit externen Backlinks, denn eine tote URL mit Links verliert Equity, die Sie mit einer einzigen Weiterleitung auf eine relevante Seite zurückgewinnen könnten. Ziehen Sie die 404-URLs mit Backlinks heraus (ein Backlink-Tool oder Ihr Link-Bericht zeigt diese), und leiten Sie diese zuerst per 301 weiter. Ein 404 ohne Links und ohne Traffic kann einfach ein 404 bleiben – eine Weiterleitung bringt nichts.

Leiten Sie nicht alles auf die Startseite weiter. Eine Weiterleitung auf eine unzusammenhängende Seite – klassischerweise das Ablegen jeder toten URL auf / – wird von Google als Soft-404 behandelt, weil das Ziel kein echter Ersatz für das Angeforderte ist. Leiten Sie auf eine relevante Seite weiter oder leiten Sie gar nicht weiter.

404 vs. 410 vs. 301 vs. noindex

Diese werden ständig verwechselt. Die vollständige Entscheidungstabelle finden Sie im Tab Kurzübersichten; die Kurzfassung:

• 404 (Not Found) / 410 (Gone) — die Seite existiert nicht. Beide entfernen die URL aus dem Index, und Googles eigene Dokumentation sagt, dass es 4xx-Statuscodes (außer 429) gleich behandelt. Meiner praktischen Erfahrung nach verschwindet 410 tendenziell etwas schneller, aber der Unterschied ist in beiden Fällen minimal. Verwenden Sie 410, wenn Sie signalisieren möchten, “das kommt nie wieder”; 404 ist ansonsten völlig in Ordnung.
• 301 (Moved Permanently) — der Inhalt wurde verschoben; bündeln Sie Signale auf der neuen URL. Das ist das richtige Werkzeug für eine entfernte Seite, die einen relevanten Ersatz hat.
• noindex — die Seite existiert und soll live bleiben, aber Sie möchten sie nicht in der Suche. Anderes Werkzeug für ein anderes Ziel — greifen Sie nicht darauf zurück, wenn die Seite wirklich weg ist.

Was 404 vs. 410 konkret betrifft, war meine eigene Sichtweise, dass 404 und 410 ähnlich behandelt werden — beide entfernen Seiten aus dem Index, und meiner eigenen Erfahrung nach gehen 410 etwas schneller, auch wenn Googles Dokumentation 4xx-Codes (außer 429) identisch behandelt. Machen Sie sich also nicht zu viele Gedanken über die Wahl; nehmen Sie 410 für “für immer weg”, 404 für alles andere, und machen Sie weiter.

So finden Sie heraus, was auf eine 404 verlinkt

Um eine 404 zu beheben (oder zu entscheiden, ob Sie sich darum kümmern sollten), finden Sie heraus, was darauf verweist:

• In der GSC: Öffnen Sie den Status “Nicht gefunden (404)”, klicken Sie auf eine Beispiel-URL und prüfen Sie Verweisende Seite unter Entdeckung. Behandeln Sie dies als einen möglichen Hinweis, nicht als vollständiges Link-Inventar — Google beschreibt es als eine Seite, die es möglicherweise verwendet hat, um die URL zu entdecken, was ein direkter Link, eine übergeordnete Seite, über die der Link gefunden wurde, oder einfach nicht vorhanden sein kann, wenn die Informationen nicht verfügbar sind. Kombinieren Sie es mit den folgenden Methoden, anstatt dort aufzuhören.
• Mit einem Crawler / Site-Audit: Ahrefs Site Audit oder Screaming Frog listet Ihre defekten internen Links auf — die internen 404s, die Sie direkt beheben können, indem Sie den Link bearbeiten.
• Mit einem Backlink-Tool: Prüfen Sie defekte Backlinks, um tote URLs auf Ihrer Website zu finden, auf die externe Seiten verlinken. Das sind Ihre 301-Prioritäten.
• In Server-Logs: die Grundwahrheit dafür, welche URLs angefordert werden und welche Statuscodes sie in großem Umfang zurückgeben.

Validieren Sie die Korrektur und was Sie erwarten können

Sobald Sie die URLs, die existieren sollten, wiederhergestellt oder umgeleitet haben, können Sie im Page Indexing-Bericht auf Korrektur validieren klicken. Es ist optional, nicht erforderlich — Google sagt, dass es eine Korrektur von selbst beim nächsten Crawlen der Seite aufgreifen kann, ob Sie validieren oder nicht. Das Klicken auf “Korrektur validieren” ermöglicht es Ihnen nur, diese Überprüfung zu verfolgen; es kommt nicht mit einer garantierten Zeitleiste oder einer Zusage schnellerer erneuter Verarbeitung. Erwarten Sie nicht, dass die Zahl sofort auf null sinkt, in beiden Fällen: Google crawlt 404s nach einem abnehmenden Zeitplan erneut, sodass selbst korrekt behandelte URLs eine Weile im Bericht verbleiben können. Dieses Verbleiben ist das erneute Prüfverhalten, kein Zeichen dafür, dass die Korrektur nicht gegriffen hat, und es gibt keinen festen Zeitpunkt, an dem Google garantiert, dass es abgeschlossen ist. (Und es gibt keinen Grund, eine 404 zu validieren, die wirklich korrekt ist, nur um zu versuchen, sie aus dem Bericht verschwinden zu lassen — Validierung dient dazu, eine Korrektur zu bestätigen, nicht um eine funktionierende 404 zu verwerfen.)

Für sehr große Websites, die massenhaft unechte 404s erzeugen (Millionen von Junk-URLs durch eine defekte Vorlage oder eine Spider-Falle), wird die Crawl-Effizienz zu einem echten Anliegen, und Sie möchten musterbasierte Korrekturen anstelle von Einzelarbeit — aber für typische Websites sind die Crawl-Budget-Kosten von 404s vernachlässigbar.

Wo dies unter seinen Geschwistern einzuordnen ist

“Nicht gefunden (404)” ist der klare Fall: Der Server hat korrekt “nicht gefunden” gesagt. Seine Nachbarn im Page Indexing-Bericht sind andere Situationen — verwechseln Sie sie nicht. Eine Soft 404 ist eine Nicht gefunden-Meldung, die mit einem 200 (oder einer irrelevanten Weiterleitung) ausgeliefert wird, was Google separat kennzeichnet. Blockiert wegen anderem 4xx-Problem deckt 401/403 und den Rest der 4xx-Familie ab. Weiterleitungsfehler ist eine defekte Weiterleitung, zu unterscheiden von der normalen “Seite mit Weiterleitung”. Und Serverfehler (5xx) bedeutet, dass der Server versagt hat, nicht dass die Seite weg ist. Die Korrekturen unterscheiden sich, also identifizieren Sie zuerst, welchen Status Sie tatsächlich betrachten.

Für den gesamten Bericht siehe den GSC Page Indexing-Hub; für die zugrunde liegenden Mechanismen, wie Bots URLs überhaupt anfordern, siehe Crawling.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Was es bedeutet: Googlebot hat eine URL angefordert, die Google als von selbst entdeckt beschreibt – einen Link oder eine zuvor indexierte Seite – nicht durch eine explizite Anfrage von Ihnen, und erhielt einen HTTP-404, sodass die Seite nicht indexiert ist. Googles Definition: “This page returned a 404 error when requested.” Das ist eine Beschreibung der Entdeckung, kein Beweis dafür, dass die URL in Ihrer aktuellen Sitemap fehlt – eine URL, die dort noch aufgeführt ist, ist ein separates Problem, das es zu beheben gilt.
• Woher die URL stammt: interne/externe Links, von Ihnen gelöschte oder umbenannte Seiten oder gescrapte/fehlerhafte/erfundene URLs von anderswo. Ein 404 hier zu finden bedeutet nicht, dass Sie etwas falsch gemacht haben.
• SEO-Auswirkung: nicht automatisch. Googles eigene Dokumentation sagt, dass 4xx-Status außer 429 die Crawl-Rate nicht beeinflussen, und ein korrekt zurückgegebener 404 für eine entfernte Seite ohne Ersatz ist keine seitenweite Strafe. Aber ein 404 auf einer URL, die funktionieren sollte – verlinkt, in einer Sitemap, mit Backlinks oder mit Traffic – kostet dennoch tote Links, verlorene Equity oder verlorene Nutzer.
• Was Google tut: entfernt eine zuvor indexierte URL aus dem Index; verarbeitet neu gefundene 404s nicht; überprüft die URL weiterhin mit abnehmender Häufigkeit – weshalb alte 404s im Bericht verbleiben (normal, keine Strafe).
• Wann zu beheben: nur URLs, die existieren sollten – intern verlinkt, in einer Sitemap, mit Backlinks oder mit Traffic.
• Wie zu beheben: Seite wiederherstellen oder per 301 auf eine wirklich relevante Live-Seite umleiten. Priorisieren Sie 404s mit eingehenden Links, um Equity zurückzugewinnen. Lassen Sie wirklich entfernte Seiten als 404 (oder 410, das Google in seiner eigenen Dokumentation wie 404 behandelt, obwohl es in der Praxis tendenziell etwas schneller fällt).
• Nicht: alles massenhaft auf die Startseite umleiten – irrelevante Weiterleitungen werden als Soft 404s behandelt.
• 404 vs. 410 vs. 301 vs. noindex: 404/410 = entfernt (beide fallen aus dem Index); 301 = verschoben (auf einen Ersatz konsolidieren); noindex = Seite live lassen, aber aus der Suche ausschließen.
• Links finden über GSC “Referring page” (ein möglicher Hinweis, keine vollständige Linkliste), einen Crawler (kaputte interne Links), ein Backlink-Tool (kaputte Backlinks) oder Server-Logs. Validate Fix ist optional – Google kann eine Korrektur auch ohne erkennen, und keiner der Wege hat eine garantierte Zeitspanne.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• Page indexing report – der Bericht, in dem dieser Status lebt, einschließlich der Definition von “Not found (404)” und der Anleitung, dass es in Ordnung ist, wenn eine URL aus den richtigen Gründen nicht indexiert ist.
• HTTP status codes, network errors, and DNS errors – wie Google mit 4xx umgeht: Entfernen zuvor indexierter URLs, Nichtverarbeiten neu gefundener 404s und die allmählich abnehmende Crawl-Häufigkeit.
• Redirects and Google Search – wie Sie die 301-Weiterleitungen einrichten, mit denen Sie die 404s, die existieren sollten, an relevante Live-Seiten senden.
• How to remove a page from search (block indexing) – wenn Sie eine Live-Seite aus der Suche ausschließen möchten (noindex), was ein anderes Ziel als ein 404 ist.

Bing / Microsoft

• Bing Webmaster Tools — Site Explorer & URL inspection – Bings Crawl-Informationen zeigen 404s auf dieselbe Weise; die Handhabungsanleitung stimmt mit Googles überein (die wichtigen beheben, echte tote Seiten als 404 belassen).

Zitate aus der Quelle

Aussagen von Google, die für die Aufzeichnung bestimmt sind. Jeder Link ist ein Deep-Link, der direkt zur zitierten Passage auf der Quellseite springt.

Google – die Definition von “Not found (404)”

• “This page returned a 404 error when requested.” — Google Search Console-Hilfe, Bericht zur Seitenindexierung. (Übersetzung) „Diese Seite hat bei der Anfrage einen 404-Fehler zurückgegeben.“ Zum Zitat springen

Google – es ist in Ordnung, wenn eine URL nicht indexiert wird

• “It’s fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you’ve removed and have no replacement for.” — Google Search Console-Hilfe, Bericht zur Seitenindexierung. (Übersetzung) „Es ist in Ordnung, wenn eine URL aus den richtigen Gründen nicht indexiert wird – zum Beispiel eine erwartete robots.txt-Regel auf Ihrer Website, ein noindex-Tag auf der Seite, eine doppelte URL oder ein 404 für eine Seite, die Sie entfernt haben und für die es keinen Ersatz gibt.“ Zum Zitat springen

Google – wie 4xx bei der Indexierung behandelt wird

• “In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed.” — Google Search Central, Dokumentation zu HTTP-Statuscodes. (Übersetzung) „Im Fall der Google-Suche entfernt die Indexierungs-Pipeline die URL aus dem Index, wenn sie zuvor indexiert war. Neu entdeckte 404-Seiten werden nicht verarbeitet.“ Zum Zitat springen
• “The crawling frequency gradually decreases.” — Google Search Central, Dokumentation zu HTTP-Statuscodes. (Übersetzung) „Die Crawling-Häufigkeit nimmt allmählich ab.“ Zum Zitat springen

Die mentalen Modelle

1. Entdeckt ≠ eingereicht. „Nicht gefunden (404)“ bedeutet konkret, dass Google die URL selbst gefunden hat – über einen Link, eine zuvor indexierte Seite oder eine verstümmelte URL von einer anderen Website – nicht über Ihre Sitemap. Die erste Frage ist also nicht „Wie behebe ich das?“, sondern „Sollte diese URL überhaupt existieren?“

2. 404 ist die richtige Antwort für eine tote Seite. Ein 404 ist kein Fehler, den es zu beseitigen gilt; es ist die richtige HTTP-Antwort, wenn Inhalte entfernt wurden. Es ist kein Qualitätssignal und kein Ranking-Signal. Das Ziel ist Genauigkeit – URLs sollten das zurückgeben, was tatsächlich zutrifft – nicht eine Null im Bericht.

3. Beheben Sie nur, was existieren sollte. Prüfen Sie jeden 404 mit einem Test: Ist er intern verlinkt, in einer Sitemap, durch externe Links gestützt oder erhält er weiterhin Traffic? Ja → Wiederherstellen oder per 301 auf eine relevante Seite umleiten. Nein → Als 404 belassen. Diese eine Regel löst den Großteil des Berichts.

4. Gewinnen Sie Equity zurück, bevor Sie URLs zurückgewinnen. Unter den 404s, die es zu beheben lohnt, haben die mit eingehenden externen Links Vorrang – ein 301 auf eine relevante Seite holt diesen Linkwert zurück. Ein 404 ohne Links und ohne Traffic kann getrost belassen werden; eine Weiterleitung bringt Ihnen nichts.

5. Relevante Weiterleitung oder keine Weiterleitung. Ein 301 hilft nur, wenn er auf eine tatsächlich verwandte Seite führt. Eine irrelevante Weiterleitung (alles → Startseite) wird als Soft 404 behandelt. Wenn es kein gutes Ziel gibt, ist es richtig, den 404 zu behalten, statt eines zu erfinden.

Ihre „Nicht gefunden (404)“-Liste priorisieren

Arbeiten Sie den Bericht von oben nach unten ab:

• Öffnen Sie den Status „Nicht gefunden (404)“ im Bericht „Seitenindexierung“ und prüfen Sie die Beispiel-URLs.
• Klicken Sie für jede URL hinein und prüfen Sie unter „Discovery“ die verweisende Seite – ein möglicher Hinweis darauf, wo Google den Link gefunden hat, aber keine garantierte vollständige Auflistung.
• Markieren Sie jede URL, die intern verlinkt ist – beheben Sie den defekten internen Link an der Quelle (das ist der sauberste Gewinn).
• Markieren Sie jede URL, die in Ihrer Sitemap steht – sie sollte dort nicht stehen; entfernen Sie sie oder stellen Sie die Seite wieder her.
• Ziehen Sie die 404-URLs mit externen Backlinks (Bericht zu defekten Backlinks) heraus – das sind Ihre 301-Prioritäten, um Linkkraft zurückzugewinnen.
• Prüfen Sie, welche 404er weiterhin Traffic erhalten oder klar der Nutzerabsicht entsprechen.
• Für jede URL, die „existieren sollte“: Stellen Sie die Seite wieder her oder leiten Sie sie per 301 auf eine wirklich relevante Live-Seite weiter (nicht auf die Startseite).
• Lassen Sie wirklich entfernte URLs ohne Links/Traffic als 404 bestehen (oder 410, wenn Sie ein etwas schnelleres Verschwinden wünschen).
• Bestätigen Sie, dass keine Live-Weiterleitungen unzusammenhängende URLs auf / werfen (Soft-404-Risiko).
• Optional: Klicken Sie auf „Korrektur validieren“ (Google kann eine echte Korrektur auch selbst erkennen) – erwarten Sie dann einen langsamen Rückgang, nicht sofort null, ohne festen Zeitrahmen.
• Bestätigen Sie, dass Sie den richtigen Status prüfen (nicht Soft-404, andere 4xx, Weiterleitungsfehler oder 5xx – die Korrekturen unterscheiden sich).

Playbook: Reaktion auf einen plötzlichen 404-Anstieg

1. Bestätigen Sie, dass der Anstieg real ist. Vergleichen Sie die Beispiele aus der Search Console mit einem Live-Crawl oder Serverantworten; Berichte können hinter dem aktuellen Verhalten zurückbleiben.
2. Gruppieren Sie nach Ursache und Vorlage. Suchen Sie nach einem Deployment, einer URL-Muster-Änderung, einem Internlink-Bug, einem gelöschten Bereich oder einer fehlerhaften generierten URL, anstatt Zeilen einzeln zu korrigieren.
3. Priorisieren Sie URLs mit Wert. Stellen Sie URLs wieder her oder leiten Sie sie weiter, die existieren sollten, sinnvolle Backlinks oder Traffic haben oder weiterhin in internen Links und Sitemaps auftauchen.
4. Lassen Sie legitime Entfernungen in Ruhe. Eine wirklich entfernte URL ohne Ersatz sollte weiterhin 404 oder 410 zurückgeben; leiten Sie sie nicht auf eine irrelevante Seite weiter.
5. Reparieren Sie die Quelle. Aktualisieren Sie Vorlagen, interne Links und die Sitemap-Generierung, damit sie das defekte Muster nicht weiterhin erzeugen oder fördern.
6. Validieren und beobachten Sie das Wiederauftreten. Testen Sie repräsentative URLs und überwachen Sie das Muster. Beenden Sie, wenn wertvolle URLs korrekt aufgelöst werden und neu entdeckte 404er auf die erwartete Baseline zurückkehren.

404-Spickzettel

Welche Antwort für welche Situation

Sollte ich diesen 404 beheben? – Entscheidungsablauf

Schnelle Fakten

• „Not found (404)“ = Google beschreibt das Auffinden der URL ohne explizite Anfrage von Ihnen – so wurde sie entdeckt, nicht als Beweis, dass sie in Ihrer aktuellen Sitemap fehlt.
• Ein korrekt zurückgegebener 404 ist nicht automatisch eine seitenweite Qualitäts- oder Ranking-Strafe – aber ein 404 auf einer URL, die funktionieren sollte, kostet trotzdem Links, Traffic oder Nutzer.
• Google entfernt eine zuvor indexierte URL bei 404; verarbeitet keine neuen 404s.
• Googlebot überprüft alte 404s weiterhin mit abnehmender Häufigkeit → sie bleiben bestehen.
• 404 vs. 410: Googles Dokumentation behandelt 4xx-Codes (außer 429) gleich; in der Praxis fallen 410s etwas schneller ab.
• Nicht alles auf die Startseite umleiten → Soft 404.
• Die Crawl-Budget-Kosten von 404s sind vernachlässigbar, außer bei sehr großen Websites mit massenhaft ungültigen URLs.

Häufige Probleme

Die 404-Anzahl steigt im Page-Indexing-Bericht plötzlich an

Wahrscheinliche Ursache: Eine defekte Vorlage generiert Junk-URLs (schlechte Paginierungsparameter, ein Facetten-Navigationsfehler, Session-IDs, die in Links auslaufen), eine Spider-Falle oder eine andere Website scraped und verstümmelt Ihre URLs. Lösung: Ziehen Sie eine Stichprobe der neuen 404-URLs und suchen Sie nach einem gemeinsamen Muster (ein Query-Parameter, ein Pfad-Präfix). Wenn es Ihre eigene Vorlage ist, beheben Sie den Code, der die fehlerhaften Links generiert. Überprüfen Sie über Server-Logs oder /tools/log-file-analyzer, um das Muster zu bestätigen und zu sehen, ob es echtes Crawl-Volumen oder nur eine Handvoll Beispiele ist.

Sie haben eine URL behoben, aber sie zeigt Wochen später immer noch „Not found (404)“

Wahrscheinliche Ursache: Googlebot überprüft 404s nach einem abklingenden Zeitplan, daher hinkt die Berichtszahl der tatsächlichen Behebung hinterher – das ist erwartbar, kein Zeichen dafür, dass die Behebung fehlgeschlagen ist. Lösung: Bestätigen Sie, dass die Live-URL jetzt tatsächlich den richtigen Status zurückgibt (200, wenn wiederhergestellt, 301, wenn umgeleitet) mit curl -I oder /tools/http-status-checker. Sie können optional Validate Fix in GSC verwenden – es ist nicht erforderlich, da Google eine Korrektur auch selbst aufnehmen kann – und erwarten Sie, dass die Zahl allmählich abnimmt, statt sofort zu fallen, ohne festen Zeitplan, wann sie sich klärt.

Eine entfernte URL erscheint als „soft 404“ statt „Not found (404)“

Wahrscheinliche Ursache: Die Seite gibt HTTP 200 mit einer „Not found“-ähnlichen Nachricht zurück, statt eines echten 404/410-Status, oder sie leitet auf eine irrelevante Seite um. Lösung: Überprüfen Sie den Antwortcode mit curl -I oder /tools/http-status-checker – wenn es 200 ist, konfigurieren Sie den Server (oder das CMS), um für diesen Pfad einen echten 404/410 zurückzugeben, statt einer Soft-Fehler-Seite.

Ein von Ihnen eingerichteter 301 zeigt als „soft 404“ für das Ziel

Wahrscheinliche Ursache: Die Zielseite ist kein echter Ersatz für das, was angefordert wurde – Google liest ein nicht passendes Redirect-Ziel genauso wie ein irrelevantes. Lösung: Überprüfen Sie das Ziel erneut mit /tools/redirect-checker und richten Sie den 301 auf eine Seite, die tatsächlich zum Thema der ursprünglichen URL passt, nicht auf die nächste Kategorieseite oder die Startseite.

Der Bericht listet eine URL, die Sie nie erstellt oder verlinkt haben

Wahrscheinliche Ursache: Eine gescrapte, fehlerhafte oder erfundene URL von einer anderen Website oder eine Seite von vor Jahren, die Google noch in Erinnerung hat und regelmäßig erneut überprüft. Lösung: Klicken Sie auf die URL im Bericht und prüfen Sie Referring page unter Discovery – ein möglicher Hinweis, keine garantierte Quelle, da Google diese Daten möglicherweise nicht verfügbar hat. Wenn sie extern und eindeutig verstümmelt ist, ist keine Aktion erforderlich – es ist nichts, was Sie kaputt gemacht haben.

Skripte und Snippets

Live-Status einer URL prüfen (macOS/Linux)

Bestätigen Sie, welchen Statuscode eine URL tatsächlich zurückgibt, bevor Sie entscheiden, ob sie behoben werden muss:

curl -I https://example.com/old-page

Schauen Sie sich die erste Zeile der Antwort an (z. B. HTTP/2 404 oder HTTP/2 301). Wenn es eine Weiterleitung ist, zeigt curl den location:-Header mit dem Ziel.

Live-Status einer URL prüfen (PowerShell)

$response = Invoke-WebRequest -Uri "https://example.com/old-page" -Method Head -UseBasicParsing
$response.StatusCode

Fügen Sie -MaximumRedirection 0 hinzu, wenn Sie den rohen 301/302 sehen möchten, ohne dass PowerShell ihn automatisch verfolgt.

Server-Logs nach 404-Treffern durchsuchen (Regex)

Führen Sie dies gegen ein Apache/Nginx-„combined“-Format-Zugriffslog aus, um jede Anfrage zu ziehen, die einen 404 zurückgab:

grep -oP '"\S+ \K\S+(?=.*" 404 )' access.log

Aufschlüsselung der Erfassungsgruppe: "\S+ \K überspringt die HTTP-Methode (GET/POST) und verwirft sie aus dem Treffer; \S+ erfasst den angeforderten Pfad; der Lookahead (?=.*" 404 ) verlangt, dass der Rest der Logzeile einen Status 404 enthält, bevor ein Treffer erzielt wird. Die Ausgabe ist eine einfache Liste der URLs, die 404 zurückgegeben haben – leiten Sie sie durch sort | uniq -c | sort -rn, um sie nach Häufigkeit zu ordnen.

DevTools-Konsole – Status prüfen, ohne die Seite zu verlassen

Fügen Sie dies in das Konsolenfeld ein, um den Status einer bestimmten URL aus dem Browser zu prüfen, in dem Sie sich bereits befinden:

fetch("https://example.com/old-page", {method: "HEAD"}).then(r => console.log(r.status, r.url));

Bookmarklet – Status der aktuellen Seite prüfen

Ziehen Sie dies in Ihre Lesezeichenleiste (es ist ein Bookmarklet – klicken Sie es auf einer beliebigen Seite an, um den Antwortstatus dieser Seite zu prüfen):

javascript:(function(){fetch(location.href,{method:"HEAD"}).then(function(r){alert(r.status+" "+r.url);});})();

Tools zum Finden und Beheben von 404-Fehlern

Tools dieser Website

• /tools/http-status-checker – prüfen Sie den Live-HTTP-Status einer beliebigen URL, bevor Sie entscheiden, ob sie eine Weiterleitung, eine Wiederherstellung oder gar nichts benötigt.
• /tools/redirect-checker – bestätigen Sie, dass eine von Ihnen eingerichtete 301 tatsächlich in einem einzigen Sprung zum gewünschten Ziel auflöst, ohne Ketten oder Schleifen.
• /tools/log-file-analyzer – analysieren Sie Server-Logs, um die tatsächlichen URLs zu sehen, die Googlebot aufruft und die 404 zurückgeben, sowie deren Häufigkeit.
• /tools/site-audit-lite – crawlen Sie Ihre eigene Website, um defekte interne Links aufzudecken (die 404-Fehler, die Sie direkt beheben können, indem Sie den Link an der Quelle bearbeiten).

Tools von Drittanbietern

• Google Search Console – der Page-Indexing-Bericht selbst; öffnen Sie ein Beispiel für „Nicht gefunden (404)“ und verwenden Sie die Ansicht Verweisende Seiten, um zu sehen, was darauf verlinkt hat, und Korrektur validieren, sobald Sie eine Änderung vorgenommen haben.
• Bing Webmaster Tools – die entsprechende Oberfläche für Crawl-Fehler bei Bing.
• Ahrefs oder Screaming Frog – Website-weite Crawls, die defekte interne Links auflisten, sowie Backlink-Berichte, die defekte Backlinks aufdecken (externe Websites, die auf eine tote URL auf Ihrer Website verlinken) – Ihre Prioritätenliste für 301-Weiterleitungen.

Validieren einer 404-Korrektur

Führen Sie diese Schritte nach dem Wiederherstellen oder Weiterleiten einer URL aus, die existieren sollte, um zu bestätigen, dass die Korrektur tatsächlich wirksam wurde, anstatt nur anzunehmen, dass sie es tat.

Live-Statusprüfung der korrigierten URL

Durchzuführender Test: curl -I auf die URL oder /tools/http-status-checker. Erwartetes Ergebnis: 200, wenn Sie die Seite wiederhergestellt haben, oder eine 301 zum richtigen Ziel, wenn Sie sie weitergeleitet haben. Fehlerinterpretation: weiterhin 404, ein 5xx oder eine Weiterleitung, die auf die falsche Seite zeigt, bedeutet, dass die Korrektur nicht tatsächlich bereitgestellt wurde. Überwachungsfenster: sofort. Rollback-Auslöser: falscher Status oder falsches Ziel – korrigieren Sie die Serverregel und prüfen Sie erneut, bevor Sie fortfahren.

Prüfung des Weiterleitungspfads

Durchzuführender Test: /tools/redirect-checker auf die alte URL. Erwartetes Ergebnis: eine 301 mit einem einzigen Sprung, die direkt auf der relevanten Live-Seite landet – keine Kette, keine Schleife. Fehlerinterpretation: mehrere Sprünge, eine Schleife oder das Landen auf einer nicht verwandten Seite (Soft-404-Risiko). Überwachungsfenster: sofort. Rollback-Auslöser: jede Kette, Schleife oder irrelevante Zielseite – korrigieren Sie die Weiterleitungsregel.

GSC-Korrektur validieren

Durchzuführender Test: Öffnen Sie im Page-Indexing-Bericht „Nicht gefunden (404)“ und klicken Sie auf Korrektur validieren (optional – Google kann eine echte Korrektur auch ohne dies selbst erkennen). Erwartetes Ergebnis: Der Status wechselt von „Validierung gestartet“ zu „Bestanden“, und die Anzahl der betroffenen URLs nimmt allmählich ab. Fehlerinterpretation: Die Validierung schlägt fehl, oder die Anzahl bewegt sich über einen längeren Zeitraum nicht – prüfen Sie erneut, ob die Live-URL tatsächlich korrigiert ist und ob nichts mehr auf die alte verlinkt. Überwachungsfenster: fortlaufend, ohne festes Abschlussdatum (Google überprüft 404-Fehler nach einem abnehmenden Zeitplan, nicht sofort, und gibt keine garantierte Zeitleiste). Rollback-Auslöser: wiederholter Validierungsfehler – verifizieren Sie die Korrektur auf Serverebene erneut.

Crawl-Verhalten in Server-Logs

Durchzuführender Test: /tools/log-file-analyzer für Anfragen an die alte URL. Erwartetes Ergebnis: Die Treffer von Googlebot auf der alten URL nehmen im Laufe der Zeit ab, während Anfragen auf die neue URL verlagert werden. Fehlerinterpretation: Googlebot trifft die alte URL auch lange nach der Änderung weiterhin in unveränderter Rate, was darauf hindeutet, dass es den Redirect nicht erkannt hat (oder dass noch etwas direkt auf die alte URL verlinkt). Überwachungszeitraum: fortlaufend, über einen längeren Zeitraum (die Crawl-Frequenz nimmt laut Googles eigener Dokumentation allmählich ab, ohne festen Zeitplan). Rollback-Auslöser: keine Abnahme nach einem längeren Zeitraum – stellen Sie sicher, dass der Redirect serverseitig ist (kein JS- oder Meta-Refresh-Redirect) und prüfen Sie auf verbleibende interne Links zur alten URL.

Quiz

Fünf Fragen, um zu überprüfen, was tatsächlich hängen bleibt bei „Not found (404).“

Änderungsprotokoll