WordPress gehackt: was zu tun ist, Schritt für Schritt

Eine rote Warnung in Chrome, eine Weiterleitung auf eine fremde Domain und ein Administrationsbereich, in dem alles aussieht wie immer. Der Notfallablauf speziell für WordPress: was in der ersten Stunde verboten ist, wo die Infektion wirklich sitzt und wie die Google-Warnung wieder verschwindet.

Donnerstagmorgen ruft ein Kunde an und sagt, Chrome zeige ihm statt Ihres Shops eine rote Vollbildwarnung; Sie öffnen die Website auf dem Handy, und nach anderthalb Sekunden wirft der Browser Sie auf eine fremde Domain, während am Arbeitsrechner, an dem der Administrationsbereich seit Montag offen steht, alles aussieht wie immer. Genau so sieht es meistens aus, wenn WordPress gehackt wurde – keine verunstaltete Startseite mit der Signatur des Angreifers, sondern eine Website, die dem Betreiber ein anderes Gesicht zeigt als dem Besucher, weshalb die ersten Stunden oft im Streit darüber vergehen, ob das Problem überhaupt existiert.

Die Fragen, die hier beantwortet werden, kommen fast immer in dieser Reihenfolge: Was darf man in der ersten Stunde tun und was auf keinen Fall, solange niemand weiß, wie tief der Angreifer gekommen ist; wo in einer WordPress-Installation der Code typischerweise liegt, denn ohne das ist jede Bereinigung Raterei; und wie man Google dazu bringt, die Warnung zu entfernen, ohne sich den zweiten Versuch zu verbauen. Dazwischen liegt, was Betreiber am häufigsten auslassen – der Wechsel der Zugangsdaten zum richtigen Zeitpunkt und in der richtigen Reihenfolge.

Alles, was in den nächsten Stunden zu tun ist, steht hier; zwischendurch muss niemand woanders nachschlagen. Außen vor bleibt nur, was danach nützlich wird, wenn die Website wieder läuft – Backup-Strategie, Systemhärtung und der Schutz vor dem nächsten Mal, der plattformunabhängig derselbe ist –, und auf den gesonderten Leitfaden dazu verweisen wir weiter unten. Es geht um das, was WordPress besonders macht: das Plugin-Ökosystem, das Verzeichnis wp-content, die Datenbanktabellen, in denen eine Infektion die Dateibereinigung überlebt, und Befehle, die mehr versprechen, als sie prüfen. In unserer Praxis entscheiden diese vier Dinge, ob eine Website nach einem Tag sauber ist oder erst nach dem dritten Versuch.

Die erste Stunde: löschen Sie nichts

Die erste Reaktion ist fast immer eine von zweien – den Dateimanager beim Hoster öffnen, dort etwas Fremdes finden und es löschen, oder den Knopf drücken, der das Backup von gestern zurückspielt. Wir bitten darum, weder das eine noch das andere zu tun, und der Grund dafür ist praktisch, nicht bürokratisch. Die Eile ist verständlich, denn jede Stunde mit der roten Warnung kostet Besucher; doch gerade in der Eile fallen jene beiden Entscheidungen, die eine Wiederherstellung von acht Stunden auf eine Woche strecken, und beide sind unumkehrbar.

Sind die infizierten Dateien erst gelöscht, verschwindet auch das einzige Material, aus dem sich später der Einbruchspunkt bestimmen lässt: die Änderungszeitpunkte der Dateien, der Inhalt der vom Angreifer hochgeladenen Skripte und die Einträge im Zugriffsprotokoll des Servers, die zu diesen Zeitpunkten passen. Ohne Einbruchspunkt ist jede Bereinigung nur Symptombehandlung, und was das kostet, ist beziffert worden – in einer Studie von Google und der University of California, Berkeley zu 760.935 Hacking-Fällen zwischen Juli 2014 und Juni 2015 wurden 12 % der Websites innerhalb von 30 Tagen erneut gehackt, weil nur die Symptome und nicht die Ursache beseitigt worden waren (Li u. a., WWW 2016).

Deshalb steht am Anfang eine vollständige Kopie – alle Dateien und die Datenbank in einem Zug, bevor auch nur ein Byte angefasst wird –, denn die sichtbare Weiterleitung oder die verunstaltete Startseite ist selten alles, was auf der Website geschieht: Sucuri fand 2023 auf 49,21 % der infizierten Websites mindestens eine Backdoor (Hintertür) und entfernte im Lauf des Jahres 21.062 solcher Programme (Sucuri, „2023 Hacked Website & Malware Threat Report“, Juni 2024). Bewahren Sie diese Kopie außerhalb desselben Servers auf, denn genau dort hat der Angreifer weiterhin Zugriff.

