Was Sie am eigenen Rechner sehen, sehen Ihre Besucher nicht unbedingt
Eingeschleuster Code kann Besucher auf fremde Seiten schicken, aber nur unter bestimmten Bedingungen: vom Smartphone, aus der Google-Suche oder ohne Anmeldung. Wer als Administrator am Desktop nachsieht, bekommt dann die normale Seite.
Ziehen Sie zuerst eine Kopie. Dann stellen Sie die Bedingungen nach und suchen den Code in Dateien und Datenbank, nicht nur in einem Plugin.
Warum leitet Ihre Website auf fremde Seiten weiter, aber nicht bei Ihnen?
Eine Weiterleitung nach einem WordPress-Hack kann an Bedingungen hängen. Der eingeschleuste Code prüft dann bei jedem Aufruf, welches Gerät ein Besucher nutzt, ob er aus der Google-Suche kommt oder angemeldet ist, und schickt nur bestimmte Besucher auf fremde Seiten. Wenn Sie als angemeldeter Administrator am Desktop nachsehen, erfüllen Sie diese Bedingungen womöglich nicht.
Google zählt solche bedingten Weiterleitungen in seinen Spam-Richtlinien zu den heimlichen Weiterleitungen („sneaky redirects“), etwa wenn Desktop-Besucher eine normale Seite sehen und Smartphone-Nutzer auf einer Spam-Domain landen (Stand Oktober 2026). Der Code erkennt das Gerät an der Kennung des Browsers, dem User-Agent, und die Herkunft am Referrer, der im Header „Referer“ heißt. Laut Googles Hilfe für gehackte Websites zielen Hacker oft nur auf Besucher mit bestimmtem User-Agent oder Referrer.
Dasselbe Prinzip steckt hinter eingeschleusten Inhalten, die nur Google sieht:
„Eine gehackte Seite kann im eigenen Browser völlig normal aussehen, während Google warnt: Der Schadcode zeigt die manipulierten Inhalte nur dem Googlebot oder nur Besuchern vom Handy.“
— Sascha Fix
Bei einer bundesweiten passiven Prüfung von Firmen-Websites habe ich jede Startseite einmal mit der Kennung eines gewöhnlichen Browsers und zweimal mit der des Googlebots abgerufen, davon einmal mit Google als Herkunft. Im dritten Quartal 2026 fand der Browser-Abruf bei 439 von 814 Messungen an WordPress-Startseiten mit bestätigter Fremdeinwirkung (54 %) keinen der gesuchten Spam-Begriffe, während der Googlebot eine deutlich andere Seite bekam. Gezählt habe ich Messungen, nicht Websites. Die Prüfung unterscheidet nicht, ob die andere Fassung eine Weiterleitung oder eingeschleuster Text war, und Smartphones oder einen gewöhnlichen Browser mit Google als Herkunft hat sie nicht nachgestellt.
Für mich heißt das: Wenn Sie am eigenen Rechner nichts Fremdes finden, ist das keine Entwarnung. Sie haben dann nur die eine Bedingung geprüft, unter der sich der Schadcode in mehr als der Hälfte dieser WordPress-Messungen nicht verraten hat. Stellen Sie deshalb jede Bedingung einzeln nach, etwa mit dem Kommandozeilenprogramm curl:
| Bedingung | Woran der Code sie erkennen kann | So stellen Sie sie nach |
|---|---|---|
| Smartphone | Kennung des Browsers (User-Agent) | curl mit Smartphone-Kennung |
| Herkunft aus der Google-Suche | Referrer | curl mit Google als Herkunft |
| Besucher ist Google | Kennung des Googlebots, Adresse, von der Google abruft | URL-Prüftool der Google Search Console |
| nicht angemeldet | kein Anmelde-Cookie wordpress_logged_in_… |
jeder Abruf ohne Ihr Anmelde-Cookie, etwa der curl-Test |
Meldet der Browser dagegen, die Seite habe Sie zu oft weitergeleitet, hängt er auf Ihrer eigenen Domain in einer Schleife. Meist ist das ein Konfigurationsfehler auf dem Server, den der Beitrag zu Redirect-Schleifen nach einem Website-Umzug behandelt.
Wo sitzt der Code, der Ihre Besucher umleitet?
Geht die Weiterleitung von Ihrer WordPress-Website aus, kann der Code an mehreren Stellen sitzen: in der .htaccess, in Theme und Plugins, in Must-Use-Plugins (MU-Plugins), in der Datenbank oder außerhalb des WordPress-Verzeichnisses. Leitet der Server weiter, sehen Sie einen Statuscode, der mit 3 beginnt. Leitet erst der Browser weiter, steckt JavaScript oder ein Meta-Refresh im Quelltext.
Laut MDN Web Docs antwortet der Server dann mit einem Statuscode des Hypertext Transfer Protocol (HTTP) wie 301 oder 302 und nennt das Ziel in der Zeile Location. Eine Weiterleitung per JavaScript wirkt dagegen nur in Programmen, die JavaScript ausführen.
| Fundort | Woran Sie ihn erkennen | Womit Sie prüfen |
|---|---|---|
.htaccess, auch in Unterordnern |
RewriteCond auf HTTP_USER_AGENT, HTTP_REFERER oder HTTP_COOKIE vor einer Regel auf eine fremde Domain |
Vergleich mit dem WordPress-Standardblock |
| Kerndateien | Abweichung von den Originalen, fremde Dateien im Hauptverzeichnis | wp core verify-checksums --include-root |
| Plugins und Theme | verschleierter Code wie eval(base64_decode(…)), nachgeladenes Skript von fremder Domain |
Prüfsummen der Plugins, Theme gegen eine frische Kopie |
MU-Plugins in wp-content/mu-plugins |
Datei ohne erkennbaren Zweck, Lader für Dateien in Unterordnern | wp plugin list --status=must-use |
| Datenbank | <script oder fremde Domain in Beiträgen und Plugin-Einstellungen, fremde Domain in home oder siteurl |
wp db search, wp option get, phpMyAdmin |
| außerhalb von WordPress | Dateien oberhalb des WordPress-Verzeichnisses, weitere befallene Websites im selben Paket | Dateimanager oder SFTP |
Im Jahr 2026 habe ich in zwei Fällen aus meiner Arbeit Weiterleitungs-Code dokumentiert. Er lag an zwei verschiedenen Stellen: einmal als JavaScript-Weiterleitung in einer gespeicherten Plugin-Einstellung in der Datenbank, einmal in einem verschleierten Lader eine Verzeichnisebene über der WordPress-Installation, also außerhalb von WordPress. Zwei Fälle sind wenig; sie zeigen, wo ich nachsehe, nicht, wie häufig welcher Fundort ist. Eine Suche nur in den Dateien von Theme und Plugins hätte aber in keinem der beiden Fälle die Stelle erreicht. Suchen Sie deshalb auch in der Datenbank und oberhalb des WordPress-Verzeichnisses.
Wie finden Sie den Weiterleitungs-Code Schritt für Schritt?
Suchen Sie den Weiterleitungs-Code in sechs Schritten: Kopie sichern, Weiterleitung nachstellen, .htaccess prüfen, Kern- und Plugin-Dateien abgleichen, Datenbank und MU-Plugins durchsuchen und unter denselben Bedingungen gegentesten. Die Befehle der Schritte 2 bis 5 lesen nur, und jede Stelle lässt sich auch ohne Kommandozeile über SFTP und phpMyAdmin prüfen.
Die Befehle (Stand Oktober 2026) brauchen die Kommandozeile Ihres Servers, etwa per Secure Shell (SSH), und das WordPress Command Line Interface (WP-CLI); Sie führen sie im Verzeichnis Ihrer WordPress-Installation aus. Mit --skip-plugins --skip-themes lädt WP-CLI die befallenen Plugins und Themes nicht. MU-Plugins lädt es laut WP-CLI-Referenz trotzdem, auch die eines Angreifers.
Befallenen Zustand sichern
Sichern Sie alle Dateien des Hosting-Kontos per SFTP, auch die Ordner oberhalb von WordPress, und exportieren Sie die Datenbank:
wp db export ~/kopie-vor-bereinigung.sql --skip-plugins --skip-themesIst der Zielordner aus dem Web erreichbar, laden Sie die Datei herunter und löschen sie danach vom Server. So gibt es einen Weg zurück, und der befallene Zustand bleibt für die Ursachensuche erhalten.
Weiterleitung nachstellen
Setzen Sie statt
example.comIhre Adresse ein:HANDY='Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36' curl -s -o /dev/null -D - -A "$HANDY" -e "https://www.google.com/" https://example.com/ curl -s -o /dev/null -D - https://example.com/Der erste Abruf kommt als Smartphone (
-A) aus der Google-Suche (-e), der zweite mit der Standardkennung voncurl;-D -zeigt den Kopf der Antwort. Die Smartphone-Kennung ist der Anfang der Kennung von Googles Smartphone-Crawler, „W.X.Y.Z“ steht dort für eine Versionsnummer. Zeigt nur der erste Abruf einen Statuscode mit 3 und eineLocationmit fremder Domain, hängt die Weiterleitung an einer Bedingung; ohne-Lfolgtcurlihr nicht. Eine Weiterleitung per JavaScript steht nur im Quelltext. Den speichern Sie mit-o seite.htmlstatt-o /dev/nullund suchen darin nach<scriptund fremden Adressen.Die .htaccess prüfen
Öffnen Sie die
.htaccessim Hauptverzeichnis und in jedem Unterordner und vergleichen Sie sie mit dem Standardblock aus der WordPress-Dokumentation, der zwischen# BEGIN WordPressund# END WordPresssteht. Verdächtig sind Regeln mit einer fremden Domain als Ziel. Wenn Sie die Permalinks speichern, ersetzt WordPress nur diesen Block; fremde Regeln davor oder danach bleiben stehen. Der Beitrag zum 500-Fehler nach einer .htaccess-Änderung zeigt, wie Sie die Datei neu anlegen lassen; tun Sie das erst, wenn Sie wissen, was die Datei zurückschreiben könnte.Kern- und Plugin-Dateien abgleichen
wp core verify-checksums --include-root wp plugin verify-checksums --all --skip-plugins --skip-themesDer erste Befehl vergleicht die Kerndateien mit den Prüfsummen von WordPress.org, ohne WordPress zu laden, und meldet mit
--include-rootauch fremde Dateien im Hauptverzeichnis. Der zweite prüft alle Plugins. Für Themes hat WP-CLI keine solche Prüfung. Dort vergleichen Sie die Dateien mit einer frischen Kopie vom Hersteller und suchen nach verschleiertem Code; Google nennt dafüreval,base64_decodeundunescape.Datenbank und MU-Plugins durchsuchen
wp option get home --skip-plugins --skip-themes wp option get siteurl --skip-plugins --skip-themes wp db search '<script' --all-tables --skip-plugins --skip-themes wp db search 'example.net' --all-tables --skip-plugins --skip-themes wp plugin list --status=must-use --skip-plugins --skip-themeshomeundsiteurlsollten Ihre eigene Adresse zeigen.wp db searchdurchsucht mit--all-tablesalle Tabellen; stattexample.netsetzen Sie die fremde Domain aus Schritt 2 ein. Verdächtig ist jedes Skript, das Sie nicht selbst eingefügt haben, und jedes MU-Plugin, das Sie keinem Zweck zuordnen können.Gegentest unter denselben Bedingungen
Entfernen Sie Funde erst, wenn Sie auch nach dem gesucht haben, was sie zurückschreiben kann; darum geht es im nächsten Abschnitt. Der Ratgeber Malware erkennen und entfernen beschreibt, wie Sie eine gehackte Website im Ganzen bereinigen. Danach wiederholen Sie beide
curl-Abrufe, prüfen den Quelltext und sehen im URL-Prüftool nach, was Google bekommt.
Warum kommt die Weiterleitung nach dem Löschen zurück?
Die Weiterleitung kommt zurück, wenn neben ihr ein Mechanismus liegt, der sie wiederherstellt, oder wenn der Angreifer noch einen Zugang hat: ein eigenes Administratorkonto, eine Hintertür oder erbeutete Zugangsdaten. Wenn Sie nur die auffällige Zeile löschen, entfernen Sie den sichtbaren Schadcode, aber keinen dieser Wege zurück.
In beiden Fällen aus dem Jahr 2026, in denen ich Weiterleitungs-Code dokumentiert habe, gab es daneben einen Mechanismus, der Entferntes von selbst zurückholte: einmal einen Trigger in der Datenbank, der ein gelöschtes Administratorkonto neu anlegte, einmal einen Lader, der bei jedem Seitenaufruf seine manipulierte .htaccess wiederherstellte. Zwei Fälle zeigen, warum das Löschen der sichtbaren Zeile nicht reicht, aber nicht, wie oft so ein Mechanismus vorkommt. Für mich folgt daraus die Reihenfolge: Bevor Sie die auffällige Zeile löschen, suchen Sie nach dem, was sie zurückschreibt.
Drei Befehle zeigen, wo so etwas sitzen kann:
wp db query "SHOW TRIGGERS;" --skip-plugins --skip-themes
wp user list --role=administrator --skip-plugins --skip-themes
wp cron event list --skip-plugins --skip-themes
Die erste Zeile listet die Trigger der Datenbank, bei MySQL 8.4 laut MySQL-Handbuch aber nur für Tabellen, auf die Ihr Datenbank-Benutzer das Recht TRIGGER hat; eine leere Ausgabe ist also keine Entwarnung. Die zweite listet die Administratoren mit Registrierungsdatum, die dritte die geplanten Aufgaben von WordPress. Notieren Sie jedes fremde Konto, bevor Sie es löschen.
Und wenn Sie WordPress einfach neu installieren?
„Eine Neuinstallation ersetzt nur die WordPress-Kerndateien – Hintertüren in Plugins, Uploads oder der Datenbank bleiben.“
— Sascha Fix
Was prüfen Sie, wenn die Weiterleitung weg ist?
Ist die Weiterleitung weg, prüfen Sie drei Dinge: ob sie unter denselben Bedingungen ausbleibt, ob Google Ihre Seite noch als gefährlich markiert und ob die Zugänge sauber sind. Die WordPress-Dokumentation rät, die Passwörter nach der Bereinigung noch einmal zu ändern, auch wenn Sie das beim Entdecken des Hacks schon getan haben.
Wiederholen Sie den Gegentest mit curl nach einiger Zeit, denn geplante Aufgaben laufen erst zu ihrem nächsten Termin. Kostenlose Malware-Scanner gibt es für die Prüfung von außen und als Plugin auf dem Server. Ruft ein Scanner Ihre Seite von außen ohne Smartphone-Kennung und ohne Google als Herkunft ab, erfüllt er die Bedingungen einer solchen Weiterleitung nicht.
Die Google Search Console zeigt im Bericht „Sicherheitsprobleme“, ob Google Ihre Seite markiert hat. Dort fordern Sie nach der Bereinigung eine Überprüfung an, die laut Google einige Tage oder mehrere Wochen dauern kann (Stand Oktober 2026). Den Ablauf beschreibt der Beitrag Google-Blacklist nach einem Hack entfernen; der Ratgeber zur WordPress-Sicherheit ordnet ein, welche Maßnahmen danach das Einfallstor schließen.
Wann sollten Sie die Bereinigung abgeben?
Sie können selbst suchen, wenn Sie eine Kopie des befallenen Zustands haben, an Dateien und Datenbank herankommen und die Weiterleitung nachstellen können. Geben Sie die Bereinigung besser ab, wenn die Weiterleitung nach dem Löschen zurückkommt, das Einfallstor unbekannt bleibt, personenbezogene Daten auf der Website liegen oder mehrere Websites im Hosting-Paket befallen sind.
| Bedingung | Selbst suchen | Abgeben |
|---|---|---|
| Kopie | befallener Zustand gesichert | fehlt oder entstand erst nach ersten Änderungen |
| Zugang | WP-CLI oder SFTP und Datenbank | nur das WordPress-Backend |
| Weiterleitung | nachstellbar, Fundort gefunden | nur aus Berichten bekannt |
| nach dem Löschen | bleibt weg | kommt zurück |
| Einfallstor | gefunden und geschlossen | unbekannt |
| Daten | keine personenbezogenen Daten | Kundenkonten, Bestellungen, Formulare |
| Hosting-Paket | nur diese Website | mehrere Websites oder Code außerhalb von WordPress |
Mein Vorgehen beschreibe ich auf der Seite zur Hilfe bei gehackten WordPress-Seiten; die Erstanalyse ist kostenlos, und den Festpreis kennen Sie, bevor ich anfange. Für Websites ohne WordPress ist meine Website-Reparatur gedacht.
Häufige Fragen zur Weiterleitung nach einem WordPress-Hack
Warum sehe ich die Weiterleitung nicht, meine Kunden aber schon?
Der eingeschleuste Code muss nicht jeden Besucher gleich behandeln. Er kann prüfen, ob jemand mit dem Smartphone kommt, aus der Google-Suche oder ohne Anmeldung, und nur dann weiterleiten. Sie selbst sind am Desktop womöglich angemeldet und rufen die Adresse direkt auf. Stellen Sie die Bedingungen deshalb mit curl nach: einmal mit Smartphone-Kennung und Google als Herkunft, einmal ohne beides.
Liegt die Weiterleitung an meinem Gerät oder an meiner Website?
Werden Sie beim Surfen auch auf anderen Websites umgeleitet, kann laut Chrome-Hilfe unerwünschte Software oder Malware auf Ihrem Rechner der Grund sein. Wenn es nur Ihre Website betrifft und auch Besucher davon berichten, spricht das für Code auf dem Server. Zeigt der curl-Test mit Smartphone-Kennung und Google als Herkunft eine Weiterleitung, geht sie von Ihrer Website aus.
Reicht es, die Weiterleitungs-Zeile in der .htaccess zu löschen?
Nur, wenn nichts sie zurückschreibt und der Code an keiner zweiten Stelle sitzt. In beiden Fällen aus meiner Arbeit 2026, in denen ich Weiterleitungs-Code dokumentiert habe, gab es einen Mechanismus, der Entferntes wiederherstellte – einmal einen Lader, der die .htaccess bei jedem Aufruf zurückschrieb. Zwei Fälle ergeben keine Häufigkeit. Prüfen Sie vor dem Löschen Trigger, Administratoren und geplante Aufgaben, und ziehen Sie vorher eine Kopie.
Hilft es, WordPress neu zu installieren?
Eine Neuinstallation ersetzt die Kerndateien von WordPress. Hintertüren in Plugins, Uploads oder der Datenbank bleiben dabei liegen, ebenso Code außerhalb des WordPress-Verzeichnisses. Die WordPress-Dokumentation rät außerdem davon ab, dafür die Funktion im Backend zu nutzen, weil solche Installer oft nur vorhandene Dateien überschreiben und Hacks oft neue anlegen. Prüfen Sie die Kerndateien stattdessen mit wp core verify-checksums.
Reicht es, meine Website im privaten Browserfenster zu öffnen?
Es deckt nur eine Bedingung ab. Ein privates Fenster startet laut Chrome-Hilfe eine eigene Sitzung, in der Sie nicht angemeldet sind; Smartphone und Herkunft aus der Google-Suche stellt es nicht nach. Außerdem öffnet es die Seite im Browser, wovon Google bei befallenen Seiten abrät, weil Schadcode über Schwachstellen im Browser Ihren Rechner treffen kann. Der curl-Test dagegen ruft das fremde Ziel nicht auf.
Muss ich die Sicherheitsschlüssel in der wp-config.php ändern?
Ja, aber erst nach der Kopie, denn dabei ändert sich die wp-config.php. Neue Sicherheitsschlüssel melden laut WordPress-Dokumentation alle ab, die noch angemeldet sind, also auch einen Angreifer mit gültiger Anmeldung. Erneuern Sie die Schlüssel zusammen mit den Passwörtern, und zwar von einem Gerät, das sicher nicht befallen ist; sonst gehen auch die neuen Zugangsdaten an den Angreifer.
Wie lange dauert es, bis Google die Warnung entfernt?
Das entscheidet Google nach einer Überprüfung, die Sie in der Search Console im Bericht „Sicherheitsprobleme“ beantragen, wenn die Website bereinigt ist. Laut Google kann sie einige Tage oder mehrere Wochen dauern (Stand Oktober 2026). Beantragen Sie die Überprüfung erst, wenn der Gegentest unter allen Bedingungen sauber ist; eine Weiterleitung, die nur Smartphones trifft, sehen Sie am Desktop sonst womöglich nicht.
Ihre WordPress-Seite schickt Besucher auf fremde Seiten?
Ich sichere zuerst den befallenen Zustand, bereinige Dateien, Datenbank und Zugänge und entferne die gefundene Malware und die erkennbaren Hintertüren. Die Erstanalyse ist kostenlos.