WordPress gehackt? Das ist jetzt zu tun

Es passiert meist nicht „beim Basteln“, sondern im laufenden Betrieb: Sie öffnen die Website und sehen Spam-Links, Weiterleitungen auf dubiose Seiten oder Google warnt vor Malware. Oder Kund:innen melden, dass das Kontaktformular plötzlich Mails an fremde Adressen schickt. Wenn WordPress kompromittiert ist, zählt zuerst Tempo – aber nicht Aktionismus. Jede unkoordinierte Änderung kann Spuren verwischen, die Sie für eine saubere Bereinigung und spätere Absicherung brauchen.

WordPress gehackt – was tun in den ersten 30 Minuten?

Der wichtigste Zielkonflikt ist sofort da: Verfügbarkeit vs. Beweissicherung. Wenn gerade aktiv Schadcode ausgeliefert wird, hat der Schutz von Nutzer:innen Vorrang. Trotzdem lohnt es sich, die ersten Schritte bewusst zu setzen.

Wenn möglich, setzen Sie die Seite kurzfristig in einen Wartungsmodus oder nehmen Sie sie temporär offline. Das reduziert das Risiko, dass Besucher:innen infiziert werden oder Daten abfließen. Parallel dazu sichern Sie den Ist-Stand: ein vollständiges Backup von Dateien und Datenbank, bevor Sie „aufräumen“. Dieses Backup ist kein Rettungsanker fürs schnelle Wiederherstellen, sondern Ihre forensische Grundlage.

Als Nächstes: Passwörter sofort ändern – aber gezielt. Ändern Sie die Zugangsdaten für WordPress-Admin, FTP/SFTP, Hosting-Panel und Datenbank-User. Wenn E-Mail-Postfächer am selben Hosting hängen, gehören auch diese Passwörter dazu. Nutzen Sie dabei wirklich neue, einzigartige Passwörter und aktivieren Sie – wo verfügbar – 2-Faktor-Authentifizierung.

Dann prüfen Sie, ob der Angriff noch läuft. Verdächtig sind plötzlich hohe CPU-Last, unbekannte Cronjobs, ungewöhnlicher Mailversand oder neue Admin-Accounts. Ein schneller Blick in die WordPress-Userliste reicht oft, um „Admin 2“ oder ähnlich offensichtliche Einträge zu entdecken. Löschen Sie diese Accounts nicht sofort, wenn Sie noch logische Spuren brauchen – deaktivieren Sie sie (Rolle entziehen, Passwort ändern) und dokumentieren Sie.

Was sich typischerweise verändert – und warum „nur Plugin löschen“ selten reicht

Viele Hacks sind keine spektakulären Exploits, sondern eine Kette aus kleinen Lücken: veraltete Plugins, schwache Passwörter, unsichere File-Rechte, eine alte PHP-Version oder ein kompromittierter Rechner, der Zugangsdaten geleakt hat. Angreifer:innen hinterlassen selten nur eine Datei. Häufig sind es Backdoors, die beim nächsten Aufruf wieder alles herstellen.

Typische Muster sind eingeschleuster Code in `wp-config.php`, manipulierte `functions.php` im Theme, zusätzliche PHP-Dateien in Upload-Verzeichnissen oder obskure Dateien mit Namen, die wie WordPress-Core klingen. In der Datenbank finden sich oft Spam-Content, bösartige Shortcodes oder injizierte JavaScript-Snippets in Optionen-Tabellen. Genau deshalb ist „Plugin X löschen“ selten die Lösung – die eigentliche Persistenz liegt meist woanders.

Saubere Bereinigung: erst verifizieren, dann ersetzen

Der technisch saubere Weg ist: WordPress-Core und seriöse Plugins/Themes nicht „reparieren“, sondern durch bekannte, unveränderte Originale ersetzen. Das reduziert das Risiko, dass Sie manipulierte Dateien übersehen.