Der nächste Anruf gilt dem Hosting-Anbieter, und zwar nicht aus Höflichkeit: Dort liegen die Zugriffsprotokolle, die in Ihrem eigenen Konto meist nur wenige Tage zurückreichen, und auf einem Shared Server muss der Anbieter prüfen, ob in den Nachbarkonten dasselbe passiert. Werden auf der Website Zahlungen entgegengenommen oder personenbezogene Daten eingegeben, muss sie in diesem Moment abgeschaltet oder in den Wartungsmodus versetzt werden – jeder Besucher, der in der nächsten Stunde seine Kartendaten eintippt, ist ein eigenes Problem, das Sie noch nicht haben. Der Wartungsmodus kostet einen Tagesumsatz; der verpasste Moment kostet ein Schreiben an die Kunden.

Lässt sich wp-admin nicht mehr öffnen – auf einer gehackten Website kommt das vor –, gelingt der Wartungsmodus über den Administrationsbereich nicht mehr, und es bleiben zwei Wege: in der .htaccess im Stammverzeichnis eine Regel ergänzen, die alle außer Ihrer IP-Adresse auf eine statische Seite mit dem Hinweis auf Wartungsarbeiten schickt, oder im selben Telefonat den Hoster bitten, das Konto vorübergehend zu sperren. Die zweite Variante wirkt grob, funktioniert aber auch dann, wenn Sie an die Dateien nicht mehr herankommen.

Das Backup von gestern sieht nach dem schnellsten Weg zurück aus, und manchmal ist es das auch – aber nur, wenn bekannt ist, an welchem Tag der Angreifer hereinkam. In unserer Praxis fällt eine Infektion deutlich später auf, als sie begann: Erst hält der Code still, dann spielt er Spam-Seiten oder Weiterleitungen aus – die Backdoor steckt im gestrigen Backup also höchstwahrscheinlich schon drin. Ein Rückspielen versteckt für ein paar Stunden die Symptome und versetzt die Website in genau den Zustand zurück, in dem sie gehackt wurde; deshalb beginnen wir die Wiederherstellung einer gehackten Website zwar meist binnen weniger Stunden, fangen aber auch in der Eile mit der Kopie an und nicht mit dem Löschen – selbst wenn der Kunde einfach nur schnell alles sauber haben will.

WordPress gehackt: die Anzeichen, an denen Sie es erkennen

Eine Weiterleitung, die beim Besucher aus einem Google-Ergebnis greift, aber ausbleibt, wenn man die Adresse selbst eintippt, ist kein Missverständnis, sondern die bewusste Entscheidung des Angreifers: In Googles Spam-Richtlinien sind Weiterleitungen eine eigens benannte Form gehackter Inhalte, bei der Angreifer Code einschleusen, der „einige Nutzer zu schädlichen Seiten oder Spamseiten weiterleitet“ (Google Search Central, geprüft im August 2026). Das Wort „einige“ führt den Betreiber in die Irre. Die Prüfung dauert eine Minute: die Website im Inkognitofenster öffnen, dann über ein Google-Ergebnis – und beides auf dem Handy wiederholen.

Die zweite Gruppe von Anzeichen zeigt sich im Administrationsbereich und ist erheblich konkreter: wp-admin liefert plötzlich einen 404, das Anmeldeformular lädt nach korrektem Passwort einfach neu, in der Benutzerliste steht ein Administratorkonto, das niemand aus Ihrem Team angelegt hat, oder unter Einstellungen → Allgemein steht als Website-Adresse (URL) nicht mehr Ihre eigene. In der Datenbank sind es beim letzten dieser Anzeichen nur zwei Zeilen in der Tabelle wp_options – siteurl und home –, und genau deshalb können die Adresse in den Einstellungen und die Adresse, auf der Ihr Besucher landet, auseinanderfallen.

Die dritte Gruppe kommt von außen und tut am meisten weh, weil jemand anderes Ihnen den Zustand Ihrer Website mitteilt: Der Hoster sperrt ohne Vorwarnung das Konto, aus dem Spam versendet wurde, in der Search Console erscheint ein Sicherheitsproblem, oder in den Suchergebnissen steht neben Ihrer Website der Hinweis „Diese Website wurde möglicherweise gehackt“, den Google zeigt, wenn es annimmt, dass ein Angreifer bestehende Seiten verändert oder neue Spam-Seiten hinzugefügt hat (Google Suche-Hilfe, geprüft im August 2026). Diesen Hinweis setzt Google selbst und nicht auf eine Beschwerde hin, und er erscheint auch dann, wenn Ihnen die Website tadellos vorkommt.

