WordPress Sicherheits-Check selbst durchführen: 15-Punkte-Checkliste

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

WordPress ist das meistgenutzte CMS der Welt und deshalb auch ein bevorzugtes Ziel für automatisierte Angriffe. Angreifer suchen nicht gezielt Ihre Website aus, sondern scannen das Netz nach bekannten Schwachstellen: veralteten Plugin-Versionen, offenen Login-Endpunkten, unsicheren Dateirechten. Wer diese Lücken kennt und schließt, ist gegen den Großteil der realen Bedrohungen geschützt. Dieser Artikel gibt Ihnen eine strukturierte Checkliste mit 15 Prüfpunkten, die Sie als Betreiber ohne technischen Hintergrund in etwa 30 Minuten selbst durcharbeiten können.

Warum ein regelmäßiger Sicherheits-Check sinnvoll ist

WordPress-Installationen veralten schnell. Ein Plugin, das heute aktuell und sicher ist, kann in vier Wochen eine kritische Sicherheitslücke enthalten, die aktiv ausgenutzt wird. Dasselbe gilt für Themes und WordPress selbst. Wer keine Routine für die regelmäßige Überprüfung hat, merkt das oft erst, wenn die Website gehackt, gesperrt oder von Google auf eine Warnliste gesetzt wurde.

Die gute Nachricht: Die meisten WordPress-Installationen scheitern nicht an ausgefeilten Angriffen, sondern an grundlegenden Versäumnissen. Updates nicht eingespielt, Standardpasswörter nicht geändert, der Datei-Editor noch aktiv. Das sind keine versteckten Schwachstellen, sie lassen sich ohne Programmierkenntnisse schließen.

Das OWASP-Projekt, das die kritischsten Sicherheitsrisiken für Webanwendungen dokumentiert, benennt veraltete Komponenten, fehlerhafte Zugriffskontrolle und Fehlkonfigurationen als wiederkehrende Hauptursachen. Alle drei betreffen typische WordPress-Installationen direkt.

Die 15-Punkte-Checkliste für Ihren WordPress Sicherheits-Check

Die folgende Checkliste ist so aufgebaut, dass Sie von oben nach unten vorgehen können. Beginnen Sie mit den ersten fünf Punkten: Sie haben den größten Effekt und sind am schnellsten erledigt.

