WordPress gehackt: Was jetzt in welcher Reihenfolge zu tun ist

Ist es wirklich ein Hack?

Nicht jede kaputte Seite ist gehackt. Ein weißer Bildschirm oder die Meldung „Es gab einen kritischen Fehler“ direkt nach einem Update ist meistens ein Plugin-Konflikt. Das ist ein Fall für die WordPress-Notfallhilfe, nicht für eine Malware-Bereinigung. Dasselbe gilt meistens für die Meldung „Fehler beim Aufbau einer Datenbankverbindung“.

Ein Hack zeigt sich anders. Typische Anzeichen sind:

• Google, Bing oder ein Virenscanner warnt vor deiner Seite.
• Dein Hoster hat die Seite gesperrt.
• Im Backend stehen Benutzer, die niemand von euch angelegt hat.
• Besucher landen auf fremden Seiten, oft nur auf dem Handy oder nur, wenn sie über Google kommen.
• Jemand meldet dir, dass von deiner Seite Angriffe oder Spam ausgehen.

Die offizielle WordPress-Anleitung FAQ My site was hacked führt ähnliche Anzeichen auf und ist auch für die Schritte unten die Referenz. Trifft eins davon zu, arbeite die sieben Schritte der Reihe nach ab. Lass keinen aus, nur weil er dir übertrieben vorkommt.

Die sieben Schritte in der richtigen Reihenfolge

1. Seite vom Netz nehmen

Solange die Seite erreichbar ist, verteilt sie womöglich Schadcode an deine Besucher, und Google sammelt weiter Gründe für eine Warnung. Ein Wartungsmodus-Plugin hilft hier wenig, denn der Schadcode läuft im selben WordPress wie das Plugin. Sicherer ist eine Sperre auf Server-Ebene: im Kundenmenü deines Hosters oder mit einer Regel in der .htaccess, die nur deine eigene IP-Adresse durchlässt.

2. Den befallenen Stand sichern und aufschreiben

Bevor du irgendetwas löschst: Sichere Dateien und Datenbank so, wie sie gerade sind, auch wenn dieses Backup verseucht ist. Darin steckt die Spur zum Einfallstor. Ohne sie lässt sich später kaum sagen, wie der Angreifer reinkam und ob Kundendaten abgeflossen sind.

Die WordPress-Dokumentation rät außerdem, sofort mitzuschreiben: Was siehst du, seit wann (mit Uhrzeit), und was wurde zuletzt geändert, etwa ein neues Plugin oder ein Theme-Update? Diese Notizen brauchst du später für den Hoster, für Google und unter Umständen für die Datenschutzbehörde.

3. Den eigenen Rechner prüfen

Das klingt nach Umweg, gehört aber vor den Passwortwechsel. Laut WordPress-Dokumentation beginnt ein Angriff oft auf dem Rechner des Betreibers: Ein Trojaner liest FTP- und Admin-Zugangsdaten mit. Wer neue Passwörter auf so einem Gerät eintippt, gibt sie gleich weiter. Lass einen vollständigen Virenscan laufen oder ändere die Passwörter von einem anderen, sauberen Gerät aus.

4. Alle Zugänge ändern und alle Sitzungen beenden

Neue Passwörter brauchst du für jeden Zugang, nicht nur für deinen eigenen WordPress-Login:

• alle WordPress-Konten mit Administrator- oder Redakteursrechten
• SFTP, FTP und SSH
• das Kundenmenü beim Hoster
• den Datenbank-Benutzer (das neue Passwort trägst du danach in der wp-config.php ein)

Ein neues Passwort wirft aber niemanden raus, der schon eingeloggt ist. Dafür tauschst du die Sicherheitsschlüssel in der wp-config.php aus. Einen frischen Satz erzeugt der offizielle WordPress-Schlüsselgenerator. Sobald die neuen Schlüssel drinstehen, muss sich jeder neu anmelden, auch der Angreifer.

Dann die Benutzerliste prüfen. Angreifer legen gern eigene Admin-Konten an, und manche blenden sie per Code aus der Liste im Backend aus. Ein Blick direkt in die Tabelle wp_users (über phpMyAdmin oder Adminer beim Hoster) zeigt alle Konten.

5. Dateien und Datenbank bereinigen

Jetzt erst geht es an den Schadcode. Ein Sicherheits-Plugin wie Wordfence oder ein externer Scan mit Sucuri SiteCheck zeigt dir, wo du anfangen kannst. Mehr als einen Startpunkt liefern Scanner aber nicht: Sie vergleichen Dateien mit bekannten Versionen und suchen nach bekannten Mustern. Schadcode in der Datenbank, etwa in der Tabelle wp_options oder versteckt in Beitragsinhalten, finden sie oft nicht.