Die Bezeichnungen sind keine akademische Frage, denn mit ihnen suchen Sie nach einer Lösung und beurteilen, ob ein Dienstleister Ihren Fall versteht: Google nennt drei – das Hacking durch unsinnige Inhalte (gibberish hack), den japanischen Keyword-Hack und das Hacking durch verborgene Keywords und Links (cloaked keywords and links hack), bei dem die angelegten Seiten der Suchmaschine einen anderen Inhalt zeigen als dem Besucher. Der in der Branche verbreitete Pharma-Hack stammt vom Sicherheitsunternehmen Sucuri (2020) und kommt in Googles Dokumentation nicht vor. Die Prüfung ist für alle drei dieselbe: Geben Sie eine site:-Abfrage mit Ihrer Domain ein, und Seiten, die niemand in Ihrem Unternehmen geschrieben hat, sehen Sie sofort. In der japanischen Variante sind es automatisch erzeugte Seiten mit japanischen Überschriften in zufällig benannten Verzeichnissen unter Ihrer Domain.

Und jetzt der unangenehme Teil: Ein sauberes Scan-Ergebnis beweist nicht, dass die Website sauber ist. Ein Scanner sieht nur, was der Server ihm zeigt, während der Code des Angreifers Scanner und Suchmaschinen häufig erkennt – und Google warnt im Leitfaden zum Hacking durch verborgene Keywords und Links, dass ein Hack oft so versteckt wird, dass dem Betreiber das Problem als bereits erledigt erscheint. Ist der Scan sauber, beschwert sich der Hoster aber über ausgehende Mails, glauben Sie dem Hoster. Angebracht ist dann ein Website-Sicherheitsaudit mit einer Prüfung von Dateien und Protokollen von Hand, denn ein Scanner beantwortet nur, ob etwas aus einer Liste bekannter Muster auf der Website liegt, und nicht, ob dort immer noch jemand ist.

Wo das WordPress-Risiko tatsächlich liegt

Wenn die Ursache in unserer Praxis endlich gefunden ist, ist sie fast nie der WordPress-Kern selbst. Der Patchstack-Bericht „State of WordPress Security in 2026“ zählt 11.334 neue Sicherheitslücken, die 2025 im WordPress-Ökosystem entdeckt wurden – 42 % mehr als im Jahr davor –, und wichtig für Sie ist gerade jetzt die Verteilung dieser Zahlen: 91 % davon entfielen auf Plugins, 9 % auf Themes, im WordPress-Kern selbst wurden im ganzen Jahr dagegen nur sechs gemeldet, und alle waren von niedriger Priorität. Nahezu jede neu entdeckte Sicherheitslücke steckt also nicht in dem WordPress, das Sie irgendwann installiert haben, sondern in dem, was über die Jahre dazugekommen ist.

Jedes Plugin ist eine eigene Codebasis, geschrieben von einem eigenen Autor mit einer eigenen – und ziemlich oft längst eingestellten – Update-Disziplin; eine Website mit vierzig Plugins hat deshalb nicht ein Sicherheitsproblem, sondern vierzig voneinander unabhängige. In unserer Praxis kommt die typische Unternehmenswebsite mit zehn bis fünfzehn Plugins aus; der Rest stammt meist aus längst vergessenen Aufgaben: eine Galerie, die niemand mehr zeigt, ein Formular, das durch ein anderes ersetzt wurde, ein Slider, den das aktuelle Design nicht mehr verwendet. Wenn wir Entwicklung und Wartung einer WordPress-Website übernehmen, steht die Verringerung der Plugin-Zahl am Anfang der Arbeit und nicht an ihrem Ende.

Und hier ist der Fehler, der sich häufiger wiederholt als jeder andere: Das überflüssige Plugin wird deaktiviert statt gelöscht – die Deaktivierung sagt WordPress lediglich, es nicht mehr zu laden, doch die Dateien bleiben auf dem Server, ein Teil davon ist weiterhin direkt über HTTP erreichbar, und dem Skript eines Angreifers genügt der Pfad. Wordfence dokumentierte im Juni 2021 eine aktiv ausgenutzte Zero-Day-Lücke im Plugin Fancy Product Designer, die sich in manchen Konfigurationen auch dann noch ausnutzen ließ, wenn das Plugin deaktiviert war, und riet, es nicht abzuschalten, sondern zu deinstallieren. Wenn Sie ein Plugin nicht mehr brauchen, gehört es nicht ausgegraut in die Plugin-Liste, sondern vom Server herunter.

