WordPress vor DDoS-Angriffen schützen: Was wirklich hilft

Ein DDoS-Angriff (Distributed Denial of Service) überflutet deine WordPress-Seite mit so vielen gleichzeitigen Anfragen aus tausenden gekaperten Rechnern, dass der Server überlastet und die Website für echte Besucher unerreichbar wird. Der wirksamste Schutz ist ein vorgeschaltetes CDN mit Web Application Firewall (etwa Cloudflare), das bösartigen Traffic abfängt, bevor er deinen Server überhaupt erreicht.

Das Wichtigste in Kürze

DDoS-Angriffe lassen sich auf WordPress-Ebene allein nicht abwehren – der Schutz muss vor dem Server ansetzen.
Die stärkste Einzelmaßnahme: ein CDN/Reverse-Proxy mit WAF (Cloudflare, Sucuri) plus Rate-Limiting.
Gutes, skalierbares Hosting und aggressives Caching reduzieren die Angriffsfläche erheblich.
Security-Plugins helfen gegen Brute-Force und Layer-7-Müll – sie ersetzen aber keine Netzwerk-Abwehr.
Im akuten Fall zählt jede Minute: Cloudflare „Under Attack“-Modus aktivieren, Hoster informieren, Logs sichern.

Was ist ein DDoS-Angriff?

DDoS steht für Distributed Denial of Service – also eine verteilte Dienstblockade. Anders als bei einem klassischen DoS-Angriff, der von einer einzelnen Quelle ausgeht, kommen die Anfragen bei einem DDoS-Angriff gleichzeitig von hunderten bis hunderttausenden Geräten. Diese Geräte sind meist Teil eines Botnetzes: gekaperte Computer, Router, IoT-Kameras oder ungepatchte Server, die ohne Wissen ihrer Besitzer ferngesteuert werden.

Das Ziel ist simpel: Die Angreifer wollen deine Website oder deinen Server so stark auslasten, dass legitime Besucher keine Verbindung mehr bekommen. Es wird also nicht eingebrochen und nichts gestohlen – die Seite wird schlicht „dichtgemacht“. Man unterscheidet grob drei Ebenen:

Volumetrische Angriffe (Layer 3/4): Die Leitung wird mit reinem Datenmüll geflutet (UDP-Floods, SYN-Floods, DNS-Amplification). Gemessen in Gigabit pro Sekunde.
Protokoll-Angriffe: Sie zielen auf Schwächen im TCP/IP-Stack und binden Server-Ressourcen über halb offene Verbindungen.
Anwendungs-Angriffe (Layer 7): Die heimtückischste Variante. Hier werden gezielt „teure“ WordPress-Seiten aufgerufen – die Suche, die Login-Seite, xmlrpc.php oder dynamische Filterseiten – mit scheinbar normalen Anfragen, die den PHP- und Datenbank-Prozess massiv belasten.

Gerade Layer-7-Angriffe sind für WordPress-Betreiber das größte Problem, weil sie wie echter Traffic aussehen und schon mit erstaunlich wenigen Anfragen pro Sekunde einen schlecht gecachten Shop oder Blog in die Knie zwingen.

Warum trifft es ausgerechnet WordPress so oft? Das CMS betreibt einen großen Teil aller Websites weltweit und ist damit ein lohnendes, gut bekanntes Ziel. Angreifer kennen die typischen Schwachstellen auswendig: die offene Login-Seite, die XML-RPC-Schnittstelle, ungepatchte Plugins und dynamische Seiten, die bei jedem Aufruf die Datenbank befragen. Hinzu kommt, dass viele WordPress-Seiten auf günstigem Shared-Hosting ohne ernsthafte Abwehr laufen. Das macht sie zu einem dankbaren Übungsziel – nicht selten ist ein DDoS-Angriff auch nur das Ablenkungsmanöver, während im Hintergrund ein Login-Bruteforce läuft.

TippEin DDoS-Angriff ist kein Hack im eigentlichen Sinn. Wenn deine Seite langsam wird, aber Inhalte unverändert sind, deutet das eher auf DDoS hin. Sind dagegen Inhalte verändert, Spam-Links eingeschleust oder Admin-Zugänge weg, geht es um einen Hack – dann hilft dir unsere Anleitung für gehackte WordPress-Seiten weiter.

Wie erkennt man einen DDoS-Angriff? Die typischen Symptome

Das Tückische: Ein DDoS-Angriff fühlt sich zunächst an wie ein ganz normaler Performance-Engpass. Erst der Blick in die Server-Logs bringt Klarheit. Diese Anzeichen sollten dich hellhörig machen:

