Die meisten gehackten Firmenwebsites wurden nicht gezielt angegriffen. Sie wurden von automatisierten Skripten gefunden, die das Netz nach bekannten Schwachstellen absuchen – und dann zufällig zuschlagen. Genau deshalb ist „Wir sind zu klein, um interessant zu sein“ das gefährlichste Argument in diesem Themenfeld.
Dieser Leitfaden zeigt fünfzehn konkrete Maßnahmen, mit denen Sie Ihre WordPress-Website absichern – priorisiert nach Wirkung, mit klarer Kennzeichnung, was Sie selbst erledigen können und wofür Sie technische Unterstützung brauchen. Dazu ein interaktives Härtungs-Cockpit, in dem Sie Ihren Ist-Stand direkt abhaken.
Die drei wirksamsten Maßnahmen zur WordPress-Sicherheit sind: zeitnahe Updates von Core, Plugins und Themes, Zwei-Faktor-Authentifizierung für alle Konten mit Administratorrechten und ein geprüftes Backup, das sich nachweislich zurückspielen lässt. Ergänzend kommen Plugin-Hygiene, Login-Schutz, gehärtete Konfiguration und eine Web Application Firewall hinzu. Der Grund für die Priorisierung: Laut dem Patchstack-Report „State of WordPress Security in 2026″ stecken rund 91 Prozent aller neu gemeldeten Schwachstellen in Plugins – nicht im WordPress-Kern.
Die Lage 2026: Warum Nachlässigkeit teurer geworden ist
Die Zahlen aus den jährlichen Auswertungen der Sicherheitsanbieter zeichnen ein deutliches Bild. Der Patchstack-Report „State of WordPress Security in 2026″ dokumentiert für das Vorjahr 11.334 neu gemeldete Schwachstellen im WordPress-Ökosystem – ein Zuwachs von rund 42 Prozent. Bemerkenswert ist die Verteilung: Nur eine Handvoll davon betraf den WordPress-Kern selbst.
Diese vier Zahlen verändern die Logik der Absicherung grundlegend. Wenn zwischen einer öffentlichen Meldung und dem ersten automatisierten Massenangriff im Median nur wenige Stunden liegen, reicht ein monatlicher Wartungstermin nicht mehr aus. Und wenn fast die Hälfte der Lücken zum Meldezeitpunkt noch gar keinen Patch hat, kann Aktualisieren allein niemals die vollständige Antwort sein.
Ein zweiter Datenpunkt macht deutlich, wie groß die Lücke zwischen Anspruch und Realität ist: Der Bericht „State of WordPress Security 2026″ von GuardingWP, der 424 bestätigte WordPress-Installationen aus über vierzig Branchen untersucht hat, kommt zu dem Ergebnis, dass 53 Prozent der Seiten mindestens ein Plugin mit einer bekannten, ungepatchten Schwachstelle betreiben. Weitere Befunde derselben Auswertung: 93,2 Prozent ohne moderne Sicherheits-Header, 55,9 Prozent mit nach außen sichtbarer WordPress-Version und 35,8 Prozent mit weiterhin offener XML-RPC-Schnittstelle.
Die Bereinigung ist selten der teuerste Teil. Teuer werden die Folgen: Ausfallzeit ohne Anfragen, der Verlust von Google-Rankings durch eine als schädlich markierte Domain, Meldepflichten nach der DSGVO bei betroffenen Personendaten und der Vertrauensschaden bei Kunden, die eine Warnmeldung im Browser gesehen haben. Wie eine Wiederherstellung im Ernstfall abläuft, beschreiben wir im Beitrag WordPress gehackt oder offline? Die ersten Schritte.
Das Härtungs-Cockpit: 15 Maßnahmen zum Abhaken
Haken Sie ab, was auf Ihrer Website bereits umgesetzt ist. Die Auswertung gewichtet nach Risiko – drei kritische Punkte wiegen schwerer als sechs kleine Verbesserungen. Über die Filter blenden Sie ein, was Sie gerade interessiert.
Härtungs-Cockpit
15 Maßnahmen · risikogewichtete Auswertung · keine Datenübertragung
Noch nichts abgehakt. Beginnen Sie mit den rot markierten Punkten – sie decken den größten Teil des realen Risikos ab.
Aktivieren Sie automatische Updates für Wartungs- und Sicherheitsreleases des Kerns sowie für unkritische Plugins. Größere Versionssprünge und alles, was das Frontend berührt, gehören zuerst auf eine Testumgebung. Der Rhythmus sollte wöchentlich sein, nicht monatlich.
Aktuelles Beispiel: WordPress 7.0.3 wurde am 6. August 2026 als Sicherheitsrelease veröffentlicht. Solche Releases sollten innerhalb von Tagen eingespielt sein, nicht innerhalb von Wochen.
Jedes Plugin, das Sie nicht brauchen, ist eine Angriffsfläche weniger. Deaktivierte Plugins sind dabei nicht sicher – der Code liegt weiterhin auf dem Server und kann unter Umständen aufgerufen werden. Löschen statt deaktivieren.
Prüfen Sie bei jedem verbliebenen Plugin: Wann kam das letzte Update? Wie viele aktive Installationen? Reagiert der Entwickler im Support-Forum? Ein Plugin ohne Update seit über einem Jahr gehört ersetzt.
Der zweite Faktor macht gestohlene oder erratene Passwörter praktisch wertlos. Für WordPress genügt ein etabliertes Plugin mit Zeitcode-Verfahren (TOTP), wie es auch Ihre Banking-App nutzt. Wichtig: für alle Konten mit Administrator- oder Redakteursrechten, nicht nur für Ihr eigenes.
Hinterlegen Sie Wiederherstellungscodes an einem sicheren Ort außerhalb der Website – sonst sperren Sie sich beim nächsten Handywechsel selbst aus.
Angreifer probieren nicht wahllos Zeichenfolgen durch. Sie nutzen Listen aus früheren Datenlecks. Ein Passwort, das Sie irgendwo anders schon einmal verwendet haben, ist deshalb unabhängig von seiner Länge unsicher.
Praktikabel wird das nur mit einem Passwortmanager: lange, zufällige Zeichenfolgen für jeden Zugang, im Team geteilt über eine gemeinsame Ablage statt per E-Mail oder Chat.
Wer nur Texte pflegt, braucht keine Administratorrechte. Vergeben Sie die Rolle „Redakteur“ oder „Autor“ und behalten Sie Administratorrechte einer möglichst kleinen Gruppe vor.
Ebenso wichtig: Zugänge ehemaliger Mitarbeiter, früherer Dienstleister oder von Testkonten konsequent löschen. Ein vergessener Admin-Zugang ist eine offene Tür, die niemand mehr beobachtet.
Begrenzen Sie die Anzahl fehlgeschlagener Anmeldeversuche pro IP-Adresse und Zeitfenster. Das stoppt den Großteil der automatisierten Versuche, bevor sie überhaupt gefährlich werden.
Sinnvolle Ergänzungen: eine Wartezeit nach mehreren Fehlversuchen, eine Benachrichtigung bei erfolgreicher Anmeldung aus einem neuen Land und – falls organisatorisch möglich – eine Zugriffsbeschränkung des Login-Bereichs auf bekannte IP-Adressen.
Die XML-RPC-Schnittstelle stammt aus einer Zeit, in der WordPress per Desktop-Software bedient wurde. Heute braucht sie kaum eine Firmenwebsite – sie wird aber gern für Anmelde-Angriffe im großen Stil genutzt, weil sich darüber viele Versuche in einer einzigen Anfrage bündeln lassen.
Laut der GuardingWP-Auswertung 2026 liefern immer noch 35,8 Prozent der untersuchten Installationen XML-RPC aus. Prüfen Sie vor dem Abschalten, ob Jetpack, eine App oder eine Schnittstelle darauf angewiesen ist.
Die WordPress-Version steht standardmäßig als Meta-Angabe im Quelltext – laut GuardingWP bei 55,9 Prozent der untersuchten Seiten. Für Angreifer ist das eine Einladung: Sie können gezielt nach Installationen mit bekannten Lücken suchen.
Ähnlich funktioniert die Benutzer-Auflistung über Autoren-Archive und Schnittstellen: Wer die Benutzernamen kennt, muss beim Anmeldeversuch nur noch das Passwort raten. Beides lässt sich mit wenigen Zeilen unterbinden – siehe die Konfigurations-Bausteine weiter unten.
Drei Einstellungen mit großer Wirkung: den Dateieditor im Backend abschalten, damit ein übernommenes Konto nicht direkt Schadcode in Theme-Dateien schreiben kann; die Fehlerausgabe im Livebetrieb deaktivieren, weil Fehlermeldungen Pfade und Versionen verraten; und die Sicherheitsschlüssel neu erzeugen, wenn ein Verdacht besteht – damit werden alle bestehenden Sitzungen ungültig.
Zusätzlich sollte das Tabellen-Präfix nicht der Standardwert sein und die Datenbank ein eigenes, nicht anderweitig verwendetes Passwort haben.
Als Faustregel gelten 644 für Dateien, 755 für Verzeichnisse und 640 oder restriktiver für die wp-config.php. Rechte wie 777 sind ein häufiger Fund bei kompromittierten Installationen – sie erlauben jedem Prozess auf dem Server das Schreiben.
Ebenso wichtig: Im Upload-Verzeichnis darf kein PHP ausgeführt werden. Andernfalls genügt eine unsauber geprüfte Datei-Uploadfunktion, um beliebigen Code auszuführen.
HTTP-Header wie Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy und eine Richtlinie gegen das Einbetten in fremde Rahmen kosten nichts und wehren eine ganze Klasse von Angriffen ab. Die GuardingWP-Auswertung fand sie bei nur 6,8 Prozent der geprüften Installationen.
Eine Content-Security-Policy ist der wirksamste, aber auch anspruchsvollste Header – sie sollte schrittweise und zunächst im Berichtsmodus eingeführt werden, sonst zerlegt sie Funktionen der Seite.
Eine PHP-Version außerhalb des Support-Zeitraums erhält keine Sicherheitsupdates mehr – unabhängig davon, wie gut WordPress selbst gepflegt ist. Prüfen Sie im Zustandsbericht des Backends, welche Version läuft, und heben Sie sie nach einem Test auf einer Kopie an.
Beim Hosting zählt weniger der Preis als die Trennung der Kundenumgebungen, die Verfügbarkeit von Staging und die Frage, wie schnell im Ernstfall jemand erreichbar ist.
Genau hier liegt die Antwort auf die 46 Prozent der Lücken, für die zum Meldezeitpunkt noch kein Update existiert. Eine spezialisierte Firewall kann eine Schutzregel ausrollen, bevor der Hersteller patcht – dieses Verfahren nennt sich virtuelles Patchen und schließt das gefährlichste Zeitfenster.
Ergänzend brauchen Sie Aufmerksamkeit: eine Benachrichtigung bei neu angelegten Administratorkonten, bei veränderten Kerndateien und bei ungewöhnlichen Anmeldungen. Sicherheit ohne Meldeweg ist nur ein Gefühl.
Seit WordPress 7.0 gibt es eine native Schnittstelle für KI-Dienste im Kern. Damit landen abrechenbare API-Schlüssel im Administrationsbereich – ein Ziel, das es vorher in dieser Form nicht gab, und auf das Sicherheitsforscher bereits ausdrücklich hingewiesen haben.
Konsequenz: API-Schlüssel möglichst als Serverkonstante hinterlegen statt in der Datenbank, Ausgabelimits beim Anbieter setzen, Nutzung überwachen und Schlüssel regelmäßig wechseln. Dasselbe gilt für Zugangsdaten von Zahlungs- und Versanddiensten in Onlineshops.
Drei Kopien der Daten, auf zwei verschiedenen Medien, davon eine an einem anderen Ort. Entscheidend ist der letzte Punkt: Ein Backup, das auf demselben Server liegt wie die Website, ist bei einer Kompromittierung des Servers mit betroffen.
Der Punkt, an dem die meisten scheitern, ist nicht die Sicherung, sondern die Rückspielung. Testen Sie mindestens zweimal im Jahr, ob sich aus dem Backup tatsächlich eine funktionierende Seite herstellen lässt – idealerweise auf einer separaten Testumgebung.
Für diesen Filter gibt es aktuell keine Einträge – alle Maßnahmen dieser Kategorie sind bereits abgehakt.
Fertige Konfigurations-Bausteine
Die folgenden Blöcke setzen die technischen Maßnahmen 8 bis 11 um. Kopieren Sie den passenden Baustein, legen Sie vorher eine Sicherung der jeweiligen Datei an und prüfen Sie die Website nach jeder Änderung.
/* Dateieditor im Backend deaktivieren */
define( 'DISALLOW_FILE_EDIT', true );
/* Installation und Updates über das Backend unterbinden
(nur setzen, wenn Updates per Deployment oder WP-CLI laufen) */
// define( 'DISALLOW_FILE_MODS', true );
/* Fehlerausgabe im Livebetrieb abschalten */
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
/* Automatische Updates für Wartungs- und Sicherheitsreleases */
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
/* Nur über HTTPS anmelden und administrieren */
define( 'FORCE_SSL_ADMIN', true );
/* Beitragsrevisionen begrenzen und Papierkorb kürzen */
define( 'WP_POST_REVISIONS', 10 );
define( 'EMPTY_TRASH_DAYS', 14 );<?php
/* WordPress-Version aus Quelltext und Feeds entfernen */
remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );
/* Versionsangabe an Skript- und Stil-URLs entfernen */
add_filter( 'style_loader_src', 'mc_strip_ver', 9999 );
add_filter( 'script_loader_src', 'mc_strip_ver', 9999 );
function mc_strip_ver( $src ) {
return $src ? remove_query_arg( 'ver', $src ) : $src;
}
/* Benutzer-Auflistung über ?author=1 unterbinden */
add_action( 'template_redirect', function () {
if ( ! is_admin() && isset( $_GET['author'] ) ) {
wp_redirect( home_url(), 301 );
exit;
}
} );
/* Benutzerliste der REST-API für Gäste sperren */
add_filter( 'rest_endpoints', function ( $endpoints ) {
if ( ! is_user_logged_in() ) {
unset( $endpoints['/wp/v2/users'] );
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
}
return $endpoints;
} );
/* Einheitliche Fehlermeldung beim Login */
add_filter( 'login_errors', function () {
return 'Anmeldedaten sind nicht korrekt.';
} );# wp-config.php vor direktem Zugriff schützen
<Files wp-config.php>
Require all denied
</Files>
# Verzeichnisauflistung deaktivieren
Options -Indexes
# XML-RPC sperren (vorher Abhängigkeiten prüfen!)
<Files xmlrpc.php>
Require all denied
</Files>
# Keine PHP-Ausführung im Upload-Verzeichnis
# (als eigene .htaccess in /wp-content/uploads/ ablegen)
# <FilesMatch "\.(php|php\d|phtml|phar)$">
# Require all denied
# </FilesMatch>
# Zugriff auf sensible Dateien unterbinden
<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php|\.env|\.git.*)">
Require all denied
</FilesMatch><IfModule mod_headers.c>
# HTTPS erzwingen (erst setzen, wenn HTTPS überall sauber läuft)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Kein Erraten von Dateitypen
Header always set X-Content-Type-Options "nosniff"
# Einbetten in fremde Seiten unterbinden
Header always set Content-Security-Policy "frame-ancestors 'self'"
# Sparsame Weitergabe der Herkunft
Header always set Referrer-Policy "strict-origin-when-cross-origin"
# Nicht benötigte Browser-Funktionen abschalten
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>Diese Bausteine sind erprobte Standardlösungen, aber jede Installation ist anders. Ein gesperrtes xmlrpc.php kann eine App-Anbindung lahmlegen, eine zu strenge Content-Security-Policy blockiert Schriften oder Karten, und ein DISALLOW_FILE_MODS verhindert Updates über das Backend. Legen Sie vor jeder Änderung eine Sicherung an, arbeiten Sie nach Möglichkeit auf einer Testumgebung und prüfen Sie danach Startseite, Formulare und Checkout.
Plugin-Hygiene: die wirksamste Einzelmaßnahme
Wenn rund neun von zehn Schwachstellen aus Plugins stammen, ist die Auswahl und Pflege der Erweiterungen kein Randthema, sondern der Kern der Absicherung. Diese fünf Fragen sollten Sie vor jeder Installation beantworten:
| Prüfpunkt | Gutes Zeichen | Warnsignal |
|---|---|---|
| Letztes Update | Innerhalb der letzten drei Monate | Über ein Jahr ohne Aktualisierung |
| Kompatibilität | Für die aktuelle WordPress-Version getestet | Hinweis auf eine deutlich ältere Version |
| Verbreitung | Hohe Zahl aktiver Installationen | Sehr wenige Installationen bei kritischer Funktion |
| Support | Entwickler antwortet im Forum | Unbeantwortete Anfragen über Monate |
| Historie | Schwachstellen wurden schnell behoben | Wiederholte, spät geschlossene Lücken |
Ein Detail aus der Patchstack-Auswertung überrascht viele: Kostenpflichtige Erweiterungen sind nicht automatisch sicherer. In der Telemetrie des Anbieters zeigten Premium-Komponenten sogar deutlich häufiger tatsächlich ausgenutzte Schwachstellen als kostenlose. Der Preis ist kein Qualitätsmerkmal – die Pflege ist es. Bei der Auswahl für Onlineshops kommt hinzu, dass jede Erweiterung im Checkout auch ein rechtliches Risiko trägt; dazu passt unser Systemvergleich für Onlineshops.
Updates einspielen, ohne die Website zu gefährden
Der häufigste Grund, warum Betriebe Updates aufschieben, ist die Angst vor einer kaputten Seite. Diese Sorge ist berechtigt – aber die Lösung heißt nicht „später“, sondern „getestet“.
- Trennen Sie die Kategorien. Sicherheits- und Wartungsreleases des Kerns können automatisch laufen. Große Versionssprünge, Page-Builder und Shop-Erweiterungen gehören zuerst auf eine Kopie.
- Nutzen Sie eine Testumgebung. Gute Hoster bieten Staging auf Knopfdruck. Dort einspielen, Startseite, Formulare, Checkout und Mobilansicht prüfen, dann live übertragen.
- Aktualisieren Sie in kleinen Schritten. Fünf Plugins auf einmal einzuspielen macht die Fehlersuche unnötig schwer.
- Sichern Sie vorher. Ein Backup unmittelbar vor dem Update ist die Rückfahrkarte, die Sie in neun von zehn Fällen nicht brauchen – und im zehnten Fall rettet.
- Planen Sie den Termin. Nicht Freitagnachmittag, nicht vor dem Urlaub. Updates gehören in ein Zeitfenster, in dem jemand nachschauen kann.
WordPress 7.1 ist für den 19. August 2026 angekündigt. Dieses Release wechselt technisch auf React 19, was das Risiko für ältere Plugins und individuell entwickelte Blöcke erhöht. Für Firmenwebsites bedeutet das: nicht am Erscheinungstag aktualisieren, sondern erst nach einem Test auf einer Kopie und nachdem die eingesetzten Erweiterungen nachgezogen haben.
Neue Angriffsfläche: KI-Schnittstellen im WordPress-Kern
Mit WordPress 7.0 ist eine native Schnittstelle für KI-Dienste in den Kern eingezogen. Plugins und Themes können darüber Anbieter wie OpenAI, Google oder Anthropic nutzen, ohne jeweils eigene Anbindungen zu bauen. Für Betreiber ist das praktisch – und es schafft eine Angriffsfläche, die es in dieser Form vorher nicht gab.
Der Punkt: Wo bisher ein übernommenes Administratorkonto vor allem bedeutete, dass jemand Inhalte manipulieren konnte, liegen dort jetzt möglicherweise abrechenbare API-Schlüssel. Sicherheitsforscher haben bereits öffentlich darauf hingewiesen, dass genau diese Schlüssel zum Ziel werden. Der Schaden entsteht dabei nicht auf der Website, sondern auf der Rechnung des Anbieters.
Drei praktische Konsequenzen: Schlüssel möglichst als Konstante in der Serverkonfiguration hinterlegen statt in der Datenbank, beim Anbieter ein Ausgabelimit setzen und die Nutzung regelmäßig kontrollieren. Und – das gilt ohnehin – der Kreis der Administratoren sollte so klein wie möglich sein.
Das Backup, das im Ernstfall wirklich funktioniert
Fast jede Website hat ein Backup. Deutlich weniger Betriebe wissen, ob es funktioniert. Diese vier Kriterien trennen eine echte Sicherung von einem falschen Sicherheitsgefühl:
| Kriterium | Warum es zählt |
|---|---|
| Externer Speicherort | Liegt die Sicherung auf demselben Server, ist sie bei dessen Kompromittierung mit betroffen. |
| Ausreichende Historie | Schadcode bleibt oft wochenlang unentdeckt. Wer nur sieben Tage aufbewahrt, sichert am Ende nur die infizierte Version. |
| Vollständigkeit | Dateien und Datenbank. Eine Sicherung ohne Datenbank ist bei WordPress praktisch wertlos. |
| Getestete Rückspielung | Der einzige Beweis, dass ein Backup funktioniert, ist eine erfolgreiche Wiederherstellung – nicht die grüne Meldung im Dashboard. |
Für Onlineshops kommt eine Besonderheit hinzu: Bestellungen entstehen laufend. Ein Rücksprung auf den Stand von gestern bedeutet, dass die Bestellungen eines Tages fehlen. Shops brauchen deshalb engere Sicherungsintervalle und einen definierten Umgang mit Bestelldaten – ein Thema, das wir bei der Onlineshop-Erstellung von Anfang an mit einplanen.
Notfallplan: die ersten 60 Minuten bei Verdacht
Wenn Warnmeldungen im Browser erscheinen, fremde Inhalte auftauchen oder Google die Seite als schädlich markiert, zählt die Reihenfolge. Diese fünf Schritte verhindern, dass aus einem Vorfall ein Datenverlust wird.
Nichts überschreiben
Kein voreiliges Neuinstallieren, kein Löschen verdächtiger Dateien. Spuren sind später wichtig, um den Einstiegspunkt zu finden – sonst schließt sich die Lücke nie.
Zustand sichern
Vollständige Kopie von Dateien und Datenbank anlegen, deutlich als „kompromittiert“ gekennzeichnet. Diese Kopie ist Ihre Beweislage und Ihr Rückfallpunkt.
Zugänge sperren
Alle Administratorpasswörter ändern, Datenbank- und Hosting-Zugänge erneuern, Sicherheitsschlüssel in der
wp-config.phpneu erzeugen. Damit fliegen bestehende Sitzungen von Angreifern heraus.Umfang klären
Wurden personenbezogene Daten berührt, greifen Meldepflichten nach der DSGVO mit engen Fristen. Diese Frage gehört an den Anfang, nicht ans Ende.
Sauber wiederherstellen
Auf einen nachweislich unbelasteten Stand zurücksetzen, die ausgenutzte Lücke schließen und erst dann wieder online gehen. Danach Google Search Console prüfen und eine Überprüfung anstoßen.
Den ausführlichen Ablauf inklusive Diagnose bei nicht erreichbarer Seite finden Sie in unserem Notfall-Ratgeber WordPress gehackt oder offline?. Wenn Sie kurzfristig Unterstützung brauchen, hilft unsere WordPress- und WooCommerce-Hilfe weiter.
Fünf verbreitete Irrtümer
| Aussage | Warum sie nicht trägt |
|---|---|
| „Wir sind zu klein, um interessant zu sein.“ | Angriffe laufen automatisiert. Skripte suchen nach Schwachstellen, nicht nach lohnenden Zielen. Die Größe des Unternehmens spielt dabei keine Rolle. |
| „WordPress ist unsicher, ein anderes CMS wäre besser.“ | Der Kern selbst weist sehr wenige Schwachstellen auf. Das Risiko entsteht aus Erweiterungen von Drittanbietern – ein Problem, das jedes System mit großem Ökosystem teilt. |
| „Ein Sicherheits-Plugin reicht.“ | Ein Plugin ersetzt weder Updates noch Backups noch saubere Zugangsverwaltung. Es ist eine Ergänzung, keine Lösung. |
| „Wir haben ein SSL-Zertifikat, also sind wir sicher.“ | HTTPS verschlüsselt die Übertragung. Gegen eine Lücke in einem Plugin oder ein erratenes Passwort richtet es nichts aus. |
| „Der Hoster kümmert sich darum.“ | Der Hoster sichert die Serverumgebung. Für WordPress, Plugins, Themes und Benutzerkonten sind in aller Regel Sie verantwortlich – ein Blick in den Vertrag lohnt sich. |
Häufige Fragen zur WordPress-Sicherheit
Wie oft sollte ich WordPress aktualisieren?
Sicherheitsrelevante Updates sollten innerhalb weniger Tage eingespielt werden. Als Rhythmus für die Kontrolle hat sich wöchentlich bewährt. Der Grund ist die Geschwindigkeit der Angreifer: Auswertungen für 2026 nennen einen Median von rund fünf Stunden zwischen der öffentlichen Meldung einer Schwachstelle und der ersten breiten automatisierten Ausnutzung.
Welches Sicherheits-Plugin ist das beste?
Die Frage ist weniger wichtig als die Konfiguration. Etablierte Lösungen bieten Firewall, Anmeldeschutz, Dateiüberwachung und Benachrichtigungen; entscheidend ist, dass die Meldungen tatsächlich bei jemandem ankommen und bearbeitet werden. Wichtiger als die Produktwahl sind Updates, Zwei-Faktor-Authentifizierung und ein geprüftes Backup.
Reicht ein Backup als Absicherung?
Nein. Ein Backup begrenzt den Schaden, verhindert ihn aber nicht. Ohne Schließen der ausgenutzten Lücke ist eine wiederhergestellte Seite innerhalb kurzer Zeit erneut betroffen. Zudem hilft ein Backup nur, wenn seine Historie weit genug zurückreicht – Schadcode bleibt oft wochenlang unentdeckt.
Soll ich die Login-Adresse ändern?
Das reduziert automatisierte Anmeldeversuche spürbar, ist aber kein echter Schutz – ein gezielter Angreifer findet die Adresse. Betrachten Sie es als Lärmreduktion, nicht als Sicherheitsmaßnahme. Wirksam sind Zwei-Faktor-Authentifizierung und eine Begrenzung der Anmeldeversuche.
Muss ich XML-RPC deaktivieren?
Wenn Sie die Schnittstelle nicht brauchen: ja. Sie wird häufig für gebündelte Anmeldeversuche genutzt. Prüfen Sie vorher, ob eine App, Jetpack oder eine externe Anbindung darauf zugreift – sonst brechen diese Funktionen ab.
Woran erkenne ich, dass meine Website kompromittiert wurde?
Typische Anzeichen sind Warnhinweise im Browser oder in der Google Search Console, unbekannte Administratorkonten, fremde Inhalte oder Weiterleitungen, plötzlich stark gestiegene Serverlast, ungewöhnlich veränderte Dateien im Verzeichnis und Beschwerden über Spam-Mails von Ihrer Domain. Auch ein unerklärlicher Einbruch bei den organischen Zugriffen kann ein Hinweis sein.
Lohnt sich ein Wartungsvertrag?
Für Unternehmen, die keine eigene technische Betreuung haben, meist ja. Die entscheidenden Maßnahmen – wöchentliche Updates mit Test, Überwachung, geprüfte Backups und schnelle Reaktion im Vorfall – sind laufende Tätigkeiten, keine einmalige Einrichtung. Wichtig ist, dass im Vertrag steht, was tatsächlich geleistet wird und wie schnell im Ernstfall reagiert wird.
Fazit: Wenige Maßnahmen decken den Großteil des Risikos ab
Sicherheit im WordPress-Umfeld ist selten eine Frage von Spezialwissen, sondern von Verlässlichkeit. Wer Updates zeitnah einspielt, den Kreis der Administratoren klein hält, Zwei-Faktor-Authentifizierung nutzt und ein Backup besitzt, das er tatsächlich schon einmal zurückgespielt hat, hat den überwiegenden Teil des realen Risikos abgedeckt.
Der Rest ist Feinarbeit: gehärtete Konfiguration, Sicherheits-Header, geschlossene Schnittstellen, virtuelles Patchen. Wertvoll – aber nur, wenn die Grundlagen stehen. Wenn Ihr Ergebnis im Cockpit weiter oben unter siebzig Prozent liegt, fangen Sie nicht bei den Feinheiten an, sondern bei den vier rot markierten Punkten.
Sicherheitscheck für Ihre WordPress-Website
Wir prüfen Version, Plugins, Konfiguration, Header und Backup-Situation Ihrer Website und sagen Ihnen konkret, wo Handlungsbedarf besteht – verständlich und ohne Panikmache. Persönlich, aus Essen-Steele.