Warum das alles automatisch und ohne jeden persönlichen Anlass geschieht, erklärt die Größenordnung: Nach den Daten von W3Techs betreibt WordPress (Stand 5. August 2026) 41,2 % aller Websites im Netz. In einem Ökosystem dieser Größe ist jede veröffentlichte Plugin-Sicherheitslücke sofort gegen eine sehr große Zahl gleich gebauter Websites einsetzbar, weshalb es sich mehr lohnt, Angriffe zu automatisieren, statt sie gezielt zu führen – ein Skript liest Versionsnummern, keine Firmennamen. Niemand hat sich ausgerechnet Ihre Website ausgesucht, und genau deshalb wird auch eine kleine Unternehmenswebsite ohne Kundendaten und ohne Zahlungen ebenso beiläufig gehackt wie ein großer Onlineshop.

Wo der Angreifer den Code in einer WordPress-Installation versteckt

Die erste Stelle, die wir öffnen, ist wp-content/uploads – ein Verzeichnis, in dem im Grunde nur Bilder, PDF-Dateien und Videos liegen und in dem niemals eine PHP-Datei ausgeführt werden sollte. Liegt dort zwischen den Produktfotos von 2019 eine Datei mit der Endung .php, ist sie nicht zufällig dorthin geraten: Fast immer ist es entweder ein Uploader, mit dem der Angreifer die nächsten Dateien auf den Server holt, oder eine Webshell, die Befehle im Namen Ihres Servers ausführt. Dass das Problem real und nicht theoretisch ist, zeigt sich schon daran, dass Sucuri und Wordfence je eine eigene Härtungsoption anbieten, die die PHP-Ausführung per .htaccess-Regel genau hier abschaltet.

Die zweite Stelle ist wp-content/mu-plugins. Was dort abgelegt wird, ist automatisch aktiv, lässt sich aus dem Administrationsbereich nicht deaktivieren und – was hier am schwersten wiegt – taucht in der gewöhnlichen Plugin-Liste nicht auf, sodass ein Betreiber monatelang auf einen scheinbar sauberen Administrationsbereich blickt; Sucuri beschrieb im Juli 2025 genau so einen Fall mit einer Backdoor in diesem Verzeichnis. Daneben prüfen wir immer die .htaccess im Stammverzeichnis wie in den Unterverzeichnissen, denn eine Weiterleitung, die nur bei Besuchern aus einer Suchmaschine oder nur auf Mobilgeräten greift, steht meistens genau dort – und sie ist der Grund, warum Ihnen Ihre eigene Website völlig normal erscheint.

Der Code steht oft auch in den ersten Zeilen vorhandener, vollkommen legitimer Dateien, am häufigsten am Anfang von wp-config.php und in der functions.php des Themes, und sieht dabei fast nie nach Schadcode aus: eine einzige lange Zeile mit einem Aufruf von base64_decode, gzinflate oder eval, gefolgt von Hunderten Leerzeilen, damit die Datei im Editor zu Ende zu sein scheint. Deshalb ist der Abgleich mit einem sauberen Original wertvoller als das Lesen mit dem Auge: Mit dem Auge findet diese Zeile niemand, weil niemand bis zur neunhundertsten Zeile scrollt.

Und dann die Datenbank, in die kein Dateiscanner schaut und in der drei Stellen zu prüfen sind: siteurl und home in wp_options, die der Angreifer überschreibt, damit die Ressourcen Ihrer Seite von einem fremden Server kommen; die Tabelle wp_users, in der gern ein Administratorkonto mit glaubwürdigem Namen auftaucht; und die Beiträge in wp_posts, wo versteckte Links und iframe-Codes mitten in alte Artikel eingebaut werden, die niemand mehr öffnet. Werden die Dateien bereinigt, die Injektion in der Datenbank aber nicht, ist die Infektion noch am selben Tag zurück. Die Zeile selbst läuft nicht: Ein kleiner Loader in der functions.php des Themes oder in mu-plugins liest und startet sie bei jedem Aufruf – und dieses Paar stellt die gelöschten Dateien schneller wieder her, als Sie prüfen können. Deshalb sind Datei- und Datenbankbereinigung bei uns in der Wiederherstellung einer gehackten Website eine Arbeit und nicht zwei.

