429 und 503 bei Googlebot: Überlastung erkennen und kontrolliert beheben

Die tatsächliche Antwort und ihren Ursprung erfassen

Ein Fehler kann vom eigentlichen Webserver, einem vorgeschalteten Dienst oder einer Schutzregel stammen. Erfassen Sie betroffene Adresse, Zeitpunkt, Statuscode und den beobachteten Antwortweg. Die Behauptung „der Server war überlastet“ ist erst eine Hypothese, wenn nur eine einzelne Meldung ohne zugehörige technische Beobachtung vorliegt.

Prüfen Sie vorhandene Protokolle und Hostinghinweise innerhalb der bestehenden Zugriffsrechte. Verändern Sie Sicherheitsregeln nicht allein, um einen Suchmaschinenwert zu verbessern. Eine legitime Schutzmaßnahme und eine unbeabsichtigte Blockade müssen fachlich unterschieden werden; das Ziel ist verlässlicher erlaubter Abruf, nicht das Abschalten von Schutz.

Vorübergehende Fehler nicht als Dauerlösung einsetzen

Google beschreibt 429 und 5xx als Signale, die Abrufe vorübergehend reduzieren können. Dauerhafte Fehler können jedoch dazu führen, dass bisher indexierte Adressen später entfallen. Eine dauerhaft fehlerhafte Antwort ist deshalb kein sauberer Ersatz für eine eigentliche Indexierungsentscheidung.

Untersuchen Sie Ursache und Dauer. Eine geplante kurze Wartung, eine ausgereizte Ressource und ein falsch konfigurierter vorgelagerter Dienst verlangen unterschiedliche Schritte. Kopieren Sie keine pauschalen Wartezeiten oder Retry-Werte aus fremden Beispielen. Der tatsächliche Betriebszustand muss die Antwort und den Wiederherstellungsplan bestimmen.

Die passende Grundlage erläutert Serverlogs für SEO-Fragen auswerten.

Entscheidungen am konkreten Befund festmachen

Eine Fehlerantwort bis zum verantwortlichen Dienst verfolgen

Das Prüfblatt enthält URL, Zeitpunkt, beobachteten Status, tatsächliche Antwortquelle und vorhandene passende Loghinweise. Kennzeichnen Sie „Ursache noch ungeklärt“, wenn die Antwort nicht eindeutig einer Stufe zugeordnet werden kann. Prüfen Sie nach einer autorisierten Entstörung dieselbe ursprüngliche Adresse und einen erlaubten Gegenfall. Eine erneute erfolgreiche Antwort ohne richtigen Hauptinhalt reicht nicht. Wenn ein Fehler nur in einem bestimmten Zeitraum auftritt, muss dieser zeitliche Zusammenhang im Befund erhalten bleiben; ein späterer Einzelaufruf darf das ursprüngliche Ereignis nicht rückwirkend als unmöglich erklären.

Praxisfall: Schutzdienst antwortet anders als die Anwendung

Eine fiktive Produktseite funktioniert im eigenen Browser, liefert bei einzelnen erlaubten Abrufen aber eine 429-Antwort des vorgelagerten Dienstes. Das Anwendungsteam sieht keine entsprechenden Fehler. Ein erneuter Artikelaufbau würde das Problem nicht beheben, weil die Abweichung vor der eigentlichen Seite entsteht.

Die zuständige technische Betreuung vergleicht die tatsächlich vorhandenen Protokolle und die betroffenen Zeitpunkte. Nach einer autorisierten Korrektur wird derselbe Abrufweg wieder geprüft. Ein erfolgreicher eigener Browseraufruf bleibt ein zusätzlicher Fall, ist aber kein Ersatz für die Untersuchung der ursprünglich beobachteten Fehlerantwort.

Wiederherstellung mit mehreren realen Seiten prüfen

Nehmen Sie wichtige Produkt-, Informations- und Einstiegsseiten in eine gezielte Stichprobe auf. Kontrollieren Sie Status und Inhalt der Antwort. Ein HTTP 200 mit einer leeren Fehlermeldung ist keine vollständige Wiederherstellung einer hilfreichen Seite.

Dokumentieren Sie den Zeitpunkt, ab dem die geprüften Antworten stabil sind. Google kann seine Abrufrate nach wieder erfolgreichen Antworten schrittweise anpassen. Eine sofortige Rückkehr aller bisherigen Suchpositionen folgt daraus nicht. Halten Sie technische Entstörung, erneuten Abruf und tatsächliche Indexierungsbeobachtung im Bericht getrennt.

Die passende Grundlage erläutert HTTP-Statuscodes im Website-Audit einordnen.

Häufige Fragen.