Gehacktes WordPress bereinigen, Malware-Entfernung

“Die aufgerufene Website enthält schädliche Programme.”

Dieser Satz, angezeigt auf einem knallroten Bildschirm (Google Safe Browsing) oder in einer E-Mail Ihres Hosting-Providers, ist der Albtraum jedes Website-Betreibers. Eine WordPress-Infektion ist nicht nur ein Imageproblem. Es droht der Diebstahl von Kundendaten, der Verlust von Google-Rankings (der sogenannte “Japanese Keyword Hack” oder Weiterleitungen zu Glücksspielseiten) und potenziell die Sperrung Ihres Hosting-Accounts.

Ein großer Teil der Angriffe auf WordPress läuft automatisiert: Der offizielle WordPress-Hardening-Leitfaden hält fest, dass viele Angriffe autonom von Bots ausgeführt werden. Bots greifen Sie nicht persönlich an, sie scannen das Netz nach veralteten Plugins, schwachen Passwörtern oder Lücken in Themes.

In diesem Artikel zeige ich Ihnen einen professionellen, technischen Prozess zur Bereinigung einer gehackten WordPress-Website. Vergessen Sie “Malware-Entfernungs-Plugins”, die das Problem oft nur maskieren. Ich zeige Ihnen, wie man es manuell, effektiv und auf Serverebene mit SSH und WP-CLI macht.

War das erste Anzeichen japanische Seiten in Google und nicht etwas Sichtbares auf der Website, handelt es sich vermutlich um die getarnte Variante, die einen anderen ersten Schritt braucht: siehe japanischer Keyword-Hack, bevor Sie etwas löschen.

#Anzeichen für ein gehacktes WordPress und was Sie zuerst notieren

“Gehackt” ist ein vager Begriff. Die Seite FAQ My site was hacked in der offiziellen WordPress-Dokumentation nennt die konkreten Symptome Indicators of Compromise (IoC) und zählt die eindeutigsten auf:

• die Website steht auf einer Sperrliste von Google, Bing oder anderen Suchmaschinen;
• der Hoster hat die Website deaktiviert;
• die Website wurde wegen Malware-Verbreitung markiert;
• Besucher melden, dass ihr Virenscanner die Website blockiert;
• jemand meldet sich, weil Ihre Website für Angriffe auf andere Websites genutzt wird;
• es gibt Aktionen, die niemand autorisiert hat, etwa neue Benutzer;
• die Veränderung ist sichtbar, sobald Sie die Website im Browser öffnen.

Der erste praktische Schritt ist laut derselben Seite die Dokumentation. Bevor Sie etwas löschen, notieren Sie, was Sie sehen, wann Sie das Problem bemerkt haben (mit Zeitzone) und was sich zuletzt geändert hat: ein neues Plugin, eine Änderung am Theme, ein bearbeitetes Widget. Ergänzen Sie die Daten der Hosting-Umgebung (PHP-Version, Servertyp, wer Zugang hat). Diese Notiz ist die Grundlage eines Incident-Reports und spart Zeit, egal ob Sie selbst bereinigen oder die Arbeit abgeben.

Zwei Schritte werden oft vergessen, beide stammen aus derselben Quelle. Erstens: Scannen Sie Ihren eigenen Rechner mit einem Virenscanner. Ein lokaler Trojaner, der FTP- oder /wp-admin-Zugangsdaten mitschneidet, macht jede Bereinigung auf dem Server wertlos. Zweitens: Sprechen Sie mit dem Hoster. Bei Shared Hosting kann die Infektion mehr als Ihre Website betreffen, und eine Website, die Spam verschickt, kann die IP des Servers auf E-Mail-Sperrlisten bringen, was auch die ausgehende Post dieses Servers trifft.

#Backup der gehackten WordPress-Seite vor der Bereinigung

Bevor Sie irgendetwas anfassen, erstellen Sie ein Backup des aktuellen Zustands. Warum? Weil Sie während der Reinigung versehentlich eine kritische Datei löschen könnten (z.B. eine modifizierte functions.php, die wichtige Funktionen enthielt, nicht nur den Virus). Die WordPress-Dokumentation empfiehlt diese Kopie auch bei infizierter Website: Geht die Bereinigung schief, haben Sie zumindest den vorherigen Stand zum Nachsehen.

Wenn Sie SSH-Zugang haben:

## Alle Dateien archivieren
tar -czf backup-infected-files_$(date +%F).tar.gz .

## Datenbank exportieren
wp db export backup-infected-db_$(date +%F).sql --allow-root

#WordPress-Malware mit grep finden

Bevor Sie anfangen zu “schneiden”, müssen Sie wissen, womit Sie kämpfen. Malware in WordPress versteckt sich oft als verschleierter Code (obfuscated code) unter Verwendung von Funktionen wie eval, base64_decode oder gzinflate. Googles Bericht zu Sicherheitsproblemen zeigt ein typisches Beispiel, eval(base64_decode("...")), und empfiehlt die Suche nach den Begriffen eval, base64_decode und unescape.

Hier ist eine Liste nützlicher grep-Befehle, um Dateien nach verdächtigen Zeichenfolgen zu scannen. Führen Sie diese im Hauptverzeichnis Ihrer Seite aus.

#Die häufigsten Malware-Signaturen

1. Suche nach der Funktion eval (in modernem Code sehr selten legitim verwendet):

   grep -rl --include=*.php 'eval(' .

2. Suche nach versteckten Iframes und Skripten in PHP-Dateien:

   grep -rl --include=*.php '<script' .
   grep -rl --include=*.php '<iframe' .

3. Suche nach kodierten und komprimierten Zeichenfolgen (Base64, Rot13, gzinflate):

   grep -rl --include=*.php 'base64_decode' .
   grep -rl --include=*.php 'str_rot13' .
   grep -rl --include=*.php 'gzinflate' .

4. Suche nach unescape in JavaScript:

   grep -rl --include=*.js 'unescape(' .