Dateien mit geprüften Originalen abgleichen

Das erste Werkzeug nach der vollständigen Datei- und Datenbankkopie heißt wp core verify-checksums: Der Befehl vergleicht den Hashwert jeder Datei mit den auf WordPress.org veröffentlichten Prüfsummen und zeigt sofort, welche Dateien verändert wurden und welche in der Installation nichts zu suchen haben. Das Problem beginnt dort, wo sein Umfang endet – geprüft werden nur wp-admin/, wp-includes/ und die wp-*-Dateien im Stammverzeichnis, während der Quellcode das gesamte wp-content, also Plugins, Themes und Uploads, bewusst auslässt (Quellcode des WP-CLI checksum-command, eingesehen am 5. August 2026). Eine Datei im Stammverzeichnis nimmt derselbe Quellcode eigens aus – wp-config.php –, weshalb ausgerechnet die Datei, in deren erste Zeilen am häufigsten Code geschrieben wird, unsichtbar bleibt. Ein sauberes Ergebnis bedeutet keine saubere Website.

Für Plugins gibt es den eigenen Befehl wp plugin verify-checksums, doch auch er vergleicht nur mit den Prüfsummen des Repositorys auf WordPress.org, sodass ein beim Entwickler gekauftes kommerzielles Plugin schlicht übersprungen wird; einen entsprechenden Befehl für Themes kennt die WP-CLI-Dokumentation überhaupt nicht (WP-CLI-Dokumentation, eingesehen am 5. August 2026). Der automatischen Prüfung entziehen sich damit Themes ebenso wie außerhalb des Repositorys gekaufte Plugins, und wp core verify-checksums lässt das gesamte wp-content aus – jenen Teil des Codes, in dem alle 11.334 von Patchstack für 2025 gezählten Sicherheitslücken entstanden sind, die sechs im Kern ausgenommen. Auf Websites, die wir übernehmen, ist ausgerechnet das Theme oft das Einzige, was nie jemand geprüft hat.

In unserer Praxis sind Prüfsummen deshalb ein Ausgangspunkt und keine Methode: Kern und Plugins behandeln wir nicht, wir ersetzen sie – dieselben Versionen aus der Originalquelle laden und die Verzeichnisse vollständig überschreiben statt Datei für Datei. Aus der alten Installation behalten wir wp-content/uploads, und auch das erst nach der Prüfung auf PHP-Dateien zwischen den Bildern – aus demselben Grund, aus dem sich das Abschalten der PHP-Ausführung in diesem Verzeichnis überhaupt lohnt. Das Theme stellen wir aus der Versionsverwaltung wieder her, sofern es eine gibt; sonst nehmen wir die vom Entwickler gelieferte Kopie und legen die Anpassungen bewusst und einzeln darüber, denn nur so lässt sich später sagen, welche Zeile von uns stammt und welche nicht.

Nur die schädliche Zeile zu finden und zu löschen klingt billiger, und genau deshalb ist es der am häufigsten wiederholte Fehler: Ein Angreifer hinterlässt selten nur einen Zugang, und eine einzige übersehene Backdoor macht die gesamte übrige Arbeit zunichte. Der Code liegt oft auf mehrere Dateien verteilt, hinter base64 oder gzinflate versteckt, in der Optionstabelle der Datenbank oder in eben jenem Verzeichnis mu-plugins, das der Administrationsbereich nicht anzeigt. Die Suche nach Mustern findet, was Sie kennen; das vollständige Ersetzen befreit auch von dem, was Sie nicht kennen.

Manches tun wir in dieser Phase bewusst nicht: Wir verlassen uns nicht auf ein Plugin, das infizierte Dateien per Knopfdruck „heilen“ will, denn es arbeitet mit derselben Liste bekannter Muster und obendrein in derselben Umgebung, zu der der Angreifer weiterhin Zugang hat. Wir vergleichen Dateien auch dann nicht von Hand, wenn die Website den Umfang einer Visitenkarte oder eines Blogs hat, weil eine frische Installation mit übertragenen Inhalten weniger Stunden kostet als der zeilenweise Abgleich zweier Verzeichnisse – und überprüfbar ist. Ein sorgfältiger manueller Abgleich ist dort am Platz, wo Theme oder Plugin einzigartig sind und keine Versionsverwaltung existiert; wie mit Backups umzugehen ist, damit diese Wahl überhaupt besteht, haben wir im allgemeinen Leitfaden zur Wiederherstellung beschrieben.

