Wer nach „WordPress Sicherheit“ sucht, landet schnell bei Listen mit zwanzig Maßnahmen und einem Plugin, das alle auf einmal erledigen soll. Für einen kleinen Blog ist das meistens die falsche Reihenfolge. Die Angriffe, die einen Hobbyblog tatsächlich treffen, laufen über veraltete Plugins, schwache Passwörter und Zugänge, die längst niemand mehr braucht – und dagegen hilft vor allem Ordnung, nicht Software.
In diesem Beitrag bekommst du die Maßnahmen, die die offizielle Härtungsanleitung von WordPress selbst empfiehlt, sortiert nach dem, was bei einem kleinen Blog den Unterschied macht. Dazu drei Fälle aus meinem eigenen Netzwerk, bei denen ich gemerkt habe, dass zwischen „erledigt“ und „wirklich erledigt“ eine Lücke klaffen kann. Was du nicht bekommst: eine Rangliste von Sicherheits-Plugins.
WordPress Sicherheit auf einen Blick
- Updates zuerst. Die WordPress-Härtungsanleitung nennt das Aktualisieren als erste Maßnahme. Seit Version 3.7 kann WordPress sich selbst aktualisieren – diese Automatik solltest du nutzen.
- Ein Backup zählt erst, wenn es sich zurückspielen lässt. Dateien und Datenbank regelmäßig sichern, die Sicherung per Prüfsumme kontrollieren und die Wiederherstellung mindestens einmal ausprobieren.
- Starke Passwörter plus zweiter Faktor. Die offizielle Anleitung empfiehlt die Zwei-Faktor-Anmeldung zusätzlich zum starken Passwort, vor allem für Administratorkonten.
- Deaktivieren ist nicht löschen. Ein deaktiviertes Plugin liegt weiter mit allen Dateien auf dem Server. Was du nicht nutzt, gehört gelöscht.
- Rollen sparsam vergeben. Für Gastautoren, Skripte und Automatik reicht die Rolle Redakteur oder weniger. Ein Redakteur kann keine Plugins installieren und keine Einstellungen ändern.
- Anwendungspasswörter gehören auf eine Liste. Sie haben dieselben Rechte wie das Konto, zu dem sie gehören, und lassen sich im Profil einzeln widerrufen.
- Ein Sicherheits-Plugin ist eine Ergänzung, kein Fundament. Es ersetzt weder Updates noch Backups noch aufgeräumte Konten.
Was einen kleinen Blog tatsächlich gefährdet
Kein gezielter Angriff, sondern ein automatischer Rundgang
Ein Blog mit ein paar hundert Besuchern im Monat ist für niemanden ein persönliches Ziel. Gefährlich wird er trotzdem, weil Angriffe auf WordPress fast immer automatisch laufen: Programme klappern massenhaft Seiten ab und probieren bekannte Lücken in Plugins und Themes aus oder testen Benutzername-Passwort-Kombinationen an der Anmeldeseite. Ob dein Blog groß oder klein ist, spielt dabei keine Rolle. Entscheidend ist, ob er eine der bekannten Türen offen hat.
Daraus folgt die wichtigste Einsicht für einen kleinen Blog: Die meisten Maßnahmen, die wirklich etwas bringen, kosten kein Geld. Sie kosten Disziplin. Die Härtungsanleitung im WordPress-Handbuch (Stand der Seite: 7. Januar 2026) beginnt deshalb nicht mit einem Plugin, sondern mit Updates, Passwörtern und Dateirechten.
Was ein Sicherheits-Plugin leisten kann – und was nicht
Sicherheits-Plugins haben ihren Platz. Die Härtungsanleitung nennt Firewalls auf Anwendungsebene und vorgeschaltete Dienste ausdrücklich als Möglichkeit, bösartigen Datenverkehr abzufangen. Nur: Ein Plugin, das Anmeldeversuche zählt und Dateien überwacht, ändert nichts daran, dass ein veraltetes Formular-Plugin eine bekannte Lücke hat. Es meldet vielleicht hinterher, dass etwas passiert ist.
Bei der WordPress-Sicherheit halte ich es deshalb so: erst die Grundordnung, dann – wenn überhaupt – ein Werkzeug obendrauf. Jedes zusätzliche Plugin ist auch zusätzlicher Code, der gepflegt und aktualisiert werden will. Wer zu den Plugins, die man wirklich braucht, ein Sicherheitspaket mit hundert Schaltern hinzufügt, das er nie konfiguriert, hat am Ende mehr Fläche als vorher.
Das Fundament: Updates, Backups, Konten
Updates automatisch laufen lassen
Die Härtungsanleitung sagt es ohne Umschweife: WordPress immer auf dem neuesten Stand halten, ältere Versionen bekommen keine Sicherheitskorrekturen mehr. Seit Version 3.7 bringt WordPress automatische Updates mit, und die Anleitung empfiehlt, diese Funktion zu nutzen. Für Plugins gilt dasselbe – sie sind der häufigste Weg, über den Lücken auf einen Blog kommen.
In der Praxis heißt das: automatische Updates für den Kern und für Plugins aus dem offiziellen Verzeichnis einschalten und einmal pro Woche ins Dashboard schauen, ob etwas hängen geblieben ist. Ein Plugin, das seit Jahren kein Update bekommen hat, ist ein Kandidat zum Austauschen, auch wenn es heute noch funktioniert.
Ein Backup, dem du trauen kannst
Ein Backup ist die einzige Maßnahme der WordPress-Sicherheit, die auch dann noch hilft, wenn alles andere versagt hat. Die Härtungsanleitung empfiehlt, Daten einschließlich der Datenbank regelmäßig zu sichern, und rät, für jede Sicherungsdatei eine Prüfsumme festzuhalten oder die Sicherung auf schreibgeschützten Medien abzulegen, damit sich später nachweisen lässt, dass niemand sie verändert hat.
Wie wichtig die Prüfsumme ist, habe ich selbst erlebt, als ich eine Seite aus einer Multisite herausgelöst habe: Eine heruntergeladene Sicherung hatte exakt die richtige Größe und trotzdem eine falsche Prüfsumme – ein abgebrochener Transfer hatte das Dateiende beschädigt. Die ganze Geschichte steht im Beitrag über das Herauslösen einer Multisite-Seite. Meine Regel seitdem: Ein Backup ist erst fertig, wenn die Prüfsumme stimmt, nicht wenn die Dateigröße stimmt. Und es ist erst brauchbar, wenn du einmal ausprobiert hast, ob es sich zurückspielen lässt.
Konten, Rollen und Zugänge aufräumen
Starke Passwörter und der zweite Faktor
Ein starkes Passwort ist lang, zufällig und kommt nirgendwo sonst vor. Die Härtungsanleitung rät von Namen, Wörterbuchwörtern und kurzen Kombinationen ab und empfiehlt, zusätzlich eine Zwei-Faktor-Anmeldung einzuschalten. Ein Passwortmanager erledigt den ersten Teil, für den zweiten brauchst du ein Plugin, weil WordPress selbst keine Zwei-Faktor-Anmeldung mitbringt.
Im offiziellen Verzeichnis gibt es dafür das von der Community gepflegte Plugin Two Factor. Es unterstützt Codes aus einer Authenticator-App, Codes per E-Mail und Notfall-Codes (Stand: Oktober 2026). Für einen kleinen Blog reicht die App-Variante. Wichtig ist nur, die Notfall-Codes an einem sicheren Ort abzulegen, bevor du dich selbst aussperrst.
Rollen: Redakteur reicht für fast alles
WordPress kennt in einer Einzelinstallation fünf Standardrollen. Laut WordPress-Dokumentation zu Rollen und Berechtigungen kann ein Administrator alles, ein Redakteur Beiträge veröffentlichen und verwalten, auch die anderer Benutzer. Was ein Redakteur nicht kann: Plugins installieren oder bearbeiten, Benutzer verwalten, Einstellungen ändern. Genau diese Rechte sind es, die ein Angreifer mit einem gekaperten Konto haben will.
Das ist der zweite Fall aus meiner Werkstatt. Meine Blogs bekommen Inhalte auch über eine Schnittstelle, die eine KI-Anwendung von außen anspricht. Dieser Schreibzugang ist aus dem öffentlichen Internet erreichbar – das lässt sich bei dieser Bauart nicht vermeiden. Deshalb steht für mich fest: Die Verbindung läuft über ein Konto mit der Rolle Redakteur, niemals über einen Administrator. Wird der Zugang missbraucht, kann er Beiträge anlegen, aber keine Plugins hochladen und keine Benutzer löschen. Dasselbe gilt für Gastautoren, Helfer und jedes Werkzeug, das nur schreiben muss.
| Rolle | darf veröffentlichen | Plugins installieren | Einstellungen ändern | typischer Einsatz |
|---|---|---|---|---|
| Administrator | ja | ja | ja | nur du, für Wartung |
| Redakteur | ja, auch fremde Beiträge | nein | nein | Automatik, Mitautoren |
| Autor | nur eigene Beiträge | nein | nein | Gastautor mit Vertrauen |
| Mitarbeiter | nein, nur Entwürfe | nein | nein | Gastbeitrag zur Prüfung |
| Abonnent | nein | nein | nein | Leserkonto |
Eine Zeile in der wp-config.php nimmt sogar dem Administrator ein gefährliches Werkzeug weg: den eingebauten Datei-Editor für Themes und Plugins. Laut Härtungsanleitung entspricht die folgende Zeile dem Entzug der Rechte edit_themes, edit_plugins und edit_files für alle Benutzer. Wer ein Konto übernimmt, kann dann nicht mehr per Dashboard PHP-Code in eine Datei schreiben.
define( 'DISALLOW_FILE_EDIT', true );Für die WordPress-Sicherheit eines kleinen Blogs ist das eine der billigsten Maßnahmen überhaupt. Den Editor vermisst ohnehin niemand, der Änderungen sauber über ein Kind-Theme oder per FTP einspielt.
Drei Stellen, an denen „erledigt“ nicht erledigt ist
Deaktivierte Plugins liegen weiter auf dem Server
Der dritte Fall: Auf diesem Blog lief früher ein Newsletter-Plugin. Als ich den Newsletter abgeschaltet hatte, hielt ich das Plugin für entfernt. Die Plugin-Liste sagte etwas anderes – es war nur deaktiviert, die Dateien lagen weiter im Plugin-Verzeichnis. Erst nach dem Löschen ging die Liste von 13 auf 11 Einträge zurück, weil bei der Gelegenheit ein zweites ungenutztes Plugin mit verschwand.
Warum das wichtig ist: Ein deaktiviertes Plugin wird nicht ausgeführt, solange WordPress es nicht lädt. Seine Dateien sind aber weiter auf dem Server, und eine Lücke in einer direkt aufrufbaren Datei bleibt eine Lücke. Die Härtungsanleitung sagt deshalb schlicht: Wenn du ein Plugin nicht nutzt, lösch es. Mein Merksatz dazu: Deaktivieren ist nicht löschen. Und bei jeder Aussage „das ist weg“ schaue ich in die Liste, statt mich auf mein Gedächtnis zu verlassen.
Anwendungspasswörter und Testdateien wieder einsammeln
Wer Skripte, Apps oder Automatisierungen an WordPress anbindet, nutzt meist Anwendungspasswörter. Es gibt sie seit WordPress 5.6. Laut Integrationsleitfaden des WordPress-Kernteams haben sie dieselben Rechte wie das Benutzerkonto, das sie erzeugt hat, taugen aber nicht für die Anmeldung im Dashboard. Im Profil des Benutzers lassen sie sich einzeln ansehen und widerrufen.
Das Problem ist nicht das Anwendungspasswort, sondern das vergessene. Ein Skript, das du für eine einmalige Massenänderung gebaut hast, braucht seinen Zugang danach nicht mehr. Meine Regel: Jedes Anwendungspasswort bekommt einen sprechenden Namen, und wenn das Skript seinen Zweck erfüllt hat, wird es widerrufen. Wer seine Zugänge zusätzlich in einer Liste führt, sollte dort nur den Verweis auf den Passwortmanager notieren, nie das Passwort selbst.
Dasselbe gilt für Hilfsdateien. Eine PHP-Info-Datei ist praktisch, um Version und Einstellungen des Servers auszulesen – und genau deshalb gehört sie nach dem Auslesen sofort gelöscht. Sie verrät jedem, der sie findet, dieselben Details wie dir. Gleiches gilt für Testskripte, alte Exportdateien und Sicherungen, die im öffentlichen Webverzeichnis liegen.
Aus diesen drei Fällen lässt sich eine kleine Routine ableiten, die einmal im Monat in zehn Minuten erledigt ist. Sie ersetzt kein Sicherheits-Plugin, aber sie deckt genau die Stellen ab, an denen WordPress Sicherheit im Alltag verloren geht:
- Plugin-Liste ansehen. Was deaktiviert ist und nicht gebraucht wird, wird gelöscht. Was seit Langem kein Update bekommen hat, kommt auf die Austauschliste.
- Benutzerliste ansehen. Gibt es Konten, die niemand mehr nutzt? Hat jemand mehr Rechte, als er braucht?
- Anwendungspasswörter in jedem Profil prüfen. Alles ohne erkennbaren Zweck wird widerrufen.
- Webverzeichnis nach Hilfsdateien durchsehen. PHP-Info, Testskripte, Exporte, alte Sicherungen.
- Letztes Backup prüfen. Ist es da, ist es vollständig, und wann wurde zuletzt eine Wiederherstellung geübt?
Häufige Fragen zur WordPress Sicherheit
Einordnen und entscheiden
Umsetzen und prüfen
Quellen und weiterführende Dokumentation
- WordPress Developer Resources: Hardening WordPress (Stand der Seite: 7. Januar 2026)
- WordPress Documentation: Roles and Capabilities (Stand der Seite: 2. September 2026)
- Make WordPress Core: Application Passwords – Integration Guide (veröffentlicht zu WordPress 5.6, November 2020)
- WordPress-Plugin-Verzeichnis: Two Factor (Funktionsumfang Stand Oktober 2026)
Schreibe einen Kommentar