HTTP-Fehlercodes

TL;DR – HTTP-Fehlercodes sind die „Etwas ist schiefgelaufen“-Antworten, die Ihr Server anstelle eines normalen „200 OK“ sendet. Es gibt zwei Familien: 4xx (die Seite fehlt oder ist blockiert – ein Client-Problem) und 5xx (der Server selbst hat Schwierigkeiten). Google behandelt sie sehr unterschiedlich: Ein 4xx entfernt die Seite lediglich aus der Suche; ein 5xx veranlasst Google, das Crawling Ihrer gesamten Website zu verlangsamen, bis sich der Server erholt. Und trotz der Panik, die sie auslösen, sind 404-Fehler keine Strafe – Sie müssen nur die beheben, die wichtig sind.

Was HTTP-Fehlercodes sind

HTTP-Statuscodes sind standardisierte Antwortmetadaten, die in die Klassen Client-Fehler 4xx und Server-Fehler 5xx gruppiert werden. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes Google dokumentiert unterschiedliche Crawling- und Indexierungsbehandlungen für diese Antwortfamilien. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTP and network errors

Jedes Mal, wenn ein Browser oder ein Suchmaschinen-Bot eine Seite anfordert, antwortet Ihr Server mit einem dreistelligen Statuscode. 200 bedeutet „Hier ist die Seite, alles gut.“ Die Fehlercodes sind die in den 400ern und 500ern – sie bedeuten, dass die Anfrage nicht erfolgreich war.

Es gibt zwei Familien, und der Unterschied zwischen ihnen ist das Wichtigste auf dieser Seite:

• 4xx – Client-Fehler. Das Problem liegt an der Anfrage: Die Seite ist weg (404), sie wurde dauerhaft entfernt (410), oder Sie haben keinen Zutritt (401, 403). Für eine Suchmaschine bedeutet ein 4xx im Grunde „Hier gibt es keinen Inhalt.“
• 5xx – Server-Fehler. Das Problem liegt bei Ihnen: Der Server ist abgestürzt (500), ein System, von dem er abhängt, ist ausgefallen (502, 504), oder er ist überlastet oder in Wartung (503). Für eine Suchmaschine bedeutet ein 5xx „Der Server selbst ist gerade kaputt.“

Wie Google auf jede Familie reagiert

Hier trennen sich die beiden Familien:

• Eine 4xx-Seite wird einfach aus der Suche entfernt. Google entscheidet, dass der Inhalt nicht existiert, und entfernt die URL im Laufe der Zeit aus seinem Index. Wichtig ist, dass eine Reihe von 404ern das Crawling des Rests Ihrer Website durch Google nicht verlangsamt.
• Ein 5xx veranlasst Google, Ihre gesamte Website langsamer zu crawlen. Wenn der Server Fehler meldet, hält sich Google zurück, um die Lage nicht zu verschlimmern. Ihre bereits indexierten Seiten bleiben zunächst im Index – Google beginnt erst dann, sie zu entfernen, wenn die Fehler anhalten. Sobald Ihr Server wieder gesund ist, beschleunigt sich das Crawling von selbst wieder.

Das, was die meisten falsch verstehen

Ein Haufen 404-Fehler ist keine Strafe. Googles John Mueller hat klar gesagt, dass 404er „kein Qualitätssignal, kein SEO-Signal“ sind. Kaputte und fehlende Seiten sind ein normaler Teil des Webs. Wenn Sie also die Search Console öffnen und tausende „Nicht gefunden“-Fehler sehen, geraten Sie nicht in Panik – Sie müssen nur die beheben, die tatsächlich wichtig sind: Seiten, auf die noch verlinkt wird, Seiten in Ihrer Sitemap, Seiten, die Traffic erhalten haben. Die wirklich toten Seiten können einfach 404 bleiben.

Das eine Muster, das tatsächlich einen echten, dokumentierten Nachteil hat, ist ein Server, der weiterhin 5xx-Fehler wirft – in diesem Fall drosselt Google das Crawling und entfernt schließlich Seiten. Auch dann ist es umkehrbar: Beheben Sie den Server, und es erholt sich.

Ein kurzer Überblick über die Codes

Jeder davon hat eine eigene ausführliche Seite – hier die Einzeiler-Version:

• 401 / 403 – die Seite ist blockiert (Sie müssen sich anmelden, oder Sie sind nicht berechtigt).
• 404 – Seite nicht gefunden. 410 – Seite dauerhaft entfernt.
• 429 – „zu viele Anfragen“ (Ratenbegrenzung). Sieht wie ein Client-Fehler aus, aber Google behandelt ihn wie einen Server-Fehler.
• 451 – aus rechtlichen Gründen blockiert (eine Entfernung, eine länderspezifische Sperre).
• 500 / 502 / 503 / 504 – die Server-Fehlerfamilie (Absturz, fehlerhaftes Gateway, nicht verfügbar, Gateway-Timeout).
• Soft 404 – der heimtückische: eine Seite, die „nicht gefunden“ sagt, aber einen 200-Code zurückgibt, sodass Google sie weiterhin prüft.

Möchten Sie die Mechanismen – genau wie Googles Crawl-Rate reagiert, wann Seiten aus dem Index entfernt werden, wie Sie eine Website richtig abschalten und wie Sie all das in der Search Console überwachen? Wechseln Sie zum Erweitert-Tab.

TL;DR — HTTP-Fehlercodes sind die Statusklassen 4xx (Client) und 5xx (Server). Google zieht eine harte Verhaltensgrenze zwischen ihnen: 4xx (außer 429) bedeutet „der Inhalt existiert nicht“ – die URL wird aus dem Index entfernt, mit „keinerlei Auswirkung auf die Crawl-Rate“; 5xx (und 429) bedeutet „der Server fällt aus“ – Google drosselt das Crawling proportional, behält indizierte URLs zunächst bei und entfernt sie nur dann aus dem Index, wenn die Fehler anhalten, und erhöht die Crawl-Rate nach der Erholung allmählich wieder. 429 ist numerisch ein 4xx, aber Google nennt es „einen Serverfehler.“ Inhalte aus jeder Fehlerantwort werden ignoriert. 404er sind kein Qualitätssignal (Mueller) – priorisieren Sie nach Links/Traffic, beheben Sie nicht alles, und denken Sie daran: Die tatsächliche Auswirkung eines isolierten Fehlers hängt von der URL ab (robots.txt hat eine spezielle Fehlerbehandlung, die eine normale Seite nicht hat). Soft 404s (ein 200, der wie „nicht gefunden“ wirkt) werden von Google als Verschwendung des Crawl-Budgets markiert – hauptsächlich ein Problem großer Websites, kein garantierter Effekt auf jede Website. Für geplante Ausfallzeiten verwenden Sie 503 + Retry-After, begrenzt auf „höchstens ein paar Tage“, und niemals 503 für die robots.txt. Überwachen Sie die Familie über den Seitenindexierungs-Bericht in der GSC. Dieser Hub kartiert und leitet zu jedem einzelnen Code weiter.