• 1. Core, Themes und Plugins aktuell halten. Öffnen Sie Dashboard > Aktualisierungen. Alles, was dort rot markiert ist, wird von Angreifern aktiv auf bekannte Lücken geprüft. Spielen Sie Updates zuerst auf einer Staging-Umgebung oder direkt mit frischem Backup ein. Automatische Core-Updates für Minor-Releases sind sinnvoll und lassen sich in der wp-config.php mit define('WP_AUTO_UPDATE_CORE', 'minor'); erzwingen.
• 2. Nicht genutzte Plugins und Themes entfernen. Deaktivierte Plugins und inaktive Themes sind trotzdem auf dem Server vorhanden und können Schwachstellen enthalten. Löschen Sie alles, was Sie nicht aktiv benötigen. Das Twenty-Twenty-One-Theme, das seit der Installation schlummert, ist genau das, was geprüft werden sollte.
• 3. Starke Passwörter für alle Konten setzen. Das gilt nicht nur für den Admin-Account, sondern für jeden WordPress-Benutzer, für den FTP-Zugang und für die Datenbank. Ein sicheres Passwort hat mindestens 16 Zeichen und besteht aus einer Mischung aus Buchstaben, Zahlen und Sonderzeichen. WordPress zeigt beim Setzen eines Passworts eine Stärkeangabe an, achten Sie auf „Stark“. Unter Benutzer finden Sie alle Konten und können jeweils ein neues Passwort erzwingen. Details zur Passwortstrategie und zu Benutzerrollen finden Sie im Artikel WordPress Login absichern.
• 4. Zwei-Faktor-Authentifizierung (2FA) aktivieren. Ein kompromittiertes Passwort reicht dann allein nicht mehr für den Login. 2FA lässt sich mit Plugins wie Two Factor einrichten, dem offiziellen WordPress-Plugin der Core-Entwickler. Aktivieren Sie 2FA mindestens für alle Benutzer mit Administrator-Rolle.
• 5. Admin-Benutzernamen prüfen. Der Benutzername „admin“ ist der erste, den Brute-Force-Scripts ausprobieren. Wenn Ihr Hauptadmin-Account noch so heißt, legen Sie einen neuen Benutzer mit Administrator-Rolle und einem anderen Namen an, weisen Sie alle Beiträge um und löschen Sie dann den alten „admin“-Account.
• 6. Login-Schutz gegen Brute-Force-Angriffe einrichten. Ohne Schutz kann ein Skript unbegrenzt Passwörter ausprobieren. Plugins wie Limit Login Attempts Reloaded sperren eine IP nach einer konfigurierbaren Anzahl fehlgeschlagener Versuche. Wie Brute-Force-Angriffe ablaufen und welche Gegenmaßnahmen über das Plugin hinaus sinnvoll sind, beschreibt der Artikel WordPress Brute Force: den Login absichern.
• 7. HTTPS erzwingen und SSL-Zertifikat prüfen. Rufen Sie Ihre Website mit http:// auf und prüfen Sie, ob automatisch auf https:// umgeleitet wird. Ein ungültiges oder abgelaufenes Zertifikat zeigt der Browser mit einer Warnmeldung an. In WordPress müssen die WordPress-Adresse und die Site-Adresse unter Einstellungen > Allgemein mit https:// eingetragen sein. Details zu Security-Headern finden Sie im Artikel SSL, HTTPS und Sicherheitsheader einfach erklärt.
• 8. Dateirechte überprüfen. Falsch gesetzte Dateirechte machen es Angreifern leicht, Dateien zu ändern oder auszulesen. Die offizielle WordPress-Dokumentation empfiehlt: Verzeichnisse auf 755, Dateien auf 644, die wp-config.php auf 440 oder 400. Fragen Sie Ihren Hoster, ob er die Dateirechte für Sie prüfen kann, die meisten Managed-WordPress-Hoster bieten das an.
• 9. XML-RPC deaktivieren, soweit nicht benötigt. XML-RPC ist eine ältere Schnittstelle, über die WordPress ferngesteuert werden kann und die häufig für Brute-Force-Angriffe missbraucht wird. Wenn Sie weder die mobile WordPress-App noch das Jetpack-Pingback-Feature verwenden, können Sie XML-RPC vollständig sperren. Das gelingt entweder per .htaccess-Regel oder über ein Plugin. Prüfen Sie zunächst, ob Ihre aktuellen Plugins oder Themes auf XML-RPC angewiesen sind. Prüfen Sie im selben Zug die REST-API: Der Endpunkt /wp-json/wp/v2/users/ gibt standardmäßig Benutzernamen preis, die Angreifer für gezielte Logins nutzen. Ein Sicherheits-Plugin oder eine Filterregel kann diese Ausgabe einschränken.
• 10. Debug-Modus deaktivieren. Wenn WP_DEBUG auf true steht, können Fehlermeldungen mit Pfadangaben und Datenbankstruktur für jeden Besucher sichtbar sein. Das ist bei der Entwicklung praktisch, auf einer Live-Website aber ein Sicherheitsrisiko. Prüfen Sie Ihre wp-config.php: define('WP_DEBUG', false); muss gesetzt sein.
• 11. Backups vorhanden und getestet. Ein Backup, das nicht wiederhergestellt werden kann, ist keins. Prüfen Sie, wann das letzte Backup erstellt wurde, wo es liegt (nicht nur auf demselben Server) und ob Sie es schon einmal testweise eingespielt haben. Details zur Backup-Strategie, zu geeigneten Plugins und zu DSGVO-konformen Speicherorten finden Sie in den Artikeln WordPress Backup automatisieren und DSGVO Backup: Wo Ihre Sicherungen liegen dürfen.
• 12. Datei-Editor im Backend deaktivieren. Über Darstellung > Theme-Editor und Plugins > Plugin-Editor lassen sich PHP-Dateien direkt im Browser bearbeiten. Wer diesen Editor missbraucht, kann beliebigen Code auf Ihrer Website ausführen. Deaktivieren Sie ihn über die wp-config.php mit einer einzigen Zeile, Details stehen im Profi-Block unten.
• 13. Security-Header prüfen. HTTP-Sicherheitsheader weisen den Browser an, bestimmte Angriffsvektoren (Clickjacking, Cross-Site-Scripting) zu blockieren. Ob Ihre Website die wichtigsten Header sendet, lässt sich mit dem kostenlosen Tool securityheaders.com in Sekunden prüfen. Wie Header technisch gesetzt werden, erklärt der Profi-Block weiter unten.
• 14. Benutzerrollen prüfen. Gehen Sie zu Benutzer und schauen Sie, wer welche Rolle hat. Jeder Account mit Administrator-Rechten ist ein potenzieller Angriffspunkt. Frühere Mitarbeiter, Test-Accounts oder der Hoster-Testzugang vom Einrichten sollten gelöscht oder auf Abonnent zurückgestuft sein. Das Prinzip der minimalen Rechte gilt auch für WordPress: Jeder Benutzer bekommt nur die Rechte, die er wirklich braucht.
• 15. Monitoring und Integritätscheck. Haben Sie eine Benachrichtigung, wenn etwas an Ihrer Website nicht stimmt, ein Zertifikat abläuft, die Website nicht erreichbar ist, verdächtige Logins auftauchen? Einfache Uptime-Monitore wie UptimeRobot sind kostenlos. Für die Dateiintegritätsprüfung und erweiterte Sicherheitsüberwachung lesen Sie den Artikel Sicherheits-Plugins für WordPress: Welche wirklich helfen.