Verwenden Sie bei diesen Mustern nicht die Option -w. Mit -w verlangt grep, dass der Treffer an einem Zeichen endet, das kein Buchstabe und keine Ziffer ist. Deshalb findet eval( dann die häufigste Form nicht, nämlich eval(base64_decode(.

#Fehlalarme von echter Malware unterscheiden

Nicht jedes Ergebnis ist ein Virus.

• Plugins wie Elementor oder Visual Composer können base64_decode in ihrem Code haben.
• Achten Sie auf Dateien an seltsamen Orten, z.B. wp-content/uploads/2024/03/avatar.php. Der Ordner uploads sollte keine PHP-Dateien enthalten.

So finden Sie alle PHP-Dateien im Uploads-Ordner:

find ./wp-content/uploads -name "*.php"

Was Sie hier finden, behandeln Sie als verdächtig, bis das Gegenteil feststeht. Nur sehr spezielle Plugins legen PHP in diesem Ordner ab, und das sollte der Plugin-Autor dokumentiert haben.

#Gehackte WordPress-Seite so sehen, wie Google sie sieht

Viele Angriffe zeigen den Spam nur dem Googlebot oder Besuchern, die über die Suche kommen (Cloaking). Der Betreiber ruft die Seite direkt auf und sieht alles normal. Googles Bericht zu Sicherheitsproblemen rät davon ab, infizierte Seiten im Browser zu öffnen, weil Malware Schwachstellen des Browsers selbst ausnutzen kann, und nennt zwei Alternativen.

Die erste ist das URL-Prüftool in der Search Console, das die Seite so zeigt, wie Google sie erhält. Die zweite ist curl (oder wget) mit gesetztem Referer und User-Agent, um einen Besucher aus der Google-Suche nachzuahmen:

curl -sv --referer "https://www.google.com/" \
  --user-agent "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://ihre-domain.de/ -o seite.html
grep -iE 'eval|base64_decode|unescape|<iframe' seite.html

Wiederholen Sie die Anfrage ohne Referer und vergleichen Sie die Antworten. Ein 301 oder 302, der nur mit Google als Referer erscheint, deutet auf Regeln in der .htaccess oder im PHP-Code. Google nennt drei Formen von Weiterleitungen, die Angreifer nutzen: Regeln in der Serverkonfiguration (.htaccess, httpd.conf), JavaScript-Weiterleitungen abhängig von document.referrer und Skripte, die von einer fremden Domain geladen werden.

#WordPress-Core-Dateien mit WP-CLI ersetzen

Das manuelle Entfernen eines Virus aus WordPress-Core-Dateien (wp-admin, wp-includes) ist eine Sisyphusarbeit. Die schnellste und zuverlässigste Methode ist, alle Systemdateien durch saubere Originale zu ersetzen.

Dies ist ein sicherer Prozess, wenn Sie die Core-Dateien nicht manuell modifiziert haben (was Sie ohnehin nicht tun sollten).

Die WordPress-Dokumentation verlangt, dieselbe Version neu zu installieren, die die Website gerade nutzt: Eine ältere oder neuere Version kann die Website lahmlegen. Ohne --version lädt wp core download die neueste Version, geben Sie also die aktuelle an:

## Dieselbe WordPress-Version herunterladen (Dateien ersetzen)
wp core download --version=$(wp core version --allow-root) --force --skip-content --allow-root

Das Flag --skip-content ist entscheidend, es sorgt dafür, dass WP-CLI Ihren wp-content-Ordner, in dem sich Ihre Bilder, Themes und Plugins befinden, nicht überschreibt.

Eine Grenze sollten Sie kennen. Laut derselben FAQ überschreiben Installer in der Regel nur vorhandene Dateien, und Angriffe legen oft neue Dateien an. Eine zusätzliche Datei in wp-includes überlebt --force. Die Prüfsummenkontrolle im nächsten Abschnitt zeigt sie an.

Wenn Sie kein WP-CLI haben:

1. Laden Sie das WordPress-Paket in derselben Version von wordpress.org herunter.
2. Entpacken Sie es lokal.
3. Löschen Sie daraus den Ordner wp-content und die Datei wp-config-sample.php.
4. Löschen Sie auf dem Server die Ordner wp-admin und wp-includes, laden Sie die aus dem Paket per SFTP hoch und überschreiben Sie dann die Dateien im Hauptverzeichnis.

Die WordPress-FAQ rät in dieser Lage von der Neuinstallations-Option im Dashboard ab, aus demselben Grund: Er überschreibt nur.

#Core und Plugins mit wp core verify-checksums prüfen

WP-CLI vergleicht die installierten Dateien mit den MD5-Prüfsummen, die WordPress.org veröffentlicht. Der Befehl wp core verify-checksums läuft im Hook before_wp_load, lädt WordPress also nicht. Das zählt, wenn WordPress selbst kompromittiert sein kann.

wp core verify-checksums --allow-root

Bei einem sauberen Core lautet das Ergebnis:

Success: WordPress installation verifies against checksums.

Bei einem veränderten Core erscheinen Warnungen pro Datei und ein abschließender Fehler:

Warning: File doesn't verify against checksum: wp-includes/version.php
Warning: File should not exist: wp-includes/zusatzdatei.php
Error: WordPress installation doesn't verify against checksums.

Nach einem Angriff zählt vor allem die Warnung “File should not exist”. Der Quellcode des Befehls zeigt, dass er standardmäßig zusätzliche Dateien in wp-admin, wp-includes und die wp-*.php-Dateien im Hauptverzeichnis prüft (außer wp-config.php). Mit --include-root (seit Version 2.8.0) prüft er das ganze Hauptverzeichnis, außer .htaccess, .maintenance, wp-config.php und wp-content. Nutzt die Website ein deutsches Sprachpaket, ergänzen Sie --locale=de_DE, sonst meldet der Befehl übersetzte Dateien als verändert. Der Name zusatzdatei.php im Beispiel ist nur ein Platzhalter: Bei einem echten Angriff trägt die Datei einen Namen, der legitim aussieht.

Für Plugins gibt es das Gegenstück wp plugin verify-checksums:

wp plugin verify-checksums --all --allow-root

Der Befehl vergleicht jedes Plugin mit den Prüfsummen von WordPress.org und meldet hinzugefügte Dateien (“File was added”) und veränderte (“Checksum does not match”). Für Plugins, die nicht im WordPress.org-Verzeichnis stehen, wie die meisten kostenpflichtigen, gibt es keine Prüfsummen: WP-CLI gibt eine Warnung aus und überspringt das Plugin. Diese müssen Sie durch ein sauberes Paket des Herstellers ersetzen.

#Virus aus wp-content in WordPress entfernen

Hier liegt meistens das Problem.

#Plugins und Themes

Wenn möglich, löschen Sie alle kostenlosen Plugins und installieren Sie sie neu. Viren heften sich oft an jede .js oder .php Datei auf dem Server.

## Plugin aus dem Repository neu installieren (z.B. contact-form-7)
wp plugin install contact-form-7 --force --allow-root

Für kostenpflichtige Plugins müssen Sie saubere Pakete vom Hersteller herunterladen und die Dateien per SFTP ersetzen.

Überprüfen Sie Ihr Theme. Wenn Sie ein Child Theme verwenden, überprüfen Sie manuell die functions.php und header.php. Dies sind Lieblingsplätze für Schadcode. Die WordPress-FAQ ergänzt index.php und footer.php, weil eine Änderung dort jeden Seitenaufruf betrifft.

#Uploads-Ordner

Wie bereits erwähnt, sollte der Medienordner (wp-content/uploads) nur Bilder, PDFs und Dokumente enthalten. Radikale Reinigung (löscht alle PHP-Skripte aus Uploads):

find ./wp-content/uploads -name "*.php" -delete

Warnung: Prüfen Sie die Liste vorher (ohne -delete), um sicherzustellen, dass Sie nichts Legitimes löschen.

#WordPress-Datenbank von Spam und falschen Admins bereinigen

Infektionen enden oft nicht bei den Dateien. Viren injizieren Spam-Links in Post-Inhalte oder erstellen gefälschte Administratoren.

Loggen Sie sich in die Datenbank ein (phpMyAdmin oder wp db cli) und prüfen Sie:

1. Gefälschte Administratoren:

   SELECT * FROM wp_users;

   Suchen Sie nach Benutzern, die Sie nicht kennen, oft mit .ru, .cn Domains oder zufälligen Zeichenfolgen. Löschen Sie diese sofort.

2. Spam im Inhalt: “Japanese Keyword Hack”-Viren injizieren tausende von Seiten mit chinesischen/japanischen Schriftzeichen, die für Fälschungen werben. Prüfen Sie die Tabelle wp_posts:

   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%eval(%';

Hat Ihre Website plötzlich tausende neue Seiten im Google-Index, müssen Sie diese Einträge aus der Datenbank bereinigen und dann eine Sitemap an die Google Search Console senden, um das Entfernen des Mülls aus dem Index zu beschleunigen.

#WordPress-Administratoren mit wp user list auflisten

Die Abfrage SELECT * FROM wp_users zeigt alle Benutzer, aber nicht deren Rolle, die in wp_usermeta steht. Der Befehl wp user list verbindet beide Tabellen und filtert nach Rolle:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --allow-root

Vergleichen Sie die Liste mit den Personen, die tatsächlich Zugang haben. Die Spalte user_registered hilft, ein unbekanntes Konto mit dem Zeitpunkt des Vorfalls aus Ihrer Notiz zu verbinden. In einer Multisite-Installation listet --network die Benutzer des ganzen Netzwerks (ohne Rollen, weil derselbe Benutzer auf jeder Website eine andere Rolle haben kann). Prüfen Sie dort auch die Super-Admins:

wp super-admin list --allow-root

Hat der Angreifer Ihr Administratorkonto übernommen und Sie kommen nicht mehr hinein, beschreibt die WordPress-FAQ den Ausweg: Melden Sie sich per phpMyAdmin oder Adminer an der Datenbank an, ändern Sie in der Tabelle wp_users die E-Mail-Adresse Ihres Kontos auf eine Adresse, die Sie kontrollieren, und nutzen Sie den Link zur Passwort-Wiederherstellung auf der Login-Seite.

#wp-config.php und .htaccess nach einem Hack prüfen

Malware modifiziert häufig diese beiden Schlüsseldateien.

1. wp-config.php: Öffnen Sie sie und prüfen Sie auf seltsame Zeilen. Oft werden Verweise auf temporäre Dateien hinzugefügt:

   include '\tmp\sess_dsf43...'; // VERDÄCHTIG!

   Vergleichen Sie Ihre Datei mit wp-config-sample.php. Sie sollte nur Datenbankzugangsdaten und Konstantendefinitionen enthalten.

2. .htaccess: Viren fügen hier oft Regeln hinzu, die Suchmaschinen-Traffic (z.B. wenn User-Agent Googlebot ist) auf Seiten mit Malware umleiten, während Sie (bei direktem Zugriff) die normale Seite sehen. Wenn Sie unsicher sind, generieren Sie die Standard-WordPress-.htaccess-Datei:

   # BEGIN WordPress
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   </IfModule>
   # END WordPress

Die WordPress-FAQ erinnert daran, dass die .htaccess nicht nur im Hauptverzeichnis liegt: Sie kann auch in anderen Verzeichnissen derselben Installation stecken. Suchen Sie alle:

find . -name ".htaccess"

#WordPress nach einem Hack absichern

Seite bereinigt? Gut. Jetzt schließen Sie die Türen ab, damit der Einbrecher nicht zurückkommt.

1. Passwörter ändern:

   • Für alle Administratorkonten.
   • Für die Datenbank.
   • Für FTP/SFTP und das Hosting-Panel.

   Die WordPress-FAQ besteht auf einem Detail: Wenn Sie die Passwörter schon bei der Entdeckung geändert haben, ändern Sie sie noch einmal, nachdem Sie bestätigt haben, dass die Website sauber ist. Ändern Sie Datenbankbenutzer oder Datenbankpasswort, tragen Sie die neuen Werte in wp-config.php ein.

2. Salt Keys ändern: Dies erzwingt ein Ausloggen aller Benutzer. Bearbeiten Sie wp-config.php und ersetzen Sie den Abschnitt der Schlüssel durch neue, die hier generiert wurden: https://api.wordpress.org/secret-key/1.1/salt/ Oder verwenden Sie WP-CLI:

   wp config shuffle-salts

3. Dateibearbeitung im Dashboard deaktivieren: Fügen Sie zu wp-config.php hinzu:

   define( 'DISALLOW_FILE_EDIT', true );

   Dies verhindert, dass ein Hacker, der ein Admin-Passwort erlangt, Theme-/Plugin-Dateien direkt über das Panel bearbeiten kann. Der Hardening-Leitfaden erklärt, dass die Konstante dem Entzug der Berechtigungen edit_themes, edit_plugins und edit_files für alle Benutzer entspricht, und dass der Dashboard-Editor oft das erste Werkzeug eines Angreifers nach dem Login ist.

4. XML-RPC deaktivieren: Wenn Sie die mobile WordPress-App oder Jetpack nicht nutzen, ist XML-RPC nur ein Sicherheitsloch (genutzt für DDoS- und Brute-Force-Angriffe). Fügen Sie zu .htaccess hinzu:

   <Files xmlrpc.php>
   order deny,allow
   deny from all
   </Files>

   Das ist die Syntax von Apache 2.2. Unter Apache 2.4 ohne das Modul mod_access_compat verwenden Sie Require all denied im <Files>-Block.

#Dateirechte und Datenbankbenutzer nach der Bereinigung

Der Hardening-Leitfaden nennt konkrete Werte. Verzeichnisse mit 755, Dateien mit 644, beschreibbar nur durch das Benutzerkonto, dem die Website gehört:

find /pfad/zu/wordpress/ -type d -exec chmod 755 {} \;
find /pfad/zu/wordpress/ -type f -exec chmod 644 {} \;

Die wp-config.php sollte nur für Sie und den Webserver lesbar sein, was in der Regel 400 oder 440 bedeutet.

Derselbe Leitfaden hält fest, dass der MySQL-Benutzer für den normalen Betrieb nur SELECT, INSERT, UPDATE und DELETE braucht. Im selben Absatz warnt er aber, dass der Entzug von ALTER und ähnlichen Rechten nicht empfohlen wird, solange kein getesteter Backup-Plan existiert, weil manche Updates das Datenbankschema ändern. Nach einem Angriff ist ein anderer Schritt nützlicher: Laufen mehrere Websites auf demselben Server, sollte jede ihre eigene Datenbank und ihren eigenen Benutzer haben, damit eine kompromittierte Website keinen Zugang zu den anderen öffnet.

Zuletzt die Logs. Der Hardening-Leitfaden beschreibt sie als Hauptquelle, um zu verstehen, wie der Angreifer hereinkam: Die Zugriffslogs des Servers zeigen IP, Uhrzeit und Anfragen, einschließlich Brute-Force-Versuchen und Versuchen, Dateien einzubinden. Die FAQ nennt diese Phase Forensik, und das Ziel ist, den Angriffsweg zu schließen und nicht nur die Symptome zu löschen. Der Leitfaden empfiehlt außerdem regelmäßige Kopien der kompletten Website an einem vertrauenswürdigen Ort, denn einen Angriff, der erst Tage später auffällt, vergleichen Sie nur mit einer Kopie von davor.

#Wie Sie prüfen, ob WordPress nicht mehr infiziert ist

Eine Bereinigung ist erst abgeschlossen, wenn die Website dieselben Prüfungen besteht, die das Problem aufgedeckt haben. Wiederholen Sie in den folgenden Tagen die grep-Befehle von oben, find ./wp-content/uploads -name "*.php" und wp core verify-checksums. Eine leere Liste im Uploads-Ordner ist das erwartete Ergebnis. Eine neue PHP-Datei dort bedeutet, dass der Zugang noch offen ist.

Gehen Sie auch zurück in die Datenbank. Führen Sie wp user list --role=administrator erneut aus, um sicherzustellen, dass kein unbekannter Administrator wieder aufgetaucht ist, und wiederholen Sie die Abfragen auf wp_posts nach <script und eval(. Vergleichen Sie wp-config.php und .htaccess mit den sauberen Versionen, weil Malware diese beiden Dateien am häufigsten verändert.

War die Infektion ein Japanese Keyword Hack, beobachten Sie den Index in der Google Search Console, nachdem Sie die Sitemap eingereicht haben, und prüfen Sie, ob die Spam-Seiten verschwinden.

Schlägt eine Prüfung fehl, wiederholen Sie nicht einfach die Bereinigung. Suchen Sie zuerst das veraltete Plugin, das Nulled-Theme oder das schwache Passwort, über das der Angreifer hereinkam, und bereinigen Sie erst dann erneut.

#Bericht zu Sicherheitsproblemen und Überprüfungsantrag in der Search Console

Hat Google die Website markiert, verschwindet die Warnung erst nach einer Überprüfung. Der Bericht zu Sicherheitsproblemen in der Search Console ist laut Google die maßgebliche Quelle: Safe Browsing zeigt Warnungen abhängig vom Browsing-Kontext, deshalb können Sie die Warnung in Ihrem Browser möglicherweise nicht nachvollziehen. Der Bericht ordnet die Probleme drei Kategorien zu: gehackte Inhalte, Malware und unerwünschte Software sowie Social Engineering.

Zu jedem Problem gibt es Beispiel-URLs. Google weist darauf hin, dass es nur eine Stichprobe ist und dass ein Problem ohne Beispiele nicht bedeutet, dass keine Seite betroffen ist. Beheben Sie das Problem auf der ganzen Website: Wer nur einige Seiten korrigiert, bekommt keine teilweise Rückkehr in die Suchergebnisse. Listet der Bericht mehrere Probleme, beheben Sie alle.

Sind alle behoben, nutzen Sie im Bericht die Option Request Review (Überprüfung anfordern). Laut Google leistet ein guter Antrag drei Dinge: Er erklärt das genaue Problem, beschreibt die Schritte zur Behebung und dokumentiert das Ergebnis. Hier dienen die Vorfallsnotiz vom Anfang und die Ausgabe der Prüfbefehle als Beleg.

Die Überprüfung dauert einige Tage bis einige Wochen, und Google informiert per E-Mail, wenn der Antrag eingegangen und wenn er abgeschlossen ist. Reichen Sie den Antrag nicht erneut ein, bevor eine Entscheidung vorliegt. Ein Antrag, der gestellt wird, bevor das Problem behoben ist, kann den nächsten verzögern und sogar dazu führen, dass die Website als Wiederholungstäter markiert wird.

Haben Sie kürzlich eine Website gekauft, die diese Probleme schon mitbrachte, bittet Google, das im Antrag anzugeben, nachdem alles behoben ist, was der Bericht auflistet.

#Zusammenfassung

Der Kampf gegen Malware ist ein Wettrüsten. Der beste Schutz ist jedoch kein “magisches Sicherheits-Plugin”, sondern digitale Hygiene:

1. Sofortige Updates von WordPress und Plugins.
2. Keine Installation von “nulled” (raubkopierten) Plugins und Themes, einer häufigen Infektionsquelle.
3. Ein Off-Site-Backup (z.B. in der Cloud).

Wenn Sie das Gefühl haben, dass der technische Aspekt Sie überfordert, beauftragen Sie lieber Profis. Eine schlecht durchgeführte Reinigung kann eine Hintertür (Backdoor) offen lassen, durch die der Hacker nach ein paar Tagen zurückkehrt, und Sie verlieren noch mehr Geld und Vertrauen in den Augen von Google.

Mehr über unsere WordPress-Sicherheitsaudits.