Die eine Unterscheidung, die das gesamte Thema durchzieht

Der Protokollcode beschreibt das HTTP-Ergebnis; ein Search Console-Label beschreibt, wie Google einen beobachteten Abruf klassifiziert hat. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes Leiten Sie keine einzelne Ursache oder einen genauen Entfernungszeitpunkt allein aus der Familie ab. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTP and network errors

Vier Ebenen werden zu „es ist ein 404“ zusammengefasst, wenn Leute über Fehler sprechen, und sie auseinanderzuhalten ist das, was den Rest dieser Seite verständlich macht:

1. Protokollsematik – was der Statuscode laut HTTP-Spezifikation bedeutet (ein 404 bedeutet „nicht gefunden“, Punkt).
2. Der beobachtete Abruf – was Googlebot tatsächlich bei einer bestimmten Anfrage zu einem bestimmten Zeitpunkt zurückbekommen hat, was sich von dem unterscheiden kann, was ein Browser sieht.
3. Suchverarbeitung – wie die Indexierungspipeline von Google diesen beobachteten Abruf klassifiziert und darauf reagiert (URL verwirft, Crawl drosselt, Inhalt ignoriert).
4. Ursache – der tatsächliche Grund auf Ihrem Server (ein fehlerhaftes Deployment, eine überlastete Datenbank, eine WAF-Regel), den der Statuscode allein Ihnen nie verrät.

Die Kenntnis der Familie (4xx vs. 5xx) sagt Ihnen, auf welcher der ersten drei Ebenen Sie sich befinden. Sie ersetzt niemals Ebene 4 – Sie müssen trotzdem herausfinden, warum.

Die eigenen Dokumente von Google formulieren die Trennung klar: 4xx-Fehler sagen “the content doesn’t exist” (Übersetzung) „Der Inhalt existiert nicht“; 5xx-Fehler sagen “the server itself is failing.” (Übersetzung) „Der Server selbst fällt aus.“ Das sind zwei völlig verschiedene Probleme, und die Indexierungspipeline von Google reagiert auf sie auf zwei völlig verschiedene Arten.

Ein nützlicher Anker zuerst: Selbst ein Erfolgscode ist kein Versprechen. Google sagt unmissverständlich: “for Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” (Übersetzung) „Für die Google-Suche garantiert ein HTTP-2xx (success)-Statuscode keine Indexierung.“ Fehlercodes sind tatsächlich die deterministischere Hälfte des Bildes – sie sagen Google eindeutig entweder „weg“ oder „kaputt“.

Wie Google mit 4xx-Fehlern umgeht

Bei Client-Fehlern ist das Verhalten von Google einheitlich und direkt: „Google verwendet die Inhalte von URLs, die 4xx-Statuscodes zurückgeben, nicht,“ und „Google-Crawler informieren das nächste Verarbeitungssystem, dass der Inhalt nicht existiert.“ Selbst wenn Ihre 403- oder 404-Seite eine Wand aus echtem Text rendert, wird nichts davon indexiert – der Inhalt einer Fehlerantwort wird ignoriert.

Zwei Konsequenzen folgen daraus:

• Zuvor indizierte URLs werden entfernt. Sobald eine Seite zuverlässig einen 4xx zurückgibt, entfernt Google sie im Laufe der Zeit aus dem Index.
• Es gibt keine Crawl-Raten-Strafe. Das ist der Mythos-Buster: „Die 4xx-Statuscodes, außer 429, haben keinerlei Auswirkung auf die Crawl-Rate.“ Ein Berg von 404ern verlangsamt das Crawling des Rests Ihrer Website durch Google nicht.

Dieser letzte Punkt tötet einen schlechten Instinkt: Versuchen Sie nicht, Googlebot mit einem 401 oder 403 zu drosseln. Google warnt ausdrücklich: „Verwenden Sie keine 401- und 403-Statuscodes zur Begrenzung der Crawl-Rate.“ Eine Authentifizierungsmauer verlangsamt das Crawling nicht – sie macht den Inhalt nur unsichtbar.

Wie Google mit 5xx-Fehlern umgeht (und 429)

Serverfehler lösen den Zweig „Der Server hat zu kämpfen“ aus, und hier ist Google bewusst schützend gegenüber Ihrer Website:

• Die Crawl-Rate wird zuerst gedrosselt, proportional zum Volumen. „5xx- und 429-Serverfehler veranlassen die Crawler von Google, das Crawling vorübergehend zu verlangsamen“, und „die Verringerung der Crawl-Rate ist proportional zur Anzahl der einzelnen URLs, die einen Serverfehler zurückgeben.“ Eine Handvoll 500er fällt kaum ins Gewicht; ein websiteweiter Ausfall reduziert das Crawling stark.
• Indizierte URLs bleiben erhalten … bis die Fehler anhalten. „Bereits indizierte URLs bleiben im Index erhalten, werden aber schließlich entfernt“, und Google „entfernt URLs aus dem Index, die dauerhaft einen Serverfehler zurückgeben.“ Ein kurzer Aussetzer führt nicht zur Deindizierung; ein anhaltender Fehler schon.
• Inhalte von 5xx werden ebenfalls ignoriert. „Alle Inhalte, die Google von URLs erhält, die einen 5xx-Statuscode zurückgeben, werden ignoriert.“
• Die Wiederherstellung erfolgt automatisch, aber schrittweise. „Sobald der Server wieder mit einem 2xx-Statuscode antwortet, erhöht Google die Crawl-Rate für die Website schrittweise.“ Google zieht sich schnell zurück und ist beim Hochfahren vorsichtig – es gibt kein manuelles „Entsperren“, Sie beheben einfach die Ursache und warten.

Warum 429 im Serverfehler-Bucket lebt

Dies ist die am häufigsten übersehene Nuance in den meisten Anleitungen. 429 Too Many Requests ist numerisch ein 4xx, aber Google behandelt ihn als Serversignal: „Die Crawler von Google behandeln den Statuscode 429 als Signal, dass der Server überlastet ist, und er gilt als Serverfehler.“ Eine WAF oder ein Rate-Limiter, der beginnt, 429er an Googlebot zu senden, drosselt Ihr Crawling also genauso wie eine Welle von 500ern – nicht einzelne Seiten fallen lassen wie bei einem 404. Wenn ich die Codes in meinem HTTP-Statuscode-Leitfaden bei Ahrefs aufschlüssele, ordne ich 429 aus genau diesem Grund den Serverfehlern zu: Es ist „eine Form des Rate-Limitings zum Schutz des Servers“, und es bringt Google dazu, langsamer zu machen.

Die Fehlercode-Familienkarte