Beginnen Sie mit dem Core: Laden Sie die passende WordPress-Version neu hoch (ohne `wp-content` und ohne `wp-config.php` zu überschreiben) oder führen Sie ein kontrolliertes Re-Deployment durch. Danach kommen Plugins und Themes: Alles, was nicht zwingend gebraucht wird, wird entfernt. Alles, was bleibt, wird aus vertrauenswürdiger Quelle neu installiert. Bei Premium-Themes oder Agentur-Themes ist das heikel – hier müssen Sie sauber zwischen legitimen Anpassungen und Schadcode unterscheiden. Wenn Anpassungen im Theme stecken, ist ein Child-Theme-Ansatz Gold wert, weil Sie Updates nicht blockieren.

Für `wp-content/uploads` gilt: Dort gehören in der Regel keine ausführbaren PHP-Dateien hinein. Finden Sie dort PHP, ist das ein starkes Warnsignal. Allerdings: Manche Plugins legen legitime PHP-Dateien in Upload-nahen Ordnern an. Es braucht also Kontext, keine pauschale Löschwut.

In der Datenbank ist das Vorgehen ähnlich: Sie suchen nicht nur nach „spam“, sondern nach typischen Injektionsmustern wie Base64-Strings, `eval()`, unbekannten Script-Tags oder auffälligen Redirects. Besonders oft betroffen: `wp_options` (Autoload), Widgets, Elementor- oder Page-Builder-Templates und Header/Footer-Settings.

Wenn Daten betroffen sein könnten: DSGVO und Kommunikation richtig einschätzen

Ob ein Hack eine meldepflichtige Datenschutzverletzung ist, hängt davon ab, ob personenbezogene Daten abgeflossen sind oder ein Risiko für Betroffene besteht. Eine reine Defacement-Attacke ohne Datenabfluss ist anders zu bewerten als ein kompromittiertes Formular, das Anfragen an Dritte weiterleitet.

Praktisch heißt das: Prüfen Sie, welche Daten Ihre Website verarbeitet (Kontaktanfragen, Shop-Bestellungen, Newsletter-Opt-ins, Kundenkonten). Prüfen Sie Logfiles auf ungewöhnliche Exporte, verdächtige Admin-Aktivitäten, große Datenbank-Dumps oder untypische POST-Requests. Wenn Sie unsicher sind, ist es sinnvoll, früh juristischen Rat einzubinden – nicht aus Panik, sondern um sauber zu dokumentieren.

Kommunikation nach außen ist ein weiterer Trade-off: Zu früh zu viel sagen wirkt unprofessionell, zu spät zu wenig kann Vertrauen kosten. Für viele Unternehmen ist eine kurze, sachliche Info ausreichend: „Wartungsarbeiten aus Sicherheitsgründen, wir sind in Kürze wieder erreichbar.“ Intern sollten Marketing und Geschäftsführung denselben Kenntnisstand haben, damit niemand spekuliert.

Nach dem Clean-up: Warum Google manchmal länger „misstrauisch“ bleibt

Selbst wenn die Website technisch sauber ist, kann es dauern, bis Warnhinweise verschwinden oder Rankings wieder stabil sind. Suchsysteme reagieren auf Signale wie Malware-Funde, Redirects, Cloaking oder Spam-Seiten, die kurzzeitig indexiert wurden.

Wenn Sie die Google Search Console nutzen, prüfen Sie Sicherheitsprobleme und manuelle Maßnahmen. Auch ohne externe Tools können Sie testen: Werden einzelne URLs unerwartet weitergeleitet? Tauchen im Quelltext fremde Scripts auf? Existieren plötzlich Tausende Seiten mit Spam-Slugs? Wichtig ist, diese Spuren konsequent zu entfernen und dann auf Normalisierung zu warten. Bei großen Schäden kann auch ein sauberer Relaunch-ähnlicher Prozess sinnvoll sein – mit kontrollierten Redirects, strukturierten Daten und klarer technischer Basis, damit Sie nicht „gesund“ werden und gleichzeitig Sichtbarkeit verlieren.

Hardening, das wirklich hilft (und was nur Beruhigung ist)