// Datei-Editor im Backend deaktivieren
define( 'DISALLOW_FILE_EDIT', true );

// Datei-Modifikation komplett sperren (auch Plugin/Theme-Installation)
define( 'DISALLOW_FILE_MODS', true );

// Debug-Modus auf Live-Websites deaktivieren
define( 'WP_DEBUG', false );

// Automatische Minor-Updates aktivieren
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"
</IfModule>

Praxisbeispiel aus einem echten Projekt

In einem Kundenprojekt haben wir eine WordPress-Installation übernommen, die seit knapp zwei Jahren nicht mehr systematisch gepflegt worden war. Die erste Prüfung zeigte: sieben Plugins mit veralteten Versionen, darunter zwei, für die es aktive Exploits gab. Der Admin-Account hieß noch „admin“ und hatte kein 2FA. Der Datei-Editor im Backend war aktiv. Die wp-config.php enthielt define('WP_DEBUG', true); und sendete damit PHP-Fehlermeldungen mit vollständigen Serverpfaden an alle Besucher.

Besonders auffällig: Zwei Plugins waren zwar im Dashboard deaktiviert, aber nicht gelöscht. Eines davon enthielt eine bekannte SQL-Injection-Schwachstelle in einer veralteten Version. Deaktiviert, aber vorhanden und ausführbar.

Alle 15 Punkte der Checkliste waren innerhalb von zwei Stunden abgearbeitet: Updates, Aufräumen, Passwörter, 2FA, Datei-Editor sperren, Debug aus. Keine tiefen technischen Eingriffe, keine neuen Systeme. Nur konsequentes Durcharbeiten einer Liste. Danach bestätigte ein erneuter Scan keine kritischen Schwachstellen mehr.

Das ist kein Extremfall. Es ist der typische Zustand einer gepflegten KMU-Website nach anderthalb Jahren ohne strukturierte Wartung.

Überblick: Was wie viel Aufwand macht

Häufige Fragen

Wie oft sollte ich den WordPress Sicherheits-Check durchführen?

Einmal pro Quartal ist ein sinnvoller Rhythmus für die vollständige Checkliste. Updates sollten deutlich häufiger eingespielt werden, idealerweise wöchentlich oder automatisch für kritische Sicherheitsupdates. Wenn Sie eine neue Version eines Plugins oder Themes installieren, lohnt sich ein kurzer Check der betroffenen Punkte direkt danach.