Hier ist die schnelle Triage-Ansicht der gesamten Familie. Jeder Code unten ist ein eigener Deep Dive, der unter diesem Hub verschachtelt ist (sie sind auch in der Seitenleiste):

Blockierte / Zugriffsfehler

• 401 Unauthorized – der Client hat sich nicht identifiziert oder verifiziert, als es nötig war. Für Googlebot hinter einer Authentifizierungsanfrage blockiert.
• 403 Forbidden – der Client ist bekannt, hat aber keine Zugriffsrechte.

Nicht-gefunden-Fehler

• 404 Not Found – die angeforderte Ressource wird nicht gefunden.
• 404 vs. 410 – der praktische Unterschied zwischen „nicht gefunden“ und „nicht mehr vorhanden“ (er ist kleiner, als man denkt).
• 410 Gone – wie ein 404, sagt aber auch, dass die Ressource nicht zurückkommt. Entfernt Seiten geringfügig schneller.

Der Code mit doppelter Identität

• 429 Too Many Requests – Rate-Limiting; numerisch 4xx, aber Google behandelt ihn für Crawl-Rate-Zwecke als Serverfehler.

Rechtlich

• 451 – aus rechtlichen Gründen nicht verfügbar – rechtlich blockiert: länderspezifische Sperren und DMCA-Entfernungen.

Serverfehler (5xx)

• 500 – interner Serverfehler – der Server ist auf ein Problem gestoßen, das er nicht bewältigen kann.
• 502 – fehlerhaftes Gateway – eine fehlerhafte Antwort von einem vorgelagerten Server.
• 503 – Dienst nicht verfügbar – der Server ist überlastet oder wegen Wartungsarbeiten nicht verfügbar (der korrekte Code für geplante Ausfallzeiten).
• 504 – Gateway-Zeitüberschreitung – keine rechtzeitige Antwort von einem vorgelagerten Server.

Der Fallstrick

• Soft 404 – eine Seite, die 200 OK zurückgibt, aber wie „nicht gefunden“ wirkt. Das Schlimmste aus beiden Welten – mehr dazu unten.

Fehlerhafte Weiterleitungen grenzen an Fehler, werden aber separat kategorisiert (Google zeigt sie in der Search Console als „Redirect error“ an, abgegrenzt von einer normalen, funktionierenden „Page with redirect“). Standardmäßig folgen die Crawler von Google „bis zu 10 Weiterleitungssprüngen“, bevor sie aufgeben; eine Kette, die zu lang ist, Schleifen enthält oder eine fehlerhafte URL enthält, wird zu diesem Status „Redirect error“.

Schadet ein HTTP-Fehler Ihrem SEO?

Beginnen wir mit dem Urteil: Ein isolierter Fehler auf einer normalen Seite ist fast nie ein Problem, und 404er sind insbesondere kein Ranking- oder Qualitätssignal. Mueller hat sich dazu explizit und wiederholt geäußert. Der Reflex – „Ich habe 50.000 404er, meine Seite muss abgestraft werden“ – ist der Mythos Nummer eins, den es zu entkräften gilt. Fehler sind ein normaler Teil des Webs; Seiten mit 404 oder 410 zu beantworten ist die technisch korrekte Art, mit URLs umzugehen, die nicht existieren.

„Isoliert“ bedeutet jedoch nicht „immer harmlos“ – die tatsächliche Auswirkung hängt davon ab, was den Fehler zurückgibt. Eine normale Seite, die eine 404 zurückgibt, ist ein Nicht-Ereignis; eine spezielle Ressource ist anders. Google hat für robots.txt eigene Fehlerbehandlungsregeln, die sich von regulären URLs unterscheiden. Ein Serverfehler bei robots.txt kann sich also auf das Crawling auswirken, was eine 404 einer normalen Seite nie tun würde. Beurteilen Sie einen Fehler danach, auf welcher URL er auftritt und was davon abhängt, nicht nur anhand des Statuscodes.

Das einzige Muster mit einem echten, dokumentierten Mechanismus ist anhaltendes, massenhaftes 5xx: Drosselung der Crawl-Rate → eventuelle Entfernung aus dem Index. Und selbst das steht im Verhältnis dazu, wie viele URLs Fehler aufweisen, und ist in der Regel umkehrbar, sobald sich der Server erholt – Google beschreibt das Hochfahren als schrittweise, nicht sofort. Behandeln Sie den genauen Zeitpunkt, die Wiederholungsfrequenz und die Erholungsgeschwindigkeit daher als evidenzabhängig (was die Google-Dokumentation beschreibt) und nicht als feste Garantie. Die Unterscheidung, die Mueller trifft, ist die, an die man sich erinnern sollte: Die Crawl-Rate reagiert auf Serverfehler (429/500/503/Timeouts), nicht auf 404er.

Crawl-Verschwendung vs. Entfernung aus dem Index – zwei verschiedene Schäden

Es hilft, die beiden Arten zu trennen, wie Fehler Sie kosten können:

• Entfernung aus dem Index – anhaltende 4xx (Seite als „entfernt“ eingestuft) oder anhaltende 5xx (Seiten nach anhaltendem Serverausfall entfernt). Hier geht es um Seiten, die den Index verlassen.
• Crawl-Budget-Verschwendung – betrifft hauptsächlich große Websites. Der Crawl-Budget-Leitfaden von Google stellt fest: “if the site slows down or responds with server errors, the limit goes down and Google crawls less.” (Übersetzung) „Wenn die Website langsamer wird oder mit Serverfehlern antwortet, sinkt das Limit und Google crawlt weniger.“ Der eigentliche Budget-Verschwender ist jedoch der Soft 404: “soft 404 pages will continue to be crawled, and waste your budget.” (Übersetzung) „Soft-404-Seiten werden weiterhin gecrawlt und verschwenden Ihr Budget.“ Da ein Soft 404 lebendig aussieht (er gibt 200 zurück), überprüft Google eine Seite, die nicht wirklich existiert, immer wieder. Deshalb ist der Soft 404 der Fall „das Schlimmste aus beiden Welten“ – er wird nicht sauber entfernt wie ein echter 404, sondern bleibt bestehen und verbraucht Abrufe.

Die Soft-404-Falle hat zwei häufige Ursachen, die beide genannt werden sollten: eine benutzerdefinierte „Seite nicht gefunden“-Vorlage, die 200 statt einer echten 404 zurückgibt, und eine pauschale Weiterleitung aller toten URLs auf die Startseite – auch dieses Muster erkennt Google als Soft 404 an. Eine freundliche 404-Seite ist gut für die Benutzererfahrung und ausdrücklich zu empfehlen – solange sie weiterhin den tatsächlichen HTTP-Statuscode 404 zurückgibt.

Geplante Ausfallzeiten richtig umsetzen