So gehst du vor:

1. Den WordPress-Core ersetzen: die Ordner /wp-admin und /wp-includes per SFTP durch frische Dateien derselben WordPress-Version ersetzen. Nicht über „Neu installieren“ im Backend. Laut WordPress-Dokumentation überschreibt das nur vorhandene Dateien, und neu angelegte Schaddateien bleiben liegen.
2. Plugins und Themes frisch aus der Originalquelle installieren, nicht aus deinem eigenen Backup. Was du nicht nutzt, löschst du ganz. Deaktivieren reicht nicht, die Dateien bleiben auf dem Server und sind weiter aufrufbar.
3. Alle .htaccess-Dateien prüfen, im Hauptverzeichnis und in Unterordnern. Die WordPress-Dokumentation nennt sie als eine der Dateien, die bei Befall am häufigsten verändert werden.
4. Im Ordner wp-content/uploads haben PHP-Dateien nichts zu suchen. Liegt dort eine, ist sie mit großer Wahrscheinlichkeit eine Hintertür.
5. In der Datenbank nach eingeschleustem JavaScript und fremden Links suchen, vor allem in wp_options und wp_posts, und unbekannte Einträge in den geplanten Aufgaben (Option cron) entfernen.

Findest du dabei mehr als eine Hintertür, ist das normal. Angreifer legen meistens mehrere an, damit eine übersehene reicht, um wieder reinzukommen.

6. Das Einfallstor finden und schließen

Bereinigen, ohne die Lücke zu schließen, verschafft dir ein paar Tage Ruhe, mehr nicht. Fang die Suche bei den Plugins an, denn dort liegen die meisten Lücken. Patchstack hat für 2025 insgesamt 11.334 neue Sicherheitslücken im WordPress-Umfeld gezählt, 91 Prozent davon in Plugins und 9 Prozent in Themes (State of WordPress Security in 2026). Etwa die Hälfte der schweren Lücken wurde laut demselben Bericht innerhalb von 24 Stunden ausgenutzt.

Die Fragen lauten also: Welches Plugin war veraltet? Für welches gab es kurz vor dem Befall ein Sicherheitsupdate, das noch nicht eingespielt war? Die Zugriffsprotokolle (Access-Logs) deines Servers zeigen oft, welche Datei der Angreifer zuerst aufgerufen hat. Danach alles aktualisieren: WordPress, Plugins, Themes und, falls sie veraltet ist, die PHP-Version.

Zum Schluss alle Passwörter noch einmal ändern. Die WordPress-Dokumentation empfiehlt das ausdrücklich, und der Grund ist einfach: Solange noch Schadcode lief, konnte er auch die neuen Passwörter aus Schritt 4 beim Login mitschneiden.

7. Google und dem Hoster Bescheid geben

Hat Google deine Seite als gefährlich markiert, steht das in der Search Console im Bericht „Sicherheitsprobleme“. Erst wenn alle gemeldeten Probleme auf der ganzen Website behoben sind, wählst du dort „Überprüfung anfordern“. Laut Search-Console-Hilfe gehört in den Antrag, was genau das Problem war, was du dagegen getan hast und woran man sieht, dass es funktioniert hat. Rechne mit einigen Tagen bis Wochen und stell keinen zweiten Antrag, solange der erste läuft.

Sag auch deinem Hoster, dass die Seite sauber ist und was du gefunden hast. Auf einem Shared-Hosting-Server kann der Befall andere Kunden betroffen haben, und manche Hoster heben eine Sperre erst nach so einer Meldung auf. Ist wegen des Befalls dein Google-Ads-Konto gesperrt, braucht es zusätzlich einen eigenen Antrag bei Google Ads.

Musst du den Hack der Datenschutzbehörde melden?

Oft ja. Sobald auf der Seite personenbezogene Daten liegen, und das ist bei jedem Shop mit Kundenkonten und bei fast jedem Formular mit gespeicherten Anfragen der Fall, kann ein Hack eine Datenpanne im Sinne der DSGVO sein. Art. 33 DSGVO verlangt dann eine Meldung an die zuständige Aufsichtsbehörde „unverzüglich und möglichst binnen 72 Stunden“, nachdem du davon erfahren hast. Die Meldung entfällt nur, wenn die Verletzung voraussichtlich zu keinem Risiko für die Betroffenen führt.

Führt der Vorfall voraussichtlich zu einem hohen Risiko, etwa weil Passwörter oder Zahlungsdaten abgeflossen sein könnten, musst du nach Art. 34 auch die Betroffenen selbst benachrichtigen. Dokumentieren musst du den Vorfall in jedem Fall, mit Fakten, Auswirkungen und deinen Gegenmaßnahmen (Art. 33 Abs. 5). Deine Notizen aus Schritt 2 sind der Anfang dieser Dokumentation.