Sicherheit ist kein Plugin, sondern ein Betriebsmodell. Ein Security-Plugin kann Monitoring und Basisschutz bieten, ersetzt aber nicht die Grundlagen.

Wirksam sind vor allem drei Ebenen: erstens Updates und Lifecycle-Management (WordPress, Plugins, Themes, PHP), zweitens Zugriffsschutz (2FA, Rollen, saubere Credentials, SFTP statt FTP, restriktive Rechte), drittens Server- und Applikationshärtung (WAF-Regeln, Rate Limiting, saubere File-Permissions, Deaktivieren riskanter PHP-Funktionen, getrennte Benutzer und Datenbanken je Projekt).

Bei vielen kompromittierten Websites ist das Problem, dass Updates „aus Angst“ vermieden wurden. Ja, Updates können brechen – besonders bei stark verbogenen Themes oder schlecht gebauten Plugins. Die richtige Antwort ist aber nicht Stillstand, sondern Wartbarkeit: saubere Code-Standards, ein Staging-System, getestete Deployments und ein klarer Prozess.

Monitoring und Logs: Ohne Sichtbarkeit bleiben Sie blind

Die Frage „wordpress gehackt was tun“ endet nicht mit „alles wieder online“. Entscheidend ist, ob Sie den nächsten Vorfall früh erkennen. Ohne Logs und Monitoring merken Sie Angriffe oft erst, wenn SEO oder Kund:innen leiden.

Sinnvoll ist ein Setup aus Verfügbarkeitsmonitoring, Security-Events (Login-Versuche, Dateiänderungen, neue Admins), Mail-Ausgangskontrolle (Spam-Indikatoren) und Server-Logs, die nicht nach wenigen Tagen verschwinden. Gerade bei Shared Hosting fehlen manchmal Detail-Logs oder sie sind schwer zugänglich. Dann ist es umso wichtiger, zumindest auf Anwendungsebene nachvollziehen zu können, was passiert.

Wann Sie besser nicht mehr selbst herumprobieren

Es gibt Situationen, in denen Eigenmaßnahmen das Risiko erhöhen: wenn ein Shop betroffen ist, wenn Kundendaten im Spiel sind, wenn die Seite mehrfach „wiederkommt“, obwohl Sie bereinigt haben, oder wenn Sie nicht sauber trennen können, welche Dateien original und welche verändert sind.

Spätestens wenn Backdoors im Spiel sind, ist eine strukturierte Incident-Response sinnvoll: isolieren, forensisch sichern, bereinigen, neu deployen, Zugangsdaten rotieren, Hardening umsetzen, Monitoring aktivieren, danach erst wieder voll online. Wer das einmal sauber durchzieht, hat später weniger Downtime und weniger SEO-Kollateralschäden.

Wenn Sie dabei Unterstützung brauchen: Als Wiener Boutique für technisch saubere WordPress-Umsetzungen, Performance und laufende Wartung begleiten wir solche Fälle pragmatisch – mit Fokus auf Stabilität, DSGVO-tauglichen Betrieb und nachhaltige Auffindbarkeit. Details dazu finden Sie bei XOXO Websolutions.

Der nachhaltige Fix: Website-Betrieb wie ein System behandeln

Ein Hack ist selten „Pech“. Meist ist es ein Signal, dass Betrieb, Updates und technische Verantwortung zu lange zwischen Zuständigkeiten gelegen sind. Wenn Ihre Website ein Vertriebskanal ist, verdient sie denselben Umgang wie jedes andere produktive System: klare Verantwortlichkeit, planbare Wartungsfenster, gemessene Qualität (Core Web Vitals), dokumentierte Änderungen und ein Sicherheitsniveau, das zu Ihrem Risiko passt.

Der beste Moment dafür ist nicht irgendwann „nach dem Stress“, sondern genau dann, wenn die Seite wieder sauber läuft und alle sehen, was ein Ausfall kostet – Zeit, Vertrauen, Leads und oft auch Sichtbarkeit. Wenn Sie diesen Moment nutzen, wird aus einem Incident ein Upgrade Ihrer digitalen Basis.