Kurz gesagt: Wenn die Website auf fremde Seiten umleitet, steckt die Ursache in einer von sechs Schichten: DNS, CDN oder Proxy, Webserver-Konfiguration, PHP-Code, Datenbank oder eingebundene Skripte. Weil viele Weiterleitungen nur unter Bedingungen greifen, testen Sie gezielt mit verschiedenen Kennungen und Herkunftsseiten. Schützen Sie zuerst die Besucher, sichern Sie Spuren und schließen Sie nach dem Entfernen das Einfallstor.
Wenn Kunden auf Gewinnspielseiten landen
Die Meldung kommt meist von außen. Ein Kunde schreibt, er sei beim Aufruf Ihrer Seite auf einem Gewinnspiel oder einem fragwürdigen Shop gelandet. Sie prüfen es am eigenen Rechner, und alles sieht normal aus. Das ist kein Widerspruch, sondern Absicht: Umleitungen nach einem Hack sind so gebaut, dass Betreiber sie möglichst spät bemerken.
Für Ihr Unternehmen ist das heikel. Besucher verlieren Vertrauen, Suchmaschinen und Browser können Warnungen anzeigen, und auf den Zielseiten warten mitunter Betrug oder Schadsoftware. Eine Weiterleitung ist zudem fast nie das Einzige, was ein Angreifer hinterlässt.
Nach PHP2Shell, den Lücken CVE-2026-109618 und CVE-2026-109619 mit Codeausführung ohne Anmeldung, gehören Weiterleitungen zu den sichtbaren Folgen, die Betreiber ernst nehmen sollten. Sie sind kein spezifischer PHP2Shell-Hinweis, denn bestätigte Indicators of Compromise gibt es nicht. Aber sie zeigen, dass jemand Inhalte Ihrer Website verändern konnte.
Häufig kommen Weiterleitungen nicht allein. Wer Besucher umleitet, legt oft zusätzlich Spam-Seiten für Suchmaschinen an, um noch mehr Verkehr abzugreifen. Zeigt Google bereits einen Hinweis auf eine gehackte Website, beschreibt der Ratgeber Google-Warnung entfernen den Weg zur Überprüfung. Fremde Seiten im Suchindex behandelt der Beitrag SEO-Spam und fremde Seiten im Google-Index.
Warum die Website nur manchmal umleitet
Bedingte Weiterleitungen werten Merkmale der Anfrage aus. Häufig sind es diese:
- Herkunft: Nur wer über ein Suchergebnis kommt, wird umgeleitet. Direkte Aufrufe zeigen die normale Seite.
- Gerät: Nur Mobilgeräte oder bestimmte Browser sind betroffen.
- Wiederholung: Die Umleitung greift einmal pro Besucher, danach setzt sie ein Cookie und schweigt.
- Anmeldung: Wer im CMS angemeldet ist, sieht nie etwas.
- Zeit oder Zufall: Die Umleitung greift nur bei einem Teil der Aufrufe.
Testen Sie deshalb nicht nur am Arbeitsplatz. Mit einer lesenden Abfrage sehen Sie, wie der Server auf unterschiedliche Aufrufe antwortet:
# Normaler Aufruf: Statuscode und Ziel einer möglichen Weiterleitung
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Aufruf wie von einem Mobilgerät, das über eine Suche kommt
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Erscheint nur bei der zweiten Abfrage ein fremdes Ziel, sitzt die Weiterleitung auf dem Server. Bleiben beide unauffällig, kann sie im Browser per JavaScript passieren. Dann hilft ein Blick in den Quelltext der ausgelieferten Seite oder die Netzwerkansicht der Entwicklerwerkzeuge im Browser, am besten in einem privaten Fenster.
Website leitet um: Die sechs Schichten prüfen
Gehen Sie von außen nach innen vor. So vermeiden Sie, stundenlang im Code zu suchen, während die Ursache in einem DNS-Eintrag liegt:
| Schicht | Typische Ursache | Prüfung |
|---|---|---|
| Domain und DNS | geänderter A-Eintrag oder Namensserver | DNS-Einträge mit dem bekannten Soll vergleichen, Zugang zum Registrar prüfen |
| CDN oder Proxy | fremde Weiterleitungs- oder Seitenregel | Regeln im Kundenbereich des Anbieters durchsehen |
| Webserver | Regeln in .htaccess oder Serverkonfiguration |
nach Rewrite- und Redirect-Regeln mit Bedingungen suchen |
| PHP-Code | zusätzlicher Code in Einstiegsdateien, Vorlagen oder Erweiterungen | Kerndateien mit dem Original vergleichen |
| Datenbank | geänderte Adress-Einstellungen, Skripte in Inhalten oder Optionen | gezielt nach fremden Adressen und Skripten suchen |
| Externe Skripte | kompromittierte Drittanbieter-Einbindung | eingebundene Skriptquellen auflisten und bewerten |
Die äußeren Schichten werden gern übersprungen, weil sie nicht auf dem eigenen Server liegen. Gerade deshalb sind sie gefährlich: Wer das Konto beim Registrar oder beim CDN-Anbieter übernommen hat, braucht keinen Zugriff auf den Server. Prüfen Sie dort neben den Regeln auch, wer Zugang hat und ob Zwei-Faktor-Anmeldung aktiv ist.
Für die Webserver-Schicht eignen sich lesende Suchen nach Regeln, die auf Herkunft oder Gerät reagieren:
# Weiterleitungsregeln mit Bedingungen in allen .htaccess-Dateien
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Weiterleitungen in der Serverkonfiguration (Apache und Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Für die PHP-Schicht beschreibt CMS-Kerndateien mit dem Original vergleichen das Vorgehen. Für die Datenbank lohnt der Beitrag Die Datenbank auf eingeschleusten Code prüfen.
Wenn die Ursache außerhalb des Servers liegt
Nicht jede Umleitung bedeutet einen kompromittierten Server. Eingebundene Skripte von Drittanbietern, etwa für Chats, Statistik oder Werbung, werden direkt im Browser der Besucher ausgeführt. Wird ein solcher Anbieter kompromittiert oder läuft eine Domain aus, auf die Ihre Seite noch ein Skript lädt, kann darüber eine Umleitung entstehen, ohne dass auf Ihrem Server eine Datei geändert wurde.
Eine Content Security Policy begrenzt, aus welchen Quellen der Browser Skripte laden darf, und macht solche Fälle sichtbar. Hinweise dazu stehen unter Sicherheits-Header für Websites. Sehr selten liegt die Ursache beim Besucher selbst: Werbe- oder Schadsoftware auf seinem Rechner leitet dann auch auf anderen Websites um.
Die richtige Reihenfolge nach dem Fund
- Besucher schützen: Website in den Wartungsmodus setzen oder die betroffenen Bereiche sperren.
- Spuren sichern: Verdächtige Regeln, Dateien und Datenbankinhalte mit Zeitstempel kopieren, bevor Sie sie entfernen.
- Entfernen: Weiterleitung beseitigen und Kerndateien aus sauberer Quelle ersetzen.
- Einfallstor schließen: PHP auf einen behobenen Stand bringen, CMS und Erweiterungen aktualisieren, alle Worker neu starten, Zugänge erneuern.
- Nachtesten: Mit allen Varianten aus dem zweiten Abschnitt erneut prüfen und Search Console beobachten.
Eine entfernte Weiterleitungsregel ist kein Beweis für eine saubere Website. Wenn die Regel nach Tagen zurückkommt, sitzt irgendwo noch eine Hintertür, die sie neu schreibt.
Wie hilft PHP SOS konkret?
- Wir reproduzieren die Weiterleitung mit verschiedenen Kennungen und Herkunftsseiten und grenzen die Schicht ein.
- Wir sichern Spuren und entfernen Weiterleitungen, Schadcode und Hintertüren in Dateien, Konfiguration und Datenbank.
- Bei akutem Befall übernimmt unsere Notfallhilfe bei gehackten Websites die Eindämmung, bis der Vorfall abgeschlossen und dokumentiert ist.
- Wir prüfen eingebundene Drittanbieter-Skripte und empfehlen eine passende Content Security Policy.
Häufige Fragen
Warum sehe ich die Weiterleitung selbst nicht?
Viele Weiterleitungen greifen nur unter bestimmten Bedingungen: für Besucher aus der Google-Suche, nur auf Mobilgeräten, nur beim ersten Besuch oder nicht für angemeldete Admins. Testen Sie deshalb mit verschiedenen Geräten, ohne Anmeldung und über einen Suchergebnis-Link.
Kann eine Weiterleitung auch ohne Hack entstehen?
Ja. Ein abgelaufenes Plugin, ein kompromittiertes externes Skript, falsche DNS-Einträge oder Schadsoftware auf dem Rechner des Besuchers können ähnliche Effekte haben. Liegt die Ursache auf dem eigenen Rechner, tritt die Umleitung meist auch auf anderen Websites auf.
Wo verstecken Angreifer Weiterleitungen am häufigsten?
Typisch sind Regeln in .htaccess oder der Serverkonfiguration, zusätzlicher Code in Einstiegsdateien der Anwendung, geänderte Adress-Einstellungen in der Datenbank und eingeschleuste JavaScript-Schnipsel in Inhalten oder Vorlagen.
Was sollte ich sofort tun, wenn meine Website umleitet?
Besucher schützen, etwa durch einen Wartungsmodus, und Spuren sichern, bevor Sie etwas löschen. Danach Schicht für Schicht nach der Ursache suchen und das Einfallstor schließen. Eine entfernte Regel ohne geschlossene Lücke kommt meist zurück.