Schlüssel, Sitzungen und Passwörter – und was davon wirklich was bewirkt

Die Authentifizierungsschlüssel und Salts (security keys and salts) in der Datei wp-config.php verschlüsseln nichts, auch wenn fast jeder Leitfaden das behauptet: WordPress verwendet sie als Grundlage für den Schlüssel, mit dem die Funktion wp_generate_auth_cookie() das Authentifizierungs-Cookie per HMAC-SHA256 signiert, während das Cookie selbst Klartext mit Benutzername, Ablaufzeit und Sitzungstoken ist (WordPress Developer Resources, eingesehen am 5. August 2026). Werden diese Werte ausgetauscht, ist deshalb jede zuvor ausgestellte Signatur nicht mehr überprüfbar, und der Server weist jedes bis dahin ausgegebene Cookie zurück, selbst wenn die Sitzung formal noch gar nicht abgelaufen ist.

Die praktische Folge ist genau die, die man im Moment eines Hacks braucht: Die offizielle WordPress-Dokumentation beschreibt den Austausch der Schlüssel als Weg, jeden hinauszuwerfen, der noch angemeldet sein könnte (WordPress.org, „FAQ My site was hacked“, aktualisiert am 26. Juli 2026) – hält der Angreifer also eine gültige Sitzung in der Hand, endet sie im selben Augenblick. Mit den Sitzungen verlieren auch alle Nonce-Token ihre Gültigkeit, weshalb begonnene Formulare und halb abgeschlossene Bestellschritte abreißen – den Zeitpunkt wählen wir deshalb bewusst und nicht zufällig mitten am Arbeitstag.

Der Austausch von Schlüsseln und Salts ändert kein einziges Passwort. Die Passwort-Hashes bildet WordPress mit bcrypt und einem eigenen zufälligen Salt je Passwort, der mit den Konstanten in wp-config.php nichts zu tun hat (Funktion wp_hash_password(); bcrypt ist seit WordPress 6.8 der Standard), weshalb sich ein Angreifer, der das Administratorpasswort kennt oder sich rechtzeitig ein eigenes Konto angelegt hat, nach dem Schlüsselwechsel einfach neu anmeldet. Passwörter sind gesondert und ausnahmslos zu wechseln, auch die, die angeblich niemand kennt, und gleichzeitig ist die Benutzerliste nach Konten durchzugehen, die niemand aus Ihrem Team angelegt hat.

Mit WordPress endet die Liste der Zugangsdaten nicht: In einem Zug zu wechseln sind das Passwort des Hosting-Control-Panels, die Zugangsdaten für FTP und SFTP, das Passwort des Datenbankbenutzers samt dem zugehörigen Eintrag in wp-config.php sowie die SSH-Schlüssel, die man nicht wie ein Passwort ändert, sondern neu erzeugt, wobei der alte öffentliche Schlüssel aus der Datei authorized_keys gelöscht wird. Zuletzt sind alle auf der Website hinterlegten API-Schlüssel zu wechseln – Zahlungsanbieter, E-Mail-Versand, Versand- und Buchhaltungsintegrationen –, denn sie bleiben am längsten unangetastet: Im Alltag sieht sie niemand auf irgendeinem Bildschirm.

Gehen Sie davon aus, dass der Angreifer eine vollständige Kopie der Datenbank besitzt, denn das ist der billigste Schritt im ganzen Angriff: Alles, was in der Datenbank stand – Kunden-E-Mail-Adressen, Bestellhistorie, Passwort-Hashes und die in Plugin-Einstellungen hinterlegten Schlüssel –, gilt als in fremde Hände geraten. Wurde eines dieser Passwörter noch anderswo verwendet, ist auch jene Stelle kompromittiert, und das ist gewöhnlich der Moment, in dem das Gespräch von der Website auf die E-Mail-Konten, die Buchhaltung und das Zahlungskonto des Shops übergeht.

Die Reihenfolge wiegt ebenso schwer wie die Liste selbst: Schlüssel und Passwörter werden erst gewechselt, nachdem die Backdoors entfernt sind, denn sonst liest der Angreifer die neuen Werte gleich in der wp-config.php mit oder fängt die nächste Anmeldung ab. Genau diese Abfolge – erst die vollständige Kopie, dann die Ursache, dann die Bereinigung und ganz zuletzt die Zugangsdaten – ist der Punkt, an dem eine in Eigenregie begonnene Wiederherstellung am häufigsten hängen bleibt oder durcheinandergerät; deshalb übernehmen wir diesen Abschnitt selbst und übergeben am Ende einen schriftlichen Bericht darüber, was wann und warum geändert wurde.