Wenn Sie eine Website (oder einen Bereich) absichtlich offline nehmen, ist der korrekte Code 503 Service Unavailable mit einem Retry-After-Header – niemals ein 4xx. Die Anleitung von Google zum „Pausieren Ihres Online-Geschäfts“ ist eindeutig:

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (Übersetzung) „Wenn Sie die Website dringend für 1–2 Tage deaktivieren müssen, geben Sie eine informative Fehlerseite mit dem HTTP-Statuscode 503 zurück.“
• Google bezeichnet das als extreme Maßnahme, die nur sehr kurz – höchstens einige Tage – eingesetzt werden sollte. Schon eine vollständige Schließung über wenige Wochen kann die Indexierung durch Google beeinträchtigen.
• “Don’t block the website by returning 403, 404, 410 HTTP status codes” während einer Ausfallzeit – ein 4xx bedeutet „dauerhaft entfernt“ und sendet damit bei einer vorübergehenden Störung das falsche Signal. (Übersetzung) „Blockieren Sie die Website nicht, indem Sie HTTP-Statuscodes 403, 404, 410 zurückgeben“ während einer Ausfallzeit – ein 4xx bedeutet „dauerhaft entfernt“, was genau das falsche Signal für eine vorübergehende Störung ist.
• Die häufig übersehene Falle: Eine 503-Antwort für die robots.txt-Datei blockiert das gesamte Crawling. Antworten Sie auf Seiten mit 503, nicht auf die robots.txt-Datei.

So überwachen Sie die gesamte Familie in der Search Console

Im Alltag begegnen Ihnen diese Fehler im Page-Indexing-Bericht der Search Console, wo jeder einem eigenen Status zugeordnet ist:

• Nicht gefunden (404) – “this page returned a 404 error when requested.” (Übersetzung) „Diese Seite hat bei der Anfrage einen 404-Fehler zurückgegeben.“
• Serverfehler (5xx) – “your server returned a 500-level error when the page was requested.” (Übersetzung) „Ihr Server hat einen Fehler der 500er-Stufe zurückgegeben, als die Seite angefordert wurde.“
• Blockiert wegen nicht autorisierter Anfrage (401) – “the page was blocked to Googlebot by a request for authorization.” (Übersetzung) „Die Seite wurde für Googlebot durch eine Autorisierungsanfrage blockiert.“
• Blockiert wegen verweigertem Zugriff (403) – ein 403, bei dem Anmeldedaten angegeben wurden, der Zugriff aber nicht gewährt wurde.
• Blockiert wegen anderem 4xx-Problem – ein 4xx, der nicht von einem anderen Status abgedeckt wird; verwenden Sie die URL-Inspektion zum Debuggen.
• Soft 404 – eine “user-friendly ‘not found’ message but not a 404 HTTP response code.” (Übersetzung) „benutzerfreundliche ‚Nicht gefunden‘-Meldung, aber kein HTTP-Statuscode 404.“
• Weiterleitungsfehler – zu lange Kette, eine Schleife, eine überlange URL oder eine fehlerhafte URL in der Kette.

Jeder Status weist auf eine andere Ursache und einen anderen Lösungsweg hin. Sobald Sie einen behoben haben, verwenden Sie Fix überprüfen, um ein erneutes Crawling anzustoßen – setzen Sie jedoch realistische Erwartungen an den Zeitrahmen; das erneute Crawling erfolgt nicht sofort. Und denken Sie an Googles eigene Formulierung: “it’s fine for a URL not to be indexed for the right reasons — for example… a 404 for a page that you’ve removed and have no replacement for.” (Übersetzung) „Es ist in Ordnung, wenn eine URL aus den richtigen Gründen nicht indexiert wird – zum Beispiel … ein 404 für eine Seite, die Sie entfernt haben und für die es keinen Ersatz gibt.“ Nicht jeder Fehler ist eine Aufgabe.

Die Search Console allein reicht nicht aus, um darauf zu reagieren – sie ist ein Blickwinkel, der Stichproben und Verzögerungen unterliegt. Wenn Sie einen Fehler zur Priorisierung protokollieren, erfassen Sie mindestens: die URL, wann der Fehler beobachtet wurde, den Blickwinkel (Search Console vs. Live-Check vs. Server-/CDN-Protokolle), den User-Agent, mit dem die Anfrage einging, die HTTP-Methode, den endgültigen Statuscode und Antwortpfad (einschließlich aller Weiterleitungsketten), ob es sich um ein einmaliges oder wiederkehrendes Problem handelt, und einen Schritt zur Überprüfung nach der Behebung, sobald Sie neu bereitgestellt haben. Die Triangulation von GSC mit einem Live-Statuscheck und Ihren eigenen Protokollen ist das, was aus einer veralteten Berichtszeile ein bestätigtes, behebbares Problem macht.

So beheben und priorisieren Sie Fehler

• Priorisieren Sie 404-Fehler nach Wert. Beheben Sie zuerst URLs mit eingehenden oder internen Verweisen, einem Eintrag in der Sitemap oder anhaltender organischer Nutzung. Leiten Sie diese per 301 auf eine relevante Seite weiter, um ihren Verweiswert zurückzugewinnen. Wirklich tote URLs dürfen weiterhin 404 oder 410 zurückgeben. Eine Weiterleitung ist nur sinnvoll, wenn ein inhaltlich passendes Ziel existiert. Leiten Sie deshalb nicht pauschal alles auf die Startseite weiter; dadurch entsteht ein Soft 404.
• 410 vs. 404 ist marginal. Ein 410 entfernt eine Seite geringfügig schneller als ein 404; der praktische SEO-Unterschied ist gering. Verwenden Sie 410, wenn Sie explizit ausdrücken möchten, dass etwas endgültig entfernt wurde, aber erwarten Sie nicht, dass es dramatisch besser ist.
• Beheben Sie die Ursache von 5xx. Die Lösungen liegen auf der Serverseite: Kapazität und Timeouts für 500er, Upstream-/CDN-Gesundheit für 502/504 und WAF- oder Rate-Limiting-Regeln, die bei Googlebot für 403/429 fehlschlagen. Bestätigen Sie den echten Bot mit einem Reverse-/Forward- DNS-Check, bevor Sie ihn per Rate-Limiting einschränken.
• Häufige Ursachen, die es wert sind, genannt zu werden: App- und Datenbankfehler sowie überlastete Hosts (5xx), Upstream-/CDN-Ausfälle (502/504), Rate-Limiting oder Bot-blockierende WAFs (403/429), fehlerhafte Migrationen und veraltete interne Links (404) und falsch konfigurierte „benutzerfreundliche Fehlerseiten“ (Soft 404).

Bing: ein ähnliches Muster, nicht unabhängig Code-für-Code verifiziert