Ob in deinem Fall eine Meldung nötig ist, ist eine rechtliche Frage. Klär sie mit deinem Datenschutzbeauftragten oder einem Anwalt, und zwar innerhalb der 72 Stunden. Was wir dafür liefern, sind die technischen Fakten: Wir werten die Zugriffsprotokolle des Servers aus und prüfen, ob es Hinweise auf einen Download der Datenbank gibt.

Warum ein altes Backup allein nicht reicht

Ein altes Backup einzuspielen ist der schnellste Weg zurück und kann ein guter Teil der Lösung sein. Das Problem löst es nicht: Die Lücke, durch die der Angreifer kam, steckt im Backup genauso wie in der gehackten Seite. Wer nur zurückspielt, steht nach ein paar Tagen wieder am selben Punkt.

Dazu kommt, dass du selten genau weißt, seit wann der Schadcode schon auf der Seite liegt. Ein Backup von letzter Woche kann bereits befallen sein. Spiel ein Backup also nur ein, wenn du sicher bist, dass es vor dem Befall entstanden ist, und wenn du weißt, welche Lücke genutzt wurde. Die schließt du direkt danach (Schritt 6).

Wann du es selbst schaffst und wann nicht

Ein sichtbarer Befall auf einer kleinen Seite ohne Kundendaten, ein sauberes Backup von vor dem Angriff und ein klarer Verdacht, welches Plugin die Lücke war: Das schaffst du mit dieser Anleitung selbst, wenn du mit SFTP und phpMyAdmin umgehen kannst.

Hol dir Hilfe, wenn eins davon zutrifft:

• Der Schadcode kommt nach dem Bereinigen zurück.
• Du findest das Einfallstor nicht.
• Es ist ein Shop, oder auf der Seite liegen Kundendaten. Dann läuft die 72-Stunden-Frist.
• Google warnt bereits vor der Seite, oder dein Ads-Konto ist gesperrt.
• Die Seite gehört zu einem WordPress-Multisite-Netzwerk. Alle Seiten teilen sich Dateien und Datenbank, also musst du jede Seite des Netzwerks prüfen.

Genau diese Fälle übernehmen wir bei der Malware-Bereinigung für WordPress: Dateien und Datenbank von Hand prüfen, alle Hintertüren suchen, das Einfallstor schließen und den Antrag bei Google stellen. Die Notfall-Bereinigung kostet ab 499 € zzgl. MwSt. Vorher schauen wir uns deinen Fall kostenlos an und nennen dir einen festen Preis. Wie schnell das gehen kann, zeigt eine Fallstudie auf derselben Seite: Die Website eines mittelständischen Industrieunternehmens, kompromittiert durch einen Trojaner, war nach unter drei Stunden bereinigt und wieder online.

Damit es nicht wieder passiert, brauchst du vor allem regelmäßige Updates, getestet und mit Backup davor. Wie das ohne Ausfall geht, steht in WordPress-Updates sicher einspielen. Das übernehmen wir auf Wunsch dauerhaft mit der WordPress-Betreuung.

Häufige Fragen

Wie finde ich heraus, ob meine WordPress-Seite gehackt wurde?

Achte auf die Anzeichen oben: Warnungen von Google oder vom Virenscanner, fremde Admin-Konten, Weiterleitungen auf fremde Seiten. Prüf dazu den Bericht „Sicherheitsprobleme“ in der Search Console und lass einen externen Scan laufen. Im Zweifel hilft ein Blick auf die zuletzt geänderten Dateien auf dem Server: Wenn sich Core-Dateien geändert haben, ohne dass du ein Update eingespielt hast, stimmt etwas nicht.

Warum wird meine Seite immer wieder gehackt?

Fast immer, weil beim Bereinigen eine Hintertür übrig geblieben ist oder die Lücke offen blieb. Seltener sind es mitgelesene Passwörter von einem befallenen Rechner (Schritt 3) oder ein Nachbar auf demselben Shared-Hosting-Server.

Reicht ein Sicherheits-Plugin wie Wordfence?

Zum Finden und zum Vorbeugen ist so ein Plugin nützlich. Zum Bereinigen reicht es selten, weil es Schadcode in der Datenbank oft nicht erkennt und das Einfallstor nicht für dich schließt. Und es läuft im selben WordPress, das gerade befallen ist.

Was kostet es, eine gehackte WordPress-Seite bereinigen zu lassen?

Bei uns kostet die Notfall-Bereinigung ab 499 € zzgl. MwSt. Den festen Preis für deinen Fall nennen wir nach einer kostenlosen Kurzanalyse, bevor wir anfangen.