Wie die Google-Warnung wieder verschwindet und was danach zu tun ist

Der Bericht „Sicherheitsprobleme“ in der Google Search Console ist die einzige Stelle, an der zu sehen ist, was Google auf Ihrer Website tatsächlich gefunden hat: Dort stehen die Art der Bedrohung und eine Auswahl betroffener Seiten, und davon hängt ab, was ein Besucher gerade zu sehen bekommt. Die Art der Bedrohung ändert nichts daran, was der Besucher sieht: Chrome unterscheidet die Überschrift der Warnung nicht mehr danach, ob Phishing, Schadsoftware oder unerwünschte Software gefunden wurde, sondern zeigt in jedem Fall dieselbe Vollbildwarnung, die auf Deutsch „Gefährliche Website“ heißt und niemanden auf die Seite lässt, während der bereits erwähnte Hinweis „Diese Website wurde möglicherweise gehackt“ in den Suchergebnissen nur ein Zusatz neben dem Link ist, durch den man hindurchklicken kann (Hilfeseite von Google Chrome zu gefährlichen Websites, geprüft im August 2026). Die älteren, nach Bedrohungsart unterschiedlichen Überschriften – etwa „Deceptive site ahead“ – verwendet Chrome nicht mehr, auch wenn sie in Teilen der Google-Dokumentation weiterhin zu finden sind. Das eine blockiert, das andere warnt, und das verändert, wie viel Zeit Ihnen wirklich bleibt.

Bevor Sie auf „Überprüfung anfordern“ klicken, muss feststehen, dass die Website wirklich sauber ist und nicht nur in Ihrem Browser sauber aussieht. Google warnt im Leitfaden zum Hacking durch verborgene Keywords und Links ausdrücklich davor, dass Angreifer den Eindruck erwecken, eine Seite sei bereits gelöscht oder repariert; deshalb muss jede ehemalige Spam-Seite mit der URL-Prüfung kontrolliert werden, die den Blick von Googlebot zeigt und nicht Ihren. Der zweite, am häufigsten ausgelassene Schritt ist die Inhaberliste: Beim japanischen Keyword-Hack trägt sich der Angreifer selbst als bestätigter Inhaber in der Search Console ein (Google-Dokumentation auf web.dev), und solange er dort steht, weiß er über den Zustand der Website genau so viel wie Sie.

Gesucht ist die Schaltfläche „Überprüfung anfordern“ im Bericht „Sicherheitsprobleme“ und nicht der „Antrag auf erneute Überprüfung“, den Google auf manuelle Maßnahmen bezieht; in den Antragstext gehören drei Dinge: was gefunden wurde, wie der Angreifer hereinkam und was konkret dagegen getan wurde. Eine Frist versprechen wir nicht, weil Google sie ebenfalls nicht verspricht: Die Dokumentationsseite zu Social Engineering schreibt, eine Überprüfung „kann mehrere Tage dauern“, die Search-Console-Hilfeseite zu Sicherheitsproblemen dagegen „einige Tage oder mehrere Wochen“ (beide geprüft im August 2026). Wenn Ihnen jemand konkrete 24 oder 72 Stunden nennt, wiederholt er eine Zahl, die in keiner Google-Quelle steht.

Eile kostet in diesem Schritt mehr als Warten. In derselben Studie von Google und der University of California, Berkeley erreichten 80 % der Betreiber schon im ersten Anlauf, dass ihre Website als sauber galt; die übrigen 20 % brauchten mehrere Anläufe und verbrachten im Median eine ganze Woche damit, den hinterlassenen Code herauszukämmen. Die Daten stammen aus den Jahren 2014 und 2015 und sind auch so zu lesen, doch an der Arithmetik hat sich nichts geändert: Ein abgelehnter Antrag bedeutet eine weitere Runde mit der Warnung – und beim zweiten Mal sind Sie kein Erstantragsteller mehr.