Brauche ich ein Sicherheits-Plugin für WordPress?

Kein Sicherheits-Plugin ersetzt die Grundlagen: aktuelle Software, sichere Passwörter und ein gesperrter Datei-Editor. Plugins können Funktionen wie einen Dateiintegritätscheck, eine Web Application Firewall (WAF) oder erweiterte Login-Protokolle hinzufügen. Welche Plugins sinnvoll sind und welche mehr Marketing als Schutz bieten, zeigt der Artikel Sicherheits-Plugins für WordPress: Welche wirklich helfen.

Ist XML-RPC immer ein Risiko?

XML-RPC ist nur dann ein Risiko, wenn es aktiv genutzt wird, um Schwachstellen auszunutzen. Wenn Sie die WordPress-App für iOS oder Android oder bestimmte Jetpack-Features nutzen, brauchen Sie XML-RPC. Wenn nicht, ist Deaktivieren die sicherere Wahl. Prüfen Sie vor dem Sperren, ob Ihre aktiven Plugins oder Themes die Schnittstelle verwenden.

Was ist der Unterschied zwischen DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS?

DISALLOW_FILE_EDIT entfernt den Theme- und Plugin-Editor aus dem Dashboard. Neue Plugins und Themes können weiterhin installiert werden. DISALLOW_FILE_MODS verhindert zusätzlich die Installation und Aktualisierung von Plugins und Themes über das Backend. Letzteres eignet sich für Installationen, bei denen Updates über einen kontrollierten, externen Prozess eingespielt werden. Wer Updates manuell über das Dashboard einspielt, sollte nur DISALLOW_FILE_EDIT setzen, sonst muss jedes Update per FTP oder direkt auf dem Server eingespielt werden.

Mein Hoster hat ein eigenes Backup. Muss ich trotzdem ein eigenes anlegen?

Hoster-Backups sind oft zeitlich begrenzt (sieben oder vierzehn Tage), decken manchmal nicht alle Datenbanken ab und liegen auf derselben Infrastruktur wie Ihre Website. Ein eigenes Backup an einem anderen Ort gibt Ihnen Kontrolle und schützt auch dann, wenn der Hoster Probleme hat. Die DSGVO regelt außerdem, wo Backups mit personenbezogenen Daten gespeichert werden dürfen. Details finden Sie im Artikel DSGVO Backup: Wo Ihre Sicherungen liegen dürfen.

Kann ich verdächtige Dateien selbst prüfen?

Eine erste Orientierung geben Tools wie Wordfence oder der kostenlose Scanner von Sucuri. Sie vergleichen Ihre Dateien mit den Originaldateien von WordPress und gemeldeten Schadcode-Mustern. Bei konkretem Verdacht auf eine Kompromittierung sollten Sie das professionell prüfen lassen, denn Malware versteckt sich oft in legitim wirkenden Dateipfaden und ist ohne Erfahrung leicht zu übersehen.

Macht es Sinn, den Standard-Datenbankpräfix wp_ zu ändern?

Der Nutzen ist begrenzt. Früher wurde das als Schutz gegen automatisierte SQL-Injection-Angriffe empfohlen, die den Präfix raten müssen. Aktuelle Exploits umgehen das aber in der Regel. Wichtiger als ein geänderter Präfix ist die Aktualität der installierten Software. Wenn Sie einen Neuaufbau planen, kann der Präfixwechsel als zusätzliche Maßnahme sinnvoll sein, als alleinige Maßnahme bringt er wenig.

Wie erkenne ich, ob meine WordPress-Installation bereits kompromittiert ist?

Typische Anzeichen: unbekannte Benutzer im Dashboard, Weiterleitungen auf fremde Seiten, Google-Sicherheitswarnungen beim Aufruf der Website, ein Hoster, der die Website wegen Schadsoftware gesperrt hat, oder PHP-Fehlermeldungen, die vorher nicht da waren. Wer auf Nummer sicher gehen will, lässt einen Integritätscheck durch ein Plugin oder einen Dienstleister durchführen, der den Dateibestand mit den Originaldaten abgleicht.