Bings veröffentlichte Hinweise weisen in dieselbe Richtung wie Googles Ansatz — Codes von 400 bis 499 werden als fehlend oder verboten behandelt, und 500er-Codes signalisieren Serverprobleme, die der Abrufeffizienz entgegenwirken — aber ich habe keine unabhängige, vollständige, aktuelle Code-für-Code-Parität mit Bings eigener Dokumentation verifiziert, also behandeln Sie dies als richtungsweisend und nicht als bestätigte Eins-zu-eins-Entsprechung. Fabrice Canel beschreibt Bings Ziel sinngemäß so: Eine URL soll nur dann abgerufen werden, wenn Inhalte hinzugefügt oder aktualisiert wurden. Anhaltende Fehler wirken dem direkt entgegen — Bing investiert Abrufressourcen in URLs, die keinen frischen, indexierbaren Inhalt liefern. Bing empfiehlt außerdem einen 503 mit Retry-After für geplante Ausfallzeiten, anstatt Fehlerseiten als 200 auszuliefern. Die Crawl-Fehler-Oberflächen von Bing finden Sie in Bing Webmaster Tools (URL Inspection, Crawl Control, Site Scan).

Wo es weitergeht

Diese Seite ist das konzeptionelle Zentrum für die Fehlercode-Familie. Sie liegt innerhalb des breiteren HTTP-Statuscodes-Clusters (das vollständige 1xx–5xx-Bild, plus Redirects und Erfolgscodes); dieser Unter-Hub ist die Karte für die Fehler-Hälfte davon. Jeder Code unten ist ein eigener Detailartikel:

Blockiert / Zugriff

• 401 – nicht authentifiziert — was den Status „wegen nicht autorisierter Anfrage blockiert“ auslöst und warum Auth-Wände Googlebot nicht ausbremsen.
• 403 – verboten — Anmeldedaten bereitgestellt, aber Zugriff verweigert, und die WAF-/Bot-Blocking-Muster, die falsche 403er für Googlebot verursachen.

Nicht gefunden

• 404 – nicht gefunden — wie Google mit fehlenden Seiten umgeht, warum es keine Strafe ist und welche 404er Sie tatsächlich beheben sollten.
• 404 vs 410 — der echte, kleine Unterschied und wann Sie welchen verwenden.
• 410 – entfernt — das Signal „dauerhaft entfernt“ und sein etwas schnelleres Verschwinden.

Ratenbegrenzung

• 429 – zu viele Anfragen — der 4xx, der sich wie ein 5xx verhält, und wie Sie verhindern, dass Anfragelimits das Crawling ausbremsen.

Rechtliches

• 451 – aus rechtlichen Gründen nicht verfügbar — Entfernungen, Ländersperren und wie rechtliche Entfernungen angezeigt werden.

Serverfehler

• 500 – interner Serverfehler — der generische Serverfehler und wie Sie die Ursache finden.
• 502 – fehlerhaftes Gateway — Fehler eines vorgelagerten Servers oder Proxys.
• 503 – Dienst nicht verfügbar — der korrekte Code für Wartung und geplante Ausfallzeiten (mit der robots.txt-Falle).
• 504 – Gateway-Zeitüberschreitung — Zeitüberschreitungen bei vorgelagerten Servern.

Der Fallstrick

• Soft 404 — die 200, die wie entfernt wirkt, warum sie Crawl-Budget verschwendet und wie ein Soft 404 in eine echte 404 umgewandelt wird.

Fehlerhafte Weiterleitungen werden separat als Status Weiterleitungsfehler behandelt — verwandt, aber in der Search Console eigenständig kategorisiert.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Zwei Familien, zwei Verhaltensweisen. 4xx = „Inhalt existiert nicht“; 5xx = „der Server fällt aus“. Die Indexierungs-Pipeline von Google reagiert auf jede sehr unterschiedlich.
• 4xx (außer 429): Inhalt wird ignoriert, die URL fällt aus dem Index, und es gibt keine Auswirkung auf die Crawl-Rate. Verwenden Sie 401/403 nicht, um Googlebot zu drosseln – Google sagt dies ausdrücklich.
• 5xx (und 429): Google drosselt zuerst das Crawling (proportional zur Anzahl der fehlerhaften URLs), behält indizierte URLs zunächst bei und entfernt sie nur dann aus dem Index, wenn Fehler bestehen bleiben. Die Wiederherstellung erfolgt automatisch, aber die Crawl-Rate steigt allmählich wieder an.
• 429 ist der Sonderfall: numerisch 4xx, aber Google behandelt ihn für Crawl-Rate-Zwecke als Serverfehler – er verhält sich wie ein 5xx.
• 404 sind kein Qualitäts-/Ranking-Signal (Mueller). Keine Panik bei einer Fehleranzahl; priorisieren Sie nach Verweisen, Sitemap-Präsenz und organischer Nutzung – 301 für die, die wichtig sind, lassen Sie tote Seiten 404/410.
• Die Auswirkung eines isolierten Fehlers hängt von der URL ab, nicht nur vom Statuscode – eine normale Seite, die 404 liefert, ist ein Nicht-Ereignis, aber spezielle Ressourcen wie robots.txt haben ihre eigene Fehlerbehandlung und können das Crawling unterschiedlich beeinflussen.
• Soft 404 ist die Falle: ein 200, das wie „nicht gefunden“ aussieht, das Google als Verschwendung des Crawl-Budgets kennzeichnet, weil es eine Seite, die lebendig aussieht, immer wieder überprüft – hauptsächlich ein Problem großer Websites, nicht ein garantierter Effekt auf jede Website.
• 410 vs. 404 ist marginal – 410 fällt etwas schneller; der praktische Unterschied ist gering.
• Geplante Ausfallzeiten: verwenden Sie 503 + Retry-After, höchstens einige Tage lang, niemals 403/404/410, und niemals 503 für Ihre robots.txt (das blockiert alles Crawling).
• Überwachen Sie über den Seitenindexierungsbericht in der GSC – sieben Status (404, 5xx, 401, 403, andere 4xx, Soft 404, Weiterleitungsfehler) – plus Ihre eigenen Live-Checks und Server-Logs, und verwenden Sie “Korrektur validieren”.
• Bings öffentliche Aussagen weisen in die gleiche Richtung wie die von Google – aber eine vollständige Code-für-Code-Parität ist nicht unabhängig verifiziert; Bing empfiehlt auch 503 + Retry-After für Ausfallzeiten.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• HTTP-Statuscodes, Netzwerkfehler und DNS-Fehler – das maßgebliche Dokument dazu, wie Google mit 4xx, 5xx, 429, Weiterleitungen und Netzwerk-/DNS-Fehlern umgeht.
• Seitenindexierungsbericht (Search Console-Hilfe) – jeder Fehlerstatus, den Sie täglich sehen (404, 5xx, 401, 403, andere 4xx, Soft 404, Weiterleitungsfehler) und “Korrektur validieren”.
• Optimieren Sie Ihr Crawl-Budget – wie Serverfehler das Crawl-Limit reduzieren und warum Soft 404s Budget verschwenden.
• Pausieren Sie Ihr Online-Geschäft in der Google-Suche – das 503 + Retry-After-Playbook für geplante Ausfallzeiten und was Sie nicht tun sollten.
• Soft-404-Fehler – was ein Soft 404 ist und wie Sie ihn beheben.
• Machen Sie Ihre 404-Seiten nützlicher – ältere, aber weiterhin gültige Anleitung: Eine freundliche 404-Seite ist in Ordnung, solange sie einen echten 404-Code zurückgibt.

Bing / Microsoft

• Crawl-Fehlerwarnungen (Bing Webmaster Tools-Hilfe) – wo Bing Crawl-Fehler anzeigt.
• bingbot-Serie: Maximierung der Crawl-Effizienz – Bings “Nordstern der Crawl-Effizienz”, gegen den anhaltende Fehler arbeiten.

Zitate aus der Quelle

Aussagen von Google und Bing, die öffentlich dokumentiert sind. Jeder Link ist ein Deep-Link, der direkt zur zitierten Passage auf der Quellseite springt.

Google – die 4xx- vs. 5xx-Trennung

• “For Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” (Übersetzung) „Für die Google-Suche garantiert ein HTTP-2xx (success)-Statuscode keine Indexierung.” — Google Search Central-Dokumentation. Zum Zitat springen
• “Google doesn’t use the content from URLs that return 4xx status codes.” (Übersetzung) „Google verwendet keine Inhalte von URLs, die 4xx-Statuscodes zurückgeben.“ Zum Zitat springen
• “The 4xx status codes, except 429, have no effect on crawl rate.” (Übersetzung) „Die 4xx-Statuscodes, außer 429, haben keine Auswirkung auf die Crawl-Rate.“ Zum Zitat springen

Google – 5xx und 429

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (Übersetzung) „5xx- und 429-Serverfehler veranlassen die Crawler von Google, das Crawling vorübergehend zu verlangsamen.“ Zum Zitat springen
• “already indexed URLs are preserved in the index, but eventually dropped.” (Übersetzung) „Bereits indexierte URLs bleiben im Index erhalten, werden aber schließlich entfernt.“ Zum Zitat springen
• “Any content Google receives from URLs that return a 5xx status code is ignored.” (Übersetzung) „Alle Inhalte, die Google von URLs erhält, die einen 5xx-Statuscode zurückgeben, werden ignoriert.“ Zum Zitat springen
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (Übersetzung) „Die Crawler von Google behandeln den 429-Statuscode als Signal dafür, dass der Server überlastet ist, und er gilt als Serverfehler.“ Zum Zitat springen

Google – Crawl-Budget und Soft 404

• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (Übersetzung) „Wenn die Website langsamer wird oder mit Serverfehlern antwortet, sinkt das Limit und Google crawlt weniger.“ Zum Zitat springen
• “Soft 404 pages will continue to be crawled, and waste your budget.” (Übersetzung) „Soft-404-Seiten werden weiterhin gecrawlt und verschwenden Ihr Budget.“ Zum Zitat springen

Google – geplante Ausfallzeiten

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (Übersetzung) „Wenn Sie die Website dringend für 1–2 Tage deaktivieren müssen, geben Sie eine informative Fehlerseite mit einem HTTP-Statuscode 503 zurück.“ Zum Zitat springen
• “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (Übersetzung) „Geben Sie für die robots.txt-Datei keinen HTTP-Statuscode 503 zurück, da dies das gesamte Crawling blockiert.“ Zum Zitat springen

Google – es ist in Ordnung, nicht indexiert zu werden

• “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.” (Ü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.“ — Search Console-Hilfe. Zum Zitat springen

John Mueller, Google – 404s sind kein Qualitätssignal

• “404s are not a quality signal, it’s not a SEO signal.” (Übersetzung) „404s sind kein Qualitätssignal, es ist kein SEO-Signal.“ Zur Berichterstattung
• Zur Reaktion der Crawl-Rate: “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts… (404s are generally fine & once discovered, Googlebot will retry them anyway)… Once things settle down on the server, the crawl rate will return to normal automatically.” (Übersetzung) „Ich würde nur erwarten, dass die Crawl-Rate so schnell reagiert, wenn sie 429 / 500 / 503 / Timeouts zurückgeben … (404s sind im Allgemeinen in Ordnung und sobald sie entdeckt werden, wird Googlebot sie sowieso erneut versuchen) … Sobald sich die Dinge auf dem Server beruhigt haben, kehrt die Crawl-Rate automatisch zur Normalität zurück.“ Zur Berichterstattung

Fabrice Canel, Microsoft Bing

• “Our crawl efficiency north star is to crawl a URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).” (Übersetzung) „Unser Nordstern für die Crawl-Effizienz ist es, eine URL nur dann zu crawlen, wenn der Inhalt hinzugefügt wurde (URL zuvor nicht gecrawlt), aktualisiert wurde (frischer On-Page-Kontext oder nützliche ausgehende Links).“ Zum Zitat springen

Mit welchem Fehler befasse ich mich zuerst?

Wenn eine Reihe von Fehlern auftaucht, arbeiten Sie die Triage in dieser Reihenfolge ab – Servergesundheit vor fehlenden Seiten, denn dort liegt der echte, seitenweite Schaden.

1. Sehen Sie 5xx oder 429 (Serverfehler oder eine Spitze von Timeouts)?

• Ja → Behandeln Sie es als dringend. Dies ist der Zweig, der das Crawling seitenweit drosselt und Seiten deindexieren kann, wenn er anhält. Finden Sie die Ursache jetzt: Serverkapazität/Timeouts (500), Upstream/CDN-Gesundheit (502/504) oder eine WAF / ein Rate-Limiter, der auf Googlebot fehlauslöst (403/429). Die Erholung erfolgt automatisch, sobald Sie 2xx zurückgeben, aber die Crawl-Rate steigt allmählich wieder an.
• Nein → Weiter; 4xx hat keinen Einfluss auf die Crawl-Rate.

2. Ist es ein Soft-404 (ein 200, der als „nicht gefunden“ gelesen wird)?

• Ja → Korrigieren Sie den Antwortcode. Geben Sie entweder einen echten 404/410 zurück, oder wenn die Seite verschoben wurde, leiten Sie die URL per 301 auf eine relevante Seite weiter. Hören Sie auf, tote URLs pauschal auf die Startseite umzuleiten. Soft-404s verschwenden Crawl-Budget, weil Google sie immer wieder überprüft.
• Nein → Weiter.

3. Ist es ein 404 / 410 (Nicht gefunden / Entfernt)?

• Hat die URL eingehende Links, interne Links, Sitemap-Präsenz oder anhaltenden Traffic?
  • Ja → Leiten Sie die URL per 301 auf eine relevante Seite weiter, um die Linkkraft zurückzugewinnen.
  • Nein → Lassen Sie die URL unverändert. Eine wirklich tote Seite sollte einfach 404/410 zurückgeben – es ist keine Strafe, und Sie müssen sie nicht reparieren.

4. Ist es ein 401 / 403 (Blockiert)?

• Sollte diese Seite öffentlich sein? Ja → Korrigieren Sie die Auth-/Berechtigungskonfiguration oder die WAF- Regel, die Googlebot blockiert. Nein → Es ist in Ordnung, blockiert zu sein – aber erwarten Sie nicht, dass der 401/403 Googlebot drosselt; er macht den Inhalt nur unsichtbar.

5. Ist es ein 451 (Rechtlich)?

• Das ist eine rechtliche Entfernung oder Geo-Sperre, kein technischer Fehler – behandeln Sie es über den rechtlichen/Compliance-Prozess, nicht über den SEO-Prozess.

6. Ist es ein Redirect-Fehler?

• Verkürzen Sie die Kette (Google folgt bis zu ~10 Hops), brechen Sie die Schleife oder korrigieren Sie die schlechte/überlange URL in der Kette, sodass sie zu einem einzigen endgültigen 200 auflöst.

Deindexierung oder Crawl-Verschwendung – welchem Schaden stehe ich tatsächlich gegenüber?

• Seiten verlassen den Index? → Suchen Sie nach anhaltenden 4xx (als „entfernt“ eingestuft) oder anhaltenden 5xx (nach anhaltendem Fehler entfernt). Isolierte Fehler tun dies nicht.
• Crawl-Budget wird verbrannt (große Seiten)? → Suchen Sie nach Soft-404s und Massen- fehlern – die Seiten, die immer wieder gecrawlt werden, weil sie lebendig aussehen.

Fehlercode → Verhalten → Fix-Spickzettel

Wie Google jeden Code behandelt

Schnelle Fakten

• 4xx (außer 429): Inhalt ignoriert, URL verworfen, keinerlei Auswirkung auf die Crawl-Rate.
• 5xx + 429: zuerst drosseln, nur bei anhaltendem Fehler deindexieren, die Erholung erfolgt allmählich.
• 404s sind kein Qualitäts-/Ranking-Signal — nach Links/Traffic priorisieren.
• Soft 404 = die Falle: 200, das sich als entfernt liest → verschwendet Crawl-Budget.
• Geplante Ausfallzeiten = 503 + Retry-After, höchstens einige Tage lang, niemals 403/404/410 — und niemals die robots.txt mit 503 beantworten (blockiert alles Crawlen).
• Weiterleitungen: Google folgt bis zu ~10 Sprüngen; zu lange oder fehlerhafte Ketten ergeben einen Weiterleitungsfehler in der GSC.

GSC-Seitenindexierungsstatus, die Sie beachten sollten Nicht gefunden (404) · Serverfehler (5xx) · Blockiert wegen nicht autorisierter Anfrage (401) · Blockiert wegen Zugriff verboten (403) · Blockiert wegen anderem 4xx-Problem · Soft 404 · Weiterleitungsfehler — dann Fehlerbehebung validieren, sobald behoben.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• HTTP-Statuscodes und ihre SEO-Auswirkungen — meine vollständige Code-für-Code-Aufschlüsselung: 4xx, 5xx, 429 und die praktischen Lösungen, über den gesamten Statuscode-Bereich.
• 11 Arten von Weiterleitungen und ihre SEO-Auswirkungen — die Weiterleitungsseite, die eine Hauptursache für Weiterleitungsfehler und Soft 404s ist.
• Der Anfängerleitfaden für technisches SEO — wo Statuscodes in das größere Bild passen.

Meine Vorträge

• How Search Works (SlideShare) — mein Durchgang durch Crawling, Rendering, Indexierung und Auslieferung, einschließlich, wie Statuscodes die Pipeline steuern. (Mein üblicher Haftungsausschluss gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Das ist mein Verständnis von Systemen… es wird nicht zu 100 % vollständig oder genau sein.”)

Aus der Branche

• Googlebot-Crawl-Einbruch? Mueller verweist auf Serverfehler (Search Engine Journal) — der Artikel, der die Unterscheidung “Crawl-Rate reagiert auf 429/500/503/Timeouts, nicht auf 404s” in Muellers eigenen Worten untermauert.
• Der ultimative Leitfaden zu HTTP-Statuscodes für SEO (Search Engine Land) — eine breite Referenz über alle Statusklassen.
• HTTP-Statuscodes erklärt (Semrush) — implementierungsorientierter Überblick über die Codefamilien.
• Ein SEO-Leitfaden zu HTTP-Statuscodes (Search Engine Journal) — eine Code-für-Code-Referenz mit SEO-Kontext.
• r/TechSEO — die Community für Crawl-Fehler- und Indexierungs-Debugging.

Das Zwei-Schäden-Modell: Verschwinden vs. Crawl-Drosselung

Priorisieren Sie einen HTTP-Fehler nicht allein anhand der ersten Ziffer. Fragen Sie, welchen der beiden Schäden er verursacht.

Schaden 1: Die URL besagt, dass der Inhalt nicht existiert

Die meisten 4xx-Antworten teilen Google mit, dass der angeforderte Inhalt nicht verfügbar ist. Google indexiert den zurückgegebenen Inhalt nicht, und eine dauerhaft betroffene URL kann aus dem Index entfernt werden. Der Umfang ist normalerweise auf die URL selbst beschränkt; gewöhnliche 4xx-Antworten signalisieren Google nicht, dass der gesamte Server ungesund ist. Die Ausnahme ist 429, das Google wie ein Serververfügbarkeitsproblem behandelt.

Entscheidungsfrage: Soll diese URL existieren, Traffic erhalten oder Links bewahren? Wenn ja, beheben Sie den fehlerhaften Status oder leiten Sie Nutzer an ein wirklich gleichwertiges Ziel weiter. Wenn nein, kann ein 404 oder 410 das korrekte Ergebnis sein und kein SEO-Problem darstellen.

Schaden 2: Der Server signalisiert, dass er nicht zuverlässig antworten kann

5xx-Antworten und 429 signalisieren Verfügbarkeits- oder Kapazitätsprobleme. Google kann das Crawling reduzieren, um zusätzliche Last zu vermeiden; nur anhaltende Fehler gefährden indexierte URLs. Der Schaden kann sich daher über eine einzelne fehlerhafte URL hinaus auf langsamere Erkennung und Aktualisierung auf der gesamten Website auswirken.

Entscheidungsfrage: Ist der Fehler anhaltend oder breit genug, um das Crawler-Verhalten zu ändern? Wenn ja, behandeln Sie ihn als Infrastrukturvorfall und stellen Sie zuverlässige Antworten wieder her. „Beheben“ Sie ihn nicht innerhalb der Search Console.

Prioritätsüberlagerung: Wert und Absicht

Nach der Auswahl des Schadens ordnen Sie die betroffenen URLs danach, ob sie live sein sollten, interne oder externe Links haben, in einer Sitemap erscheinen, Suchverkehr erhalten oder eine kritische Vorlage darstellen. Eine Fehleranzahl ohne diesen Kontext ist keine Prioritätenliste.

Evidenz-/Aktionsmatrix: Was pro Fehler zu erfassen ist

Das Zwei-Schaden-Modell zeigt Ihnen, welches Problem Sie haben. Diese Matrix zeigt, was Sie für jede betroffene URL tatsächlich erfassen sollten, bevor Sie entscheiden, was damit zu tun ist – das Überspringen einer dieser Spalten verwandelt eine Triage-Liste in eine Vermutung:

Prompt: GSC-Fehlerexport in eine Triage-Warteschlange verwandeln

Exportieren Sie die Liste der betroffenen URLs aus der Search Console und ergänzen Sie nach Möglichkeit Statuscode, Sitemap-Präsenz, organische Klicks und Impressionen, interne und externe Links sowie den beabsichtigten URL-Zustand. Fügen Sie nur nicht sensible Daten ein.

You are triaging an HTTP-error URL export for technical SEO. Use only the supplied
columns. Do not assume that every 404 is a problem or that every 5xx is permanent.

For each URL:
1. Classify the response as 4xx disappearance risk, 5xx/429 crawl-throttling risk,
   soft-404 mismatch, or insufficient evidence.
2. Decide whether the URL appears intended to exist, based only on sitemap presence,
   links, traffic, template, and the supplied intended-state field.
3. Assign priority: incident-now, high, medium, low, or expected/no fix.
4. Explain the priority using the exact supplied signals.
5. Recommend the next verification, not a guessed root cause.

Prioritize broad or persistent 5xx/429 incidents first, then intended URLs with
traffic or links, then sitemap/internal-link hygiene. Keep intentional 404/410 URLs
out of the fix queue. Return a table plus a short list of missing data that would
change the ranking.

DATA:
[PASTE SANITIZED EXPORT HERE]

Verifizieren Sie die Ausgabe anhand von Live-Statusprüfungen und der beabsichtigten URL-Zuordnung der Website, bevor Sie Arbeiten zuweisen.

Tools für die Fehler-Triage

• Bulk HTTP Status Code Checker — fügen Sie die exportierten URLs ein, um Live-Statuscodes, Weiterleitungsketten, Ziele und Latenz zu erfassen, und filtern und exportieren Sie dann das Ergebnis. So wird eine veraltete Berichtszeile in aktuelle HTTP-Belege umgewandelt.
• Website Down Checker — prüfen Sie, ob ein vermuteter 5xx-Vorfall extern reproduzierbar ist, bevor Sie Anwendungs- oder Crawler-Einstellungen ändern.
• Google Search Console Page Indexing report — identifizieren Sie die Begründungsgruppen von Google und betroffene Beispiele; verwenden Sie URL Inspection für eine repräsentative Live-Prüfung.
• Server- oder CDN-Zugriffsprotokolle — messen Sie die Fehlerraten gegenüber Crawlern und unterscheiden Sie ein einzelnes URL-Problem von einem siteweiten Verfügbarkeitsmuster.

Search Console berichtet, was Google beobachtet hat; es ersetzt keine Live-Anfrage oder die Server-Belege, die zur Ursachenfindung erforderlich sind.

Beabsichtigte URLs, die Fehler zurückgeben

Kennzahl: Anzahl und Anteil der URLs, die live sein sollen, aber 4xx, 5xx oder 429 zurückgeben, segmentiert nach Antwortfamilie und Vorlage.

Was es Ihnen sagt: Trennt echte Verfügbarkeits-/Indexierungsfehler von beabsichtigter 404/410-Bereinigung.

So ziehen Sie es: Kombinieren Sie einen aktuellen Crawl oder einen Bulk-HTTP-Statuscode-Checker-Export mit Ihrer Sitemap, Ihrem internen Linkgraphen und Ihrem beabsichtigten URL-Inventar.

Benchmark / realistischer Bereich: Das Ziel ist null unbeabsichtigte Fehler auf URLs, die live sein müssen. Erwartete zurückgezogene URLs sollten separat verfolgt und nicht in ein erfundenes websiteweites Fehlerraten-Ziel gezwungen werden.

Häufigkeit: Täglich für kritische Vorlagen und während Releases; wöchentlich für das breitere Inventar.

Fehlerrate bei Crawler-Anfragen

Kennzahl: Suchmaschinen-Anfragen, die 4xx, 429 oder 5xx zurückgeben, als Anteil verifizierter Crawler-Anfragen, aufgeschlüsselt nach Status, Hostname und Pfadgruppe.

Was es Ihnen sagt: Zeigt, ob Crawler-Verschwendung in zurückgezogenen URLs konzentriert ist oder ob Serverfehler die Crawl-Nachfrage unterdrücken könnten.

So ziehen Sie es: Aggregieren Sie verifizierte Crawler-Anfragen aus CDN- oder Server-Zugriffsprotokollen; verlassen Sie sich nicht allein auf den User-Agent-String, wenn Verifizierung verfügbar ist.

Benchmark / realistischer Bereich: Legen Sie die normale Mischung für Ihre Site fest. Beabsichtigte 404s können legitim sein; unerklärliche 5xx/429-Antworten auf beabsichtigten URLs sollten nicht als normale Basislinien-Rauschen behandelt werden.

Häufigkeit: Überwachen Sie kontinuierlich auf 5xx/429-Alarme; überprüfen Sie segmentierte Trends wöchentlich.

Search Console-Fehlerinventar-Trend

Kennzahl: Betroffene URL-Anzahl nach Page-Indexing-Grund, gepaart mit repräsentativem URL-Status und Berichtsaktualisierungsdatum.

Was es Ihnen sagt: Ob das von Google beobachtete Inventar nach Korrekturen schrumpft oder sich auf zusätzliche Vorlagen ausweitet.

So ziehen Sie es: Exportieren Sie die Page-Indexing-Begründungstabellen und behalten Sie datierte Schnappschüsse; stichprobenartig Beispiele mit URL Inspection und Live-Anfragen prüfen.

Benchmark / realistischer Bereich: Vergleichen Sie mit dem beabsichtigten Zustand der Site und ihren eigenen früheren Schnappschüssen. Search Console ist stichprobenartig und verzögert, also erfinden Sie keinen Echtzeit-Bestehens-Schwellenwert.

Häufigkeit: Wöchentlich und nachdem Google Zeit hatte, eine bereitgestellte Korrektur erneut zu crawlen; verwenden Sie Protokolle und Live-Prüfungen für die sofortige Vorfallüberwachung.

Testen Sie sich selbst: HTTP-Fehlercodes

Fünf kurze Fragen dazu, wie Google mit 4xx- und 5xx-Fehlern umgeht. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Änderungsprotokoll