Ist die Warnung entfernt, ist die Arbeit nicht zu Ende, denn im Index bleiben die vom Angreifer angelegten Seiten stehen, und diese dürfen nicht auf die Startseite umgeleitet werden – sie müssen 404 oder 410 zurückgeben, damit Google sie ganz herausnimmt, während das Tool zum Entfernen in der Search Console sie nur vorübergehend ausblendet. Die Rankings kommen nicht auf Knopfdruck zurück: Die Seiten müssen neu indexiert werden, und das geschieht in Googles Takt, nicht in Ihrem. Wie sich Protokolldateien und Backups dabei nutzen lassen, damit der Ausgangspunkt beim nächsten Mal besser ist, haben wir im eigenen Leitfaden zur Wiederherstellung gehackter Websites beschrieben.

Wann Sie aufhören sollten, es selbst zu machen, und was es kostet

Einen Teil des hier Beschriebenen erledigt ein erfahrener Website-Betreiber selbst, und das sagen wir ohne Umschweife auch denen, die uns mit offener Search Console und dem bereits gefundenen schuldigen Plugin anrufen. Ist die Infektion eine einzelne verunstaltete Startseite, zeigen die Protokolldateien, welches Plugin sie hereingelassen hat, steht in der Benutzerliste kein fremder Administrator und existiert ein Backup von gestern, das Sie irgendwann tatsächlich einmal in einer Testumgebung zurückgespielt haben, dann kaufen Ihnen acht bezahlte Stunden ruhigeren Schlaf und kein schnelleres Ergebnis.

Es gibt vier Situationen, in denen wir raten aufzuhören, und die erste ist die erneute Infektion nach der Bereinigung: Wird eine Website ein zweites Mal gehackt, ist das keine Frage des Pechs, sondern der Beweis, dass der Einbruchspunkt offen steht – die dritte Bereinigung in derselben Umgebung kostet so viel wie die ersten beiden. Die zweite ist jeder Verdacht rund um Kunden- oder Zahlungsdaten, denn neben die technische Arbeit treten Pflichten gegenüber der Aufsichtsbehörde und Fristen, die sich nicht verlängern lassen. Die dritte ist eine Website, mit der ein Unternehmen jeden Tag Geld verdient, die vierte schlicht fehlende Zeit: Eine Bereinigung ist intellektuell nicht schwierig, aber lang, eintönig und verzeiht keine ausgelassene Datei.

Unsere Wiederherstellung gehackter Websites kostet 90 € pro Stunde zzgl. MwSt., mit einem Minimum von acht Arbeitsstunden, die im Voraus bezahlt werden. Wir beginnen meist binnen weniger Stunden nach der Anfrage, und der gesamte Ablauf vom Beginn bis zur Übergabe dauert meist 8–72 Stunden; der Unterschied zwischen acht und zweiundsiebzig Stunden liegt fast immer darin, wie tief sich der Angreifer einrichten konnte und wie alt die letzte saubere Kopie ist. Das Minimum ist keine Marketingzahl: Vollständige Kopie, Ursachensuche in den Protokolldateien, Bereinigung und Kontrolle passen selten in weniger Zeit.

Der Ablauf ist derselbe wie oben, nur ohne Ihr Wochenende. Bevor wir irgendetwas anfassen, nehmen wir eine vollständige Datei- und Datenbankkopie, damit sich der Vorfall später überhaupt untersuchen lässt, und erst dann wird die Website isoliert; anschließend wird sie von Schadsoftware und Backdoors befreit, die Datenbank geprüft, Zugangsdaten und Schlüssel gewechselt, die Einbruchsursache gefunden und geschlossen, der Antrag auf Überprüfung bei Google gestellt und das Monitoring eingerichtet – am Ende erhalten Sie einen schriftlichen Bericht über den Vorfall und die Änderungen. Wenn Ihre Website gerade nicht läuft oder Sie nicht sicher sind, was Sie da sehen, können Sie eine dringende Website-Prüfung anfragen, und wir sagen Ihnen, ob es hier überhaupt etwas zu bezahlen gibt.

In vielen Fällen ist die richtige Antwort allerdings nicht die Wiederherstellung, sondern das, was danach kommt: Hat eine Website zwanzig Plugins angesammelt, bei deren Hälfte sich niemand mehr an den Grund erinnert, liegt das Problem in der Wartung, und gelöst wird es durch WordPress-Entwicklung und -Wartung, nicht durch einen weiteren Bereinigungszyklus in einem halben Jahr. Die billigste Stunde dieser Geschichte ist die vorher aufgewendete: ein ungenutztes Plugin aus wp-content/plugins zu löschen statt es zu deaktivieren und ein Backup, das jemand tatsächlich einmal in einer Testumgebung zurückgespielt hat, kosten zusammen weniger als ein Arbeitstag von uns.