Plötzliche, drastische Verlangsamung ohne erkennbaren Grund – keine neue Kampagne, kein viraler Beitrag, trotzdem ist die Seite zäh oder gar nicht erreichbar.
HTTP-Fehler 502, 503 oder 504 häufen sich. Der Server oder ein vorgelagerter Proxy gibt auf.
Massiver Anstieg der Anfragen aus untypischen Regionen – etwa tausende Zugriffe aus Ländern, in denen du keine Kunden hast.
Auffällig viele Anfragen auf wenige Endpunkte, vor allem xmlrpc.php, wp-login.php, die interne Suche oder ?s=-Parameter.
CPU- und RAM-Auslastung am Anschlag im Hosting-Dashboard, oft begleitet von einer Warn-Mail des Hosters wegen überschrittener Ressourcen.
Gleichförmige User-Agents oder fehlende Referrer – Bot-Traffic sieht in den Logs oft unnatürlich uniform aus.

Ein guter erster Check ist die Live-Ansicht der Zugriffe (in Cloudflare oder im Hoster-Panel) und ein Blick in die access.log. Wiederholen sich dort dieselben IP-Bereiche oder Pfade im Sekundentakt, ist die Diagnose meist eindeutig.

AchtungVerwechsle einen Traffic-Peak durch echten Erfolg nicht mit einem Angriff. Ein gut platzierter Presse-Artikel oder ein TikTok-Video kann ähnliche Lastspitzen erzeugen. Der Unterschied: Echter Traffic kommt über verschiedene Quellen, Geräte und Seiten – ein Angriff konzentriert sich auf wenige Endpunkte und zeigt unnatürliche Muster.

Welche Schutzmaßnahmen wirklich helfen

Die unbequeme Wahrheit zuerst: Du kannst einen ernsthaften DDoS-Angriff nicht innerhalb von WordPress stoppen. Wenn die Anfragen erst einmal deinen PHP-Prozess erreichen, ist es zu spät – der Schaden ist bereits entstanden. Wirksamer Schutz funktioniert nach dem Zwiebelprinzip: mehrere Ebenen, die Angriffe so früh wie möglich abfangen.

1. CDN mit Reverse-Proxy (Cloudflare & Co.)

Das ist die mit Abstand wichtigste Maßnahme. Ein Dienst wie Cloudflare (kostenlos im Einstiegstarif) schaltet sich zwischen Besucher und Server. Sämtlicher Traffic läuft zuerst durch das globale Netzwerk des Anbieters, der über riesige Kapazitäten verfügt, um volumetrische Angriffe einfach „aufzusaugen“. Deine echte Server-IP bleibt verborgen, statische Inhalte werden direkt aus dem CDN ausgeliefert, und bösartige Anfragen erreichen deinen Server gar nicht erst.

2. Web Application Firewall (WAF)

Eine WAF analysiert jede Anfrage auf Anwendungsebene und blockiert verdächtige Muster, bevor sie WordPress erreichen. Sie filtert bekannte Angriffssignaturen, SQL-Injection-Versuche und eben auch Layer-7-Floods. Cloudflare, Sucuri oder die WAF deines Hosters erkennen typische WordPress-Angriffsmuster – etwa exzessive Zugriffe auf xmlrpc.php – und sperren sie automatisch.

3. Rate-Limiting

Rate-Limiting begrenzt, wie viele Anfragen eine einzelne IP-Adresse in einem Zeitfenster stellen darf. Wer 200-mal pro Minute die Login-Seite aufruft, wird automatisch ausgebremst oder mit einer Challenge konfrontiert. Das stoppt zwar keine breit verteilten Botnetze allein, nimmt aber kleineren und mittleren Angriffen sofort die Wucht. Besonders wirksam ist es in Kombination mit einer WAF: Die Firewall erkennt das Muster, das Rate-Limit deckelt die Frequenz, und gemeinsam blocken sie genau die Endpunkte, die unter Last am teuersten werden.

4. Gutes, skalierbares Hosting

Billig-Shared-Hosting ist bei DDoS ein Totalausfall – ein einziger Angriff legt den ganzen geteilten Server lahm. Ordentliches Hosting bringt großzügige Ressourcen, serverseitige Abwehrmechanismen und im Idealfall bereits eine integrierte Schutzschicht mit. Solides Hosting ist die Basis jeder vernünftigen WordPress-Sicherheitsstrategie.

5. Aggressives Caching

Je weniger Anfragen tatsächlich PHP und die Datenbank auslösen, desto widerstandsfähiger ist deine Seite. Ein Full-Page-Cache liefert fertige HTML-Seiten aus, ohne WordPress überhaupt zu starten. Damit lassen sich auch Lastspitzen abfedern, die einen ungecachten Server längst überfordert hätten. Wie du Caching richtig aufsetzt, zeigen wir im Beitrag WordPress schneller machen – Performance und DDoS-Resilienz gehen hier Hand in Hand.

Die Schutzebenen im Überblick

Die folgende Tabelle zeigt, welche Ebene gegen welche Art von Angriff schützt und mit welchem Werkzeug du sie umsetzt:

Schutzebene	Wogegen es hilft	Tool / Umsetzung
CDN / Reverse-Proxy	Volumetrische Floods, IP-Verschleierung	Cloudflare, Sucuri, BunnyCDN
Web Application Firewall	Layer-7-Angriffe, bekannte Angriffssignaturen	Cloudflare WAF, Sucuri, Hoster-WAF
Rate-Limiting	Brute-Force, Login- und Such-Floods	Cloudflare Rules, Nginx `limit_req`
Caching	Server-Überlastung durch dynamische Aufrufe	WP Rocket, Server-Cache, CDN-Cache
Hosting-Infrastruktur	Ressourcen-Erschöpfung, Protokoll-Angriffe	Managed Hosting mit DDoS-Schutz
WordPress-Härtung	`xmlrpc.php`-Missbrauch, Bot-Logins	Security-Plugin, `.htaccess`-Regeln

Was Plugins können – und was nicht

Security-Plugins wie Wordfence, Solid Security oder All-In-One Security werden oft als DDoS-Lösung verkauft. Das stimmt nur zur Hälfte. Wichtig ist, ihre Rolle realistisch einzuordnen.

Was Plugins gut können:

Brute-Force-Schutz an der Login-Seite (Versuche pro IP begrenzen, Captcha erzwingen).
xmlrpc.php deaktivieren oder einschränken – ein beliebtes Layer-7-Einfallstor.
Application-Level-Firewall-Regeln gegen bekannte Angriffsmuster.
Verdächtige IPs erkennen, protokollieren und temporär sperren.
Datei-Integrität überwachen und Schwachstellen melden.

Was Plugins prinzipbedingt nicht können:

Volumetrische Angriffe abwehren. Wenn die Leitung mit 50 Gbit/s geflutet wird, ist der Server längst überlastet, bevor PHP das Plugin überhaupt lädt.
Den Server entlasten – jede vom Plugin geprüfte Anfrage verbraucht selbst Ressourcen. Bei einem großen Angriff kann ein Security-Plugin die Last sogar erhöhen.
Deine Server-IP verbergen. Das schafft nur ein vorgeschaltetes CDN.

Beispiel aus der Praxis: Ein Online-Magazin meldete sich bei uns, weil die Seite trotz Wordfence mehrmals täglich zusammenbrach. Die Auswertung zeigte: Ein Botnetz feuerte zehntausende Anfragen pro Minute auf die WordPress-Suche. Das Plugin „arbeitete“ pflichtbewusst jede einzelne ab – und trieb die CPU-Last damit erst recht nach oben. Erst nachdem wir Cloudflare mit Rate-Limiting davorschalteten und die Suche cachebar machten, war Ruhe. Die Last erreichte den Server gar nicht mehr.

Die Lehre daraus: Plugins sind eine wertvolle Ergänzung auf der WordPress-Ebene, aber niemals die erste Verteidigungslinie. Diese gehört vor den Server.

Was tun während eines laufenden Angriffs?

Wenn es ernst wird und die Seite gerade unter Last zusammenbricht, zählt ein klarer Ablauf statt Panik. Diese Schritte solltest du in dieser Reihenfolge gehen:

Angriff bestätigen. Prüfe Server-Auslastung und Live-Logs. Konzentrieren sich die Anfragen auf wenige IPs, Länder oder Endpunkte? Dann ist es ein Angriff, kein normaler Traffic-Peak.
Cloudflare „I’m Under Attack“-Modus aktivieren. Falls du Cloudflare nutzt, ist das der schnellste Hebel. Jeder Besucher bekommt eine kurze JavaScript-Challenge, die Bots aussperrt, echte Nutzer aber durchlässt. Aktivierbar mit einem Klick im Dashboard.
Hoster kontaktieren. Guter Support kann auf Netzwerkebene filtern (Null-Routing einzelner IP-Bereiche), Geo-Sperren setzen oder zusätzliche Kapazität freigeben. Melde den Angriff sofort.
Auffällige Endpunkte sperren. xmlrpc.php und – falls nicht gebraucht – auch die XML-Sitemap-Endpunkte temporär per Firewall-Regel oder .htaccess blockieren.
Geo- und IP-Blocking gezielt einsetzen. Kommt der Großteil des Traffics aus einer Region ohne dein Publikum, sperre sie vorübergehend.
Logs sichern. Für die spätere Analyse und eine eventuelle Strafanzeige solltest du die relevanten Logfiles wegkopieren, bevor sie rotieren.

AchtungStarte den Server nicht panisch immer wieder neu. Ein Neustart unter laufendem Angriff bringt die Seite nur kurz zurück, bevor sie erneut zusammenbricht – und du verlierst dabei wertvolle Log-Daten. Stabilisiere zuerst die vorgelagerte Abwehr, dann den Server. Wenn du dich allein nicht sicher fühlst, hol dir WordPress-Soforthilfe – im Ernstfall zählt jede Minute.

Prävention: So machst du deine Seite dauerhaft widerstandsfähig

Der beste DDoS-Schutz ist der, der schon steht, bevor der erste Angriff kommt. Wer erst im Ernstfall anfängt, Cloudflare einzurichten, verliert Stunden. Diese Maßnahmen gehören zur soliden Grundausstattung jeder professionellen WordPress-Seite:

Cloudflare dauerhaft vorschalten – nicht erst im Notfall, sondern als Standard-Setup mit verborgener Server-IP.
WAF-Regeln und Rate-Limiting für die kritischen Endpunkte (wp-login.php, xmlrpc.php, Suche) dauerhaft aktiv halten.
xmlrpc.php deaktivieren, sofern du es nicht aktiv brauchst – ein Klassiker unter den Angriffsvektoren.
WordPress, Theme und Plugins aktuell halten. Veraltete Komponenten sind Einfallstore und machen deinen Server unnötig angreifbar.
Full-Page-Caching aktiviert lassen, damit Lastspitzen gar nicht erst auf PHP durchschlagen.
Monitoring einrichten, das dich bei Lastspitzen alarmiert – damit du nicht erst aus Kundenmails von der Störung erfährst.
Regelmäßige Backups, damit du im schlimmsten Fall schnell wieder sauber hochfahren kannst.

Genau dieses Rundum-Paket – Updates, Monitoring, Sicherheits-Härtung, Backups und im Bedarfsfall schnelle Reaktion – decken wir seit 2014 für mittlerweile über 299 Websites ab. Wer das nicht selbst im Blick behalten will, ist mit einem festen WordPress-Wartungsvertrag gut aufgehoben: Sicherheit ist bereits ab dem Pro-Paket für 37,50 € enthalten.

Häufige Fragen

Kann ich einen DDoS-Angriff komplett verhindern?

Vollständig verhindern lässt sich ein DDoS-Angriff nicht – jeder kann zum Ziel werden. Was du aber kontrollieren kannst, ist die Auswirkung. Mit einem vorgeschalteten CDN, einer WAF und Rate-Limiting fängst du die allermeisten Angriffe ab, bevor sie spürbaren Schaden anrichten. Ziel ist nicht „kein Angriff“, sondern „kein Ausfall trotz Angriff“.

Reicht das kostenlose Cloudflare-Paket aus?

Für die meisten kleinen und mittleren WordPress-Seiten ja. Der kostenlose Cloudflare-Tarif enthält bereits unbegrenzten Schutz gegen volumetrische Angriffe, eine Basis-WAF und den „Under Attack“-Modus. Für Shops oder stark frequentierte Seiten mit höherem Risiko lohnen sich die kostenpflichtigen Tarife mit erweiterten WAF-Regeln und Rate-Limiting.

Ist ein DDoS-Angriff dasselbe wie ein Hack?

Nein. Bei einem DDoS-Angriff wird nichts gestohlen oder verändert – die Seite wird nur überlastet und dadurch unerreichbar. Ein Hack bedeutet dagegen, dass jemand Zugriff erlangt, Inhalte manipuliert oder Schadcode einschleust. Beides erfordert unterschiedliche Reaktionen: Bei einem Hack hilft unsere Anleitung zu gehackten WordPress-Seiten.

Belastet ein Security-Plugin meinen Server bei einem Angriff zusätzlich?

Ja, das kann passieren. Da ein Plugin innerhalb von WordPress läuft, muss PHP für jede geprüfte Anfrage starten. Bei einem massiven Angriff kann das die Server-Last sogar erhöhen, statt sie zu senken. Deshalb gehört die erste Verteidigungslinie immer vor den Server – auf CDN- und Firewall-Ebene.

Deine nächsten Schritte

Fasse die wichtigsten Erkenntnisse in konkrete Maßnahmen – diese drei kannst du sofort angehen:

Cloudflare vorschalten: Richte den kostenlosen Tarif ein und verbirg deine Server-IP. Das ist die wirkungsvollste Einzelmaßnahme.
Angriffsvektoren schließen: Deaktiviere xmlrpc.php, falls du es nicht brauchst, und aktiviere Rate-Limiting für Login und Suche.
Caching und Monitoring prüfen: Stelle sicher, dass Full-Page-Caching aktiv ist und du bei Lastspitzen alarmiert wirst.

Du willst diese Schutzebenen nicht selbst aufsetzen und überwachen? Wir kümmern uns darum – inklusive Sicherheits-Härtung, Monitoring und schneller Reaktion im Ernstfall. Schreib uns an info@wordpresswartung.com oder stell direkt deine Schnellanfrage. Mehr über uns und unsere Pakete erfährst du auf der Startseite.