WordPress Fehler 429 Too Many Requests: Rate-Limits, CDN-Sperren und

Zuletzt aktualisiert: 9. Oktober 2026

Quick Answer: Der WordPress Fehler 429 Too Many Requests bedeutet, dass ein Server oder ein vorgelagerter Dienst (CDN, WAF, Sicherheitsplugin) zu viele Anfragen von einer IP-Adresse oder einem Client in kurzer Zeit registriert und diese blockiert. Die Lösung hängt davon ab, wer das Limit setzt: der Hosting-Server, Cloudflare, ein WordPress-Plugin oder eine fehlerhafte Bot-Regel. Wer den richtigen Verursacher identifiziert, kann gezielt eingreifen, ohne legitime Besucher oder Suchmaschinen dauerhaft auszusperren.

Key Takeaways

🔍 429 ist kein Server-Absturz, sondern ein bewusstes Drosselungssignal, der Server funktioniert, er lehnt nur zu häufige Anfragen ab.
⚙️ Vier Hauptquellen im WordPress-Umfeld: Hosting-Rate-Limits, CDN/WAF-Regeln (z. B. Cloudflare), Sicherheitsplugins und fehlerhafte API- oder Cron-Aufrufe.
🤖 Falsche Bot-Regeln sind 2026 eine der häufigsten Fehlerquellen, Googlebot, Uptime-Monitore und legitime API-Clients werden irrtümlich gesperrt.
📋 Response-Header lügen nicht: Der Retry-After-Header und die X-RateLimit-*-Felder zeigen, wer das Limit gesetzt hat.
🛡️ Cloudflare-Konfiguration erfordert separate Einstellungen für Bot-Regeln, Rate-Limiting-Regeln und WAF-Firewall-Regeln.
🔄 WordPress Heartbeat API und REST-API-Endpunkte sind häufige Auslöser für interne 429-Fehler im Admin-Bereich.
✅ Whitelists vor Deaktivierung: Immer erst legitime IPs/User-Agents whitelisten, bevor Rate-Limits generell gelockert werden.
⚠️ Nie Rate-Limiting komplett abschalten, das öffnet die Tür für Brute-Force-Angriffe auf wp-login.php.
🔧 Praxiswerte für 2026: 5-10 Req/Min für Login-Endpunkte, 30-60 Req/Min für REST-API-Endpunkte gelten als solide Ausgangsbasis.
📞 Wenn die Ursache unklar bleibt: Professionelle Hilfe ist oft schneller als stundenlanges Trial-and-Error.

Was bedeutet der WordPress Fehler 429 Too Many Requests genau?

Der HTTP-Statuscode 429 ist ein standardisierter Fehler (definiert in RFC 6585), der signalisiert: „Du sendest zu viele Anfragen in zu kurzer Zeit.“ Der Server oder ein vorgelagerter Dienst hat ein Limit gesetzt und lehnt weitere Anfragen temporär ab. [1]

Das Wichtige dabei: 429 ist kein Absturz. Die Website lebt, der Server läuft, er drosselt nur. Oft enthält die Antwort einen Retry-After-Header, der angibt, wie lange gewartet werden soll. [5]

Im WordPress-Kontext taucht dieser Fehler an verschiedenen Stellen auf:

Im Browser beim Seitenaufruf (Besucher sehen eine Fehlerseite)
Im WordPress-Admin-Bereich (z. B. beim Speichern von Beiträgen)
In Plugin-Logs oder bei API-Integrationen
In Monitoring-Tools oder Uptime-Checks

Wichtige Unterscheidung: Der Fehler kann von vier verschiedenen Ebenen kommen, Hosting-Server, CDN/WAF, WordPress-Plugin oder einer externen API. Jede Ebene erfordert eine andere Lösung.

KI-generiertes Bild

Warum bekomme ich 429-Fehler auf meiner WordPress-Seite?

429-Fehler entstehen auf WordPress-Seiten aus einer Handvoll konkreter Ursachen. Die häufigsten in 2026:

1. Brute-Force-Angriffe auf wp-login.php Automatisierte Angriffe versuchen hunderte Passwörter pro Minute. Sicherheitsplugins oder der Hoster erkennen das und sperren die angreifende IP. Das ist gewolltes Verhalten, aber manchmal trifft es auch legitime Nutzer. [4]

2. WordPress Heartbeat API Die Heartbeat API sendet standardmäßig alle 15-60 Sekunden Anfragen an den Server, um den Admin-Bereich aktuell zu halten. Bei mehreren offenen Browser-Tabs oder langsamen Servern kann das schnell zu 429-Fehlern führen. [3]

3. Plugins mit aggressiven API-Aufrufen Manche Plugins (SEO-Tools, WooCommerce-Erweiterungen, Backup-Plugins) senden in kurzen Abständen viele Anfragen an den Server oder externe APIs. Wenn das Rate-Limit des Hosters überschritten wird, folgt der 429. [2]

4. Zu enge CDN- oder WAF-Regeln Cloudflare und andere CDNs haben eigene Rate-Limiting-Regeln. Wenn diese zu aggressiv konfiguriert sind, blockieren sie auch normale Besucher oder Crawler. [1]

5. Fehlerhafte Cron-Jobs WordPress-Cron-Jobs, die in Schleifen laufen oder zu häufig ausgelöst werden, können den Server überlasten. Mehr dazu im Artikel über WordPress Cron Jobs, die nicht funktionieren.

Wie unterscheiden sich Rate-Limiting und CDN-Sperren?

Rate-Limiting und CDN-Sperren sind verwandte, aber unterschiedliche Mechanismen. Das Verwechseln der beiden ist eine der häufigsten Fehlerquellen bei der Fehlerbehebung.

KI-generiertes Bild

Merkmal	Server-Rate-Limiting	CDN/WAF-Sperre (z. B. Cloudflare)
Wo aktiv?	Hosting-Server / PHP / nginx / Apache	Vor dem Server, im CDN-Netzwerk
Konfiguration	Hosting-Panel,.htaccess, nginx.conf	Cloudflare-Dashboard, WAF-Regeln
Sichtbar in Logs?	Server-Logs (access.log, error.log)	CDN-Firewall-Logs / Analytics
Typischer Auslöser	Zu viele PHP-Prozesse, Plugin-Loops	Bot-Erkennung, IP-Reputation, Geo-Blocking
Lösung	Limits erhöhen oder Anfragen reduzieren	Whitelist, Bot-Regel anpassen, Ausnahmen

Faustregel: Wenn der 429-Fehler im Cloudflare-Dashboard als „Firewall Event“ auftaucht, ist die CDN-Ebene schuld. Wenn er nur in den Server-Logs erscheint, liegt das Problem beim Hosting. [6]

Wie prüfe ich meine WordPress Rate-Limit-Einstellungen?

Die Diagnose des WordPress Fehler 429 Too Many Requests läuft in fünf klaren Schritten ab. Wer diese Reihenfolge einhält, spart viel Zeit.

KI-generiertes Bild

Schritt 1: Browser-DevTools öffnen Im Chrome/Firefox: F12 → Reiter „Netzwerk“ → Seite neu laden. Nach Einträgen mit Status 429 suchen. Den betroffenen Request anklicken und die Response-Header prüfen.

Schritt 2: Response-Header auswerten Relevante Header:

Retry-After: 60 → Server sagt, wie lange warten
X-RateLimit-Limit: 100 → Maximale Anfragen
X-RateLimit-Remaining: 0 → Kontingent aufgebraucht
CF-RAY: → Cloudflare war beteiligt [1]

Schritt 3: Server-Logs prüfen Im Hosting-Panel (cPanel, Plesk) unter „Error Logs“ oder „Access Logs“ nach 429-Einträgen suchen. Zeitstempel und IP-Adressen notieren.

Schritt 4: WordPress-Debug aktivieren In wp-config.php temporär eintragen:

<code class="language-php">define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
</code>

Dann /wp-content/debug.log auf 429-relevante Einträge prüfen.

Schritt 5: Sicherheitsplugin-Logs prüfen Wordfence, iThemes Security und ähnliche Plugins führen eigene Logs. Dort oft direkt ersichtlich, welche IP oder welcher User-Agent geblockt wurde. [8]

Tipp: Wer den WordPress Fehler 503 Service Unavailable kennt, wird die Ähnlichkeit bemerken, beide Fehler deuten auf Überlastung hin, aber 503 kommt vom Server selbst, 429 ist eine bewusste Drosselung.

Verursacht Cloudflare meine 429-Fehler?

Ja, Cloudflare kann 429-Fehler auslösen, aber nicht immer auf die gleiche Weise. Es gibt drei verschiedene Cloudflare-Mechanismen, die 429-ähnliche Sperren erzeugen. [1]

Cloudflare Rate Limiting Rules Unter „Security → WAF → Rate limiting rules“ können Regeln definiert werden, die Anfragen pro IP und Zeitfenster begrenzen. Wenn diese zu eng konfiguriert sind, trifft es auch normale Besucher.

Bot Fight Mode / Super Bot Fight Mode Dieser Modus blockiert automatisch erkannte Bots. Das Problem: Er erkennt manchmal Googlebot, Bing-Bot oder Uptime-Monitoring-Dienste fälschlicherweise als schädliche Bots.

Firewall Rules (Custom Rules) Selbst erstellte Regeln, die bestimmte User-Agents oder IP-Bereiche blockieren, können legitimen Traffic treffen.

So prüft man Cloudflare als Ursache:

Cloudflare-Dashboard öffnen → „Security“ → „Events“
Nach blockierten Anfragen filtern
IP-Adresse oder User-Agent des betroffenen Clients suchen
Regel identifizieren, die den Block ausgelöst hat

Wichtig: Cloudflare gibt bei eigenen Rate-Limit-Sperren oft den Code 429 zurück, bei anderen Sperren (z. B. WAF-Regeln) jedoch 403. Das hilft bei der Unterscheidung. [1]

Wie whiteliste ich legitime Bots in WordPress?

Legitime Bots wie Googlebot, Bingbot oder Uptime-Monitore sollten niemals dauerhaft blockiert werden. Das Whitelisting funktioniert auf zwei Ebenen.

KI-generiertes Bild

Ebene 1: Cloudflare Bot-Whitelist

Im Cloudflare-Dashboard unter „Security → WAF → Tools“:

IP-Adresse des Bots unter „IP Access Rules“ als „Allow“ eintragen
Oder unter „Bots“ → „Bot Fight Mode“ → „Allow verified bots“ aktivieren

Verifizierte Bots (Googlebot, Bingbot etc.) werden von Cloudflare automatisch erkannt, wenn „Allow verified bots“ aktiv ist. [1]

Ebene 2: WordPress-Sicherheitsplugin

In Wordfence unter „Firewall → Brute Force Protection“:

„Whitelisted IP Addresses“ → IP des Monitoring-Dienstes eintragen
Unter „Tools → IP Whitelisting“ User-Agents von bekannten Crawlern hinterlegen

Ebene 3:.htaccess (Apache)

Für spezifische IP-Adressen, die immer durchgelassen werden sollen:

<code class="language-apache"># Googlebot-IP-Bereich freigeben (Beispiel)
<Limit GET POST>
  Allow from 66.249.0.0/16
</Limit>
</code>

⚠️ Achtung: IP-Adressen von Suchmaschinen ändern sich. Besser User-Agent-basierte Regeln nutzen oder die Cloudflare-Verifizierung verwenden, als IP-Ranges manuell zu pflegen. [7]

Welche Rate-Limits sind für WordPress-Seiten sinnvoll?

Es gibt keine universelle Zahl, aber es gibt praxiserprobte Richtwerte, die für die meisten WordPress-Seiten in 2026 als Ausgangsbasis funktionieren. [4]

Empfohlene Ausgangswerte nach Endpunkt:

Endpunkt	Empfohlenes Limit	Begründung
`wp-login.php`	5-10 Req/Min pro IP	Brute-Force-Schutz
`wp-admin/` allgemein	30-60 Req/Min	Admin-Nutzung
REST API (`/wp-json/`)	30-60 Req/Min	Plugin-Kompatibilität
WooCommerce Checkout	10-20 Req/Min	Fraud-Schutz
Heartbeat API	1 Req/60 Sek	Serverentlastung
Öffentliche Seiten	100-200 Req/Min	Normale Nutzung

Wichtige Anpassungsfaktoren:

Shared Hosting: Limits eher enger setzen (Server hat weniger Ressourcen)
Managed WordPress (z. B. Kinsta, WP Engine): Hoster hat eigene Limits, die Vorrang haben
WooCommerce-Shops: Checkout und Cart-Endpunkte brauchen etwas mehr Spielraum
Mitglieder-Seiten: Login-Endpunkt muss für viele gleichzeitige echte Nutzer zugänglich bleiben [9]

Wähle engere Limits, wenn: die Seite regelmäßig unter Brute-Force-Angriffen leidet oder auf einem schwachen Shared-Hosting-Paket läuft.

Wähle weitere Limits, wenn: viele echte Nutzer gleichzeitig eingeloggt sind (z. B. Mitglieder-Plattformen, Online-Shops mit hohem Traffic).

Können falsche Bot-Regeln echte 429-Sperren verursachen?

Ja, und das ist 2026 eine der häufigsten Fehlerursachen überhaupt. Falsch konfigurierte Bot-Regeln sind tückisch, weil sie stillen Schaden anrichten: Die Website läuft, aber bestimmte Nutzergruppen oder Crawler kommen nicht rein.

Typische Fälle falscher Positiv-Erkennungen:

Googlebot wird geblockt → Seite verschwindet aus dem Index
Uptime-Monitoring (z. B. UptimeRobot) wird geblockt → Falsche Alarm-Meldungen
Zahlungsanbieter-Webhooks werden geblockt → WooCommerce-Bestellungen schlagen fehl
CDN-Prerender-Dienste werden geblockt → Social-Media-Previews funktionieren nicht
Eigene API-Integrationen werden geblockt → Datenübertragungen brechen ab [7]

Wie man falsche Positiv-Erkennungen aufdeckt:

Cloudflare Security Events nach blockierten Anfragen durchsuchen
User-Agent der blockierten Anfragen notieren
Prüfen, ob der User-Agent einem legitimen Dienst gehört (z. B. via user-agent-string.info)
Entsprechende Whitelist-Ausnahme erstellen

Praxishinweis von WP-Repair: In vielen Fällen, die täglich bearbeitet werden, ist nicht der Angreifer das Problem, sondern eine zu aggressiv eingestellte Sicherheitsregel, die legitimen Traffic blockiert. Das ist schwerer zu erkennen, weil keine offensichtliche Fehlermeldung erscheint.

Wer vermutet, dass sein Plugin Probleme verursacht, sollte auch den Artikel über WordPress Plugin-Fehler beheben ohne Datenverlust lesen.

Wie konfiguriere ich Rate-Limits in WordPress richtig?

Die richtige Konfiguration des WordPress Fehler 429 Too Many Requests erfordert ein abgestimmtes Vorgehen auf mehreren Ebenen gleichzeitig.

Schritt 1: Heartbeat API drosseln

Mit dem Plugin „Heartbeat Control“ (kostenlos) oder manuell in functions.php:

<code class="language-php">add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 60; // Sekunden zwischen Anfragen
    return $settings;
});
</code>

Schritt 2: Login-Schutz konfigurieren

Wordfence: „Firewall → Brute Force Protection“ → Login-Versuche auf 5 pro Minute begrenzen. Alternativ: „Limit Login Attempts Reloaded“ Plugin installieren und konfigurieren. [4]

Schritt 3: REST-API-Zugriff einschränken

Nicht benötigte REST-API-Endpunkte deaktivieren. In functions.php:

<code class="language-php">add_filter('rest_authentication_errors', function($result) {
    if (!is_user_logged_in()) {
        return new WP_Error('rest_not_logged_in', 'Nicht autorisiert.', ['status' => 401]);
    }
    return $result;
});
</code>

⚠️ Vorsicht: Das blockiert auch öffentliche Endpunkte, die manche Plugins benötigen.

Schritt 4: CDN-Regeln abstimmen

Im Cloudflare-Dashboard:

Rate Limiting Rule für wp-login.php: max. 5 Req/10 Sek pro IP
Ausnahme für verifizierte Bots aktivieren
Custom Rule für eigene API-Integrationen mit „Skip“ erstellen [1]

Schritt 5: Hoster-Limits prüfen

Beim Hoster nachfragen (oder im Panel nachschauen), welche Rate-Limits serverseitig gesetzt sind. Managed-WordPress-Hoster wie Kinsta oder WP Engine haben eigene Limits, die nicht über WordPress konfigurierbar sind. [9]

Wer nach einem Update auf Fehler stößt, findet im Artikel über WordPress Fehler 500 nach PHP 8.3/8.4 Update weitere Diagnose-Hinweise.

Braucht mein CDN andere Einstellungen für 429-Fehler?

Ja. CDN-Einstellungen für 429-Fehler unterscheiden sich grundlegend von Server-seitigen Konfigurationen, weil CDNs eine eigene Logik für Bot-Erkennung, IP-Reputation und Traffic-Analyse mitbringen.

Was CDNs anders machen:

CDNs sehen den Traffic vor dem Server und können Muster erkennen, die der Server nicht sieht
Sie unterscheiden zwischen „Challenge“ (CAPTCHA), „Block“ (harter 429/403) und „Allow“
Viele CDNs haben separate Regeln für API-Traffic vs. Browser-Traffic [1]

Empfohlene CDN-Einstellungen für WordPress:

Bot Fight Mode: Aktivieren, aber „Allow verified bots“ einschalten
Rate Limiting: Separate Regeln für /wp-login.php, /wp-json/ und öffentliche Seiten
Cache-Ausnahmen: Admin-Bereich (/wp-admin/) und Login-Seite vom Cache ausschließen
IP-Geolocation: Nur aktivieren, wenn wirklich notwendig, zu viele Geo-Blocks treffen auch VPN-Nutzer

Häufiger Fehler: Viele Nutzer aktivieren Cloudflares „Under Attack Mode“ bei Problemen und vergessen, ihn danach wieder zu deaktivieren. Dieser Modus blockiert praktisch alle automatisierten Anfragen, auch Googlebot. [1]

Ähnliche Konfigurationsprobleme entstehen auch bei WordPress REST API Fehlern (404, 403), wo CDN-Regeln ebenfalls eine Rolle spielen.

Wie teste ich, ob mein WordPress Rate-Limiting funktioniert?

Nach jeder Konfigurationsänderung sollte man prüfen, ob die Regeln wie gewünscht greifen, und ob legitimer Traffic noch durchkommt.

KI-generiertes Bild

Test 1: Manuelle Anfragen-Simulation

Mit curl im Terminal:

<code class="language-bash">for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}n" https://deine-seite.de/wp-login.php; done
</code>

Wenn nach 5-10 Anfragen ein 429 zurückkommt, funktioniert das Login-Limit.

Test 2: Google Search Console prüfen

Unter „Abdeckung“ → „Fehler“ nach 429-Einträgen suchen. Wenn Googlebot geblockt wird, erscheint das hier innerhalb weniger Tage.

Test 3: Uptime-Monitor prüfen

UptimeRobot, Pingdom oder ähnliche Dienste melden 429-Fehler als „Downtime“. Wenn der Monitor nach der Konfiguration Alarm schlägt, ist er wahrscheinlich selbst in der Sperrliste.

Test 4: Cloudflare Security Events

Im Cloudflare-Dashboard nach der Änderung 24 Stunden warten und dann die Security Events prüfen. Gibt es neue Blockierungen von bekannten legitimen IPs?

Test 5: Plugin-Kompatibilität

Nach Rate-Limit-Änderungen alle kritischen Plugins testen: WooCommerce-Checkout durchführen, Formulare absenden, Backup-Plugin manuell starten. Wer dabei auf andere Fehler stößt, findet Hilfe beim WordPress Fehler 503 Service Unavailable.

Soll ich Rate-Limiting deaktivieren oder nur anpassen?

Rate-Limiting komplett zu deaktivieren ist fast immer die falsche Entscheidung. Stattdessen sollte man es anpassen.

Warum nie komplett deaktivieren:

wp-login.php ohne Rate-Limit ist ein offenes Tor für Brute-Force-Angriffe
Ohne Drosselung kann ein einziger fehlerhaften Cron-Job den Server lahmlegen
Hoster können bei Überlastung ohne eigene Schutzmaßnahmen das Konto sperren [10]

Wann Anpassen sinnvoll ist:

Legitime Nutzer werden fälschlicherweise gesperrt → Whitelist erweitern
Limits sind zu eng für normalen Traffic → Schwellenwerte erhöhen
Bestimmte Endpunkte brauchen mehr Spielraum → Ausnahmeregeln erstellen

Wähle „Deaktivieren“ nur für:

Temporäres Debugging (max. 30 Minuten, dann wieder aktivieren)
Einzelne, klar definierte Endpunkte, die keinen Angriffspunkt darstellen

Wähle „Anpassen“ für:

Alle produktiven Szenarien
Shops, Mitglieder-Seiten, API-Integrationen

Wer nach einem Hack auf 429-Fehler stößt, sollte zuerst die gehackte WordPress-Seite bereinigen, denn manchmal sind die Rate-Limits eine Reaktion auf laufende Angriffe, nicht die eigentliche Ursache.

FAQ: WordPress Fehler 429 Too Many Requests

Was ist der Unterschied zwischen 429 und 503? 429 bedeutet „zu viele Anfragen“, der Server drosselt bewusst. 503 bedeutet „Service nicht verfügbar“, der Server ist überlastet oder im Wartungsmodus. Beide können ähnliche Symptome zeigen, haben aber unterschiedliche Ursachen und Lösungen.

Wie lange dauert eine 429-Sperre? Das hängt vom Konfiguration ab. Viele Sperren dauern 1-15 Minuten. Der Retry-After-Header gibt die genaue Wartezeit an. Bei Cloudflare können Sperren auch länger andauern, wenn die IP auf einer Blockliste steht. [5]

Kann ein Plugin 429-Fehler verursachen, ohne dass ich es merke? Ja. Manche Plugins senden im Hintergrund regelmäßige API-Anfragen. Wenn diese das Rate-Limit überschreiten, erscheint der Fehler nur in den Logs, nicht unbedingt im Browser. [3]

Blockiert 429 auch Suchmaschinen-Crawler? Ja, wenn die Regeln zu eng sind. Googlebot und Bingbot können geblockt werden, was das Ranking negativ beeinflusst. Deshalb immer „Allow verified bots“ in CDN-Einstellungen aktivieren. [7]

Wie erkenne ich, ob Cloudflare oder mein Hoster das Limit setzt? Im Response-Header: Wenn CF-RAY vorhanden ist, war Cloudflare beteiligt. Wenn der Header fehlt, kommt das Limit vom Hosting-Server. Im Cloudflare-Dashboard unter „Security Events“ sieht man Cloudflare-seitige Blockierungen direkt. [1]

Muss ich für 429-Fixes ins Hosting-Panel? Nicht immer. Viele Fixes lassen sich direkt in WordPress (über Plugins oder wp-config.php) oder im CDN-Dashboard erledigen. Nur wenn der Hoster selbst Limits gesetzt hat, braucht man Zugang zum Hosting-Panel oder muss den Support kontaktieren. [9]

Was ist die Heartbeat API und warum verursacht sie 429-Fehler? Die Heartbeat API ist ein WordPress-Mechanismus, der regelmäßig Anfragen an den Server sendet, um den Admin-Bereich aktuell zu halten (z. B. Auto-Speicherung, Sitzungs-Verwaltung). Bei zu kurzem Intervall oder vielen offenen Tabs kann sie das Rate-Limit auslösen. [3]

Können 429-Fehler das SEO-Ranking beschädigen? Ja, wenn Googlebot regelmäßig 429-Antworten erhält, kann das die Crawl-Rate reduzieren und das Ranking verschlechtern. Kurzfristige, seltene 429-Fehler sind weniger kritisch als dauerhafte Sperren. [6]

Welches Plugin empfiehlt sich für Rate-Limit-Konfiguration in WordPress? „Wordfence Security“ für umfassenden Schutz, „Limit Login Attempts Reloaded“ speziell für Login-Schutz, und „Heartbeat Control“ für die Heartbeat-API-Drosselung. Alle drei ergänzen sich gut. [4]

Was tun, wenn die Ursache nicht klar ist? Logs sichern, alle Änderungen dokumentieren und professionelle Hilfe in Anspruch nehmen. Stundenlanges Trial-and-Error kann den Fehler verschlimmern, besonders wenn WooCommerce oder wichtige API-Integrationen betroffen sind.

Fazit: WordPress Fehler 429 Too Many Requests richtig beheben

Der WordPress Fehler 429 Too Many Requests ist lösbar, aber nur, wenn man den richtigen Verursacher kennt. Die wichtigsten Schritte zusammengefasst:

Diagnose zuerst: Response-Header, Server-Logs und CDN-Events prüfen, bevor etwas geändert wird.
Ebene identifizieren: Hosting-Server, CDN/WAF oder WordPress-Plugin, jede Ebene braucht eine andere Lösung.
Nie komplett deaktivieren: Rate-Limiting ist Sicherheitsinfrastruktur. Anpassen ja, abschalten nein.
Whitelists vor Lockerung: Legitime Bots, Monitoring-Dienste und API-Integrationen explizit freischalten.
Testen nach jeder Änderung: Google Search Console, Uptime-Monitor und manuelle Tests zeigen, ob die Konfiguration stimmt.

Wer nach der Diagnose feststellt, dass das Problem tiefer liegt, etwa durch einen Plugin-Konflikt, einen Hack oder eine Fehlkonfiguration nach einem Update, findet beim WordPress Reparatur-Service von WP-Repair schnelle, professionelle Hilfe. Die Ersteinschätzung ist kostenlos, und mit über 890 geretteten Websites und 20+ Jahren Erfahrung kennt Kay Jaeger und sein Team praktisch jeden Fehler, der in WordPress auftauchen kann.

Sofort-Hilfe erhalten: 0 23 32 – 91 44 44 oder sos@wp-repair.de