Ist eine weiße WordPress-Seite ein Zeichen für einen Hack?

Nicht automatisch. Häufig sind ein PHP-Fehler, ein inkompatibles Plugin oder Theme, ein fehlgeschlagenes Update, ein Datenbankproblem oder erschöpfte Serverressourcen die Ursache. Ein Hack wird wahrscheinlicher, wenn gleichzeitig fremde Weiterleitungen, unbekannte Konten, unerklärliche Dateiänderungen oder Sicherheitswarnungen auftreten.

Warum sehe nur ich eine normale Website, während Besucher umgeleitet werden?

Manipulierter Code kann Weiterleitungen nur bei bestimmten Geräten, Referrern, Cookies oder Besuchergruppen auslösen. Auch Cache- und DNS-Konfigurationen können unterschiedliche Ansichten verursachen. Vergleichen Sie deshalb mehrere Zugriffswege und prüfen Sie zusätzlich Search Console, Serverkonfiguration, Dateien und Datenbank.

Was bedeutet es, wenn bei Google fremde Seiten unter meiner Domain erscheinen?

Unbekannte Suchtreffer mit Glücksspiel-, Arzneimittel-, Kredit- oder anderen fremden Begriffen sind ein starkes Warnsignal für eingeschleuste Seiten oder SEO-Spam. Die sichtbaren URLs sind häufig nur ein Teil des Vorfalls. Ursache, Persistenz und weitere betroffene Bereiche müssen ebenfalls geprüft werden.

Kann WP Notdienst auch helfen, wenn kein Hack vorliegt?

Ja. Ergibt die Prüfung keinen Sicherheitsvorfall, können wir je nach Ursache auch WordPress-, Plugin-, Theme-, PHP-, Datenbank-, Cache- oder Konfigurationsfehler beheben. Ziel ist, die tatsächliche Ursache zu finden und die Website kontrolliert wieder erreichbar zu machen.

Welche Angaben werden für eine erste Prüfung benötigt?

Für den Erstkontakt genügen die Website-Adresse, eine Kontaktmöglichkeit und eine kurze Beschreibung: seit wann das Problem auftritt, was Besucher sehen und ob zuvor ein Update oder eine Änderung erfolgt ist. Passwörter oder andere Zugangsdaten gehören nicht in das Kontaktformular.

WordPress weiße Seite: Fehler oder Hack erkennen

Bedeutet eine weiße WordPress-Seite, dass die Website gehackt wurde?

Nein. Eine komplett weiße Seite ist zunächst ein Symptom, keine Diagnose. WordPress bezeichnet dieses Verhalten häufig als „White Screen of Death“. Laut offizieller WordPress-Dokumentation können sowohl PHP- als auch Datenbankfehler dazu führen. Typische Auslöser sind ein inkompatibles Plugin, ein fehlerhaftes Theme, ein abgebrochenes Update oder ein Problem mit dem verfügbaren Arbeitsspeicher.

Ein Sicherheitsvorfall ist trotzdem möglich. Manipulierter PHP-Code kann die Ausführung abbrechen, Schadsoftware kann Dateien beschädigen und ein Angreifer kann Serverregeln verändern. Verdächtiger wird die weiße Seite deshalb, wenn mindestens ein weiteres Warnzeichen hinzukommt:

die Störung begann ohne erkennbares Update oder andere geplante Änderung
Besucher berichten zusätzlich von fremden Weiterleitungen oder Pop-ups
im WordPress-Backend existieren unbekannte Administratoren
der Hoster, ein Browser oder die Google Search Console meldet Schadcode
unter der eigenen Domain erscheinen fremde Suchtreffer oder neue URLs
Dateien, geplante Aufgaben oder Serverregeln wurden unerwartet verändert

Grenze / Limit

Ein einzelnes Symptom beweist weder einen Hack noch einen harmlosen Defekt. Eine belastbare Einschätzung entsteht erst, wenn Zeitpunkt, technische Änderungen, Protokolle, Konten, Dateien, Datenbank und externe Warnungen zusammenpassen.

Welche WordPress-Symptome sprechen eher für einen Fehler und welche für einen Hack?

Manche Auffälligkeiten haben oft eine technische Ursache, andere sind ohne unbefugte Veränderung schwer zu erklären. Die folgende Einordnung hilft bei der Priorisierung. Sie ersetzt keine Prüfung der konkreten Installation.

Beobachtung	Häufige technische Erklärung	Mögliche Sicherheitsursache	Dringlichkeit
komplett weiße Seite	PHP-Fatal-Error, Plugin- oder Theme-Konflikt, Speicherlimit	beschädigter oder eingeschleuster PHP-Code	hoch, wenn keine geplante Änderung vorausging
„Es gab einen kritischen Fehler“	fehlerhaftes Update, inkompatible Erweiterung	manipulierte Datei oder absichtlich ausgelöster Fehler	mittel bis hoch
Fehler 500 oder 503	Serverkonfiguration, Überlastung, fehlerhafte `.htaccess`	schädliche Regeln, Botlast, ausgeführter Schadcode	hoch bei plötzlichem Auftreten
Datenbankverbindung fehlgeschlagen	falsche Zugangsdaten, Datenbankausfall, volles Hosting	geänderte Konfiguration oder missbrauchte Ressourcen	hoch, weil die Website ausfällt
Weiterleitung auf fremde Seiten	falsch gesetzte URL, DNS-, Cache- oder Redirect-Regel	eingeschleustes JavaScript, manipulierte Serverregel	sehr hoch
fremde Google-Suchergebnisse	alte Testseite oder falsch eingebundener Inhalt	SEO-Spam, URL-Injection oder Cloaking	sehr hoch
unbekannter Administrator	vergessener Dienstleister- oder Agenturzugang	übernommenes Konto oder neu angelegter Angreiferzugang	sehr hoch
Website plötzlich extrem langsam	Hostingengpass, defektes Plugin, externe API	Botangriff, Spamgenerierung, Mining oder Malwareprozess	hoch bei zusätzlichen Warnzeichen

Für die Einordnung zählt vor allem, ob eine bekannte Änderung und die technischen Spuren zusammenpassen. Wenn direkt vor dem Ausfall ein Plugin aktualisiert wurde und das Fehlerprotokoll genau dort einen PHP-Fehler zeigt, ist ein technischer Defekt plausibel. Gibt es dagegen keine Änderungshistorie, aber neue Konten und fremde Weiterleitungen, muss von einem möglichen Sicherheitsvorfall ausgegangen werden.

Warum bleibt WordPress nach einem Update weiß oder zeigt einen kritischen Fehler?

Nach einer Änderung liegt häufig ein Kompatibilitäts- oder PHP-Problem vor. Ein Plugin kann eine nicht vorhandene Funktion aufrufen, ein Theme kann mit der eingesetzten PHP-Version kollidieren oder ein Update kann unvollständig geblieben sein. WordPress nennt solche Ursachen ausdrücklich in seiner Übersicht häufiger Fehler.

Sinnvolle erste Fragen sind:

Trat der Fehler unmittelbar nach einem WordPress-, Plugin-, Theme- oder PHP-Update auf?
Ist nur die öffentliche Website betroffen oder auch /wp-admin/?
Gibt es eine WordPress-Mail zum Wiederherstellungsmodus?
Welche Meldung steht zeitgleich im PHP- oder WordPress-Fehlerprotokoll?
Funktioniert eine unveränderte Staging-Kopie oder ein nachweislich sauberes Backup?

WP_DEBUG kann technische Hinweise liefern. Die WordPress-Dokumentation empfiehlt Debug-Werkzeuge jedoch für Entwicklungs- oder Stagingumgebungen und nicht als dauerhaft sichtbare Ausgabe auf der Live-Website. Fehlermeldungen können interne Pfade oder andere Details offenlegen. Auf einer produktiven Seite sollten sie protokolliert, aber nicht Besuchern angezeigt werden.

Ein Fehlerprotokoll erklärt nicht automatisch die Ursache

Ein PHP-Fehler benennt die Stelle, an der die Ausführung abbricht. Er erklärt nicht automatisch, warum eine Datei verändert wurde. Bei ungeklärten Dateiänderungen muss zusätzlich geprüft werden, ob der Fehler Folge eines Einbruchs ist.

Was bedeutet eine unerwartete Weiterleitung auf Werbung, Glücksspiel oder fremde Shops?

Eine nicht eingerichtete Weiterleitung auf eine fremde Domain ist ein starkes Hack-Indiz. Angreifer platzieren dafür häufig JavaScript, verändern .htaccess- oder Serverregeln, manipulieren die Datenbank oder laden Code über ein kompromittiertes Plugin nach.

Tückisch ist, dass nicht jede Person dieselbe Weiterleitung sieht. Der Schadcode kann nur reagieren, wenn jemand:

über Google oder eine Werbeanzeige kommt,
ein Smartphone statt eines Desktoprechners verwendet,
nicht im WordPress-Backend angemeldet ist,
eine bestimmte IP-Adresse oder Sprache hat,
die Seite zum ersten Mal besucht.

Google weist darauf hin, dass kompromittierte Websites Inhalte durch Cloaking vor ihren Eigentümern verbergen können. Eine normale Ansicht im eigenen Browser widerlegt den Bericht eines Kunden daher nicht. Zugleich gibt es harmlose Alternativen: eine falsch konfigurierte Domainweiterleitung, alte Cache-Regeln, ein fehlerhaftes Mehrsprachen-Plugin oder geänderte DNS-Einträge. Genau deshalb sollte die Diagnose mehrere Geräte, Referrer, Serverantworten und Konfigurationsebenen vergleichen.

Warum zeigt Google fremde Texte oder unbekannte Seiten unter der eigenen Domain?

Unbekannte Suchtreffer sind oft ein Hinweis auf SEO-Spam oder eingeschleuste URLs. Typische Beispiele enthalten Begriffe zu Arzneimitteln, Krediten, Glücksspiel, Fälschungen oder Inhalten, die nichts mit dem Unternehmen zu tun haben. Die eigentliche Website kann dabei für den Betreiber weiterhin normal aussehen.

Google beschreibt mehrere Varianten:

eingeschleuste Texte und Links in vorhandenen Seiten,
neu erzeugte Spam-URLs,
andere Inhalte für Suchmaschinen als für normale Besucher,
Weiterleitungen, die nur nach einem Klick aus der Suche aktiv werden.

Eine Suche nach site:ihre-domain.de kann unbekannte Treffer sichtbar machen. Sie liefert nur Hinweise und keine vollständige Liste aller indexierten oder manipulierten URLs. Maßgeblich ist außerdem der Bereich Sicherheitsprobleme in der Google Search Console. Dort gezeigte Beispiel-URLs sind laut Google nur eine Auswahl. Werden drei betroffene Seiten genannt, bedeutet das nicht, dass nur drei Seiten manipuliert wurden.

Das bloße Löschen der sichtbaren Spam-Seiten reicht deshalb nicht. Der Zugang, über den sie erzeugt wurden, und vorhandene Persistenz müssen ebenfalls gefunden werden. Erst danach ist eine Überprüfung durch Google sinnvoll.

Wie ernst ist eine rote Browserwarnung oder die Meldung „Diese Website könnte gehackt worden sein“?

Eine Browser- oder Search-Console-Warnung erfordert eine sofortige Prüfung. Google unterscheidet unter anderem gehackte Inhalte, Schadsoftware, schädliche Downloads und Social Engineering. Solche Seiten können mit einem Warnhinweis in der Suche oder einer vorgeschalteten Browserseite erscheinen.

Öffnen Sie gemeldete Malware-Seiten nicht wiederholt auf normalen Arbeitsgeräten. Sichern Sie die Warnung, die betroffene URL und den Zeitpunkt. Prüfen Sie die Search Console und informieren Sie Personen, die Website, Hosting oder Shop betreuen.

Nach der Bereinigung kann die Warnung sichtbar bleiben, bis Google die Website erneut geprüft und den Status aktualisiert hat. Fordern Sie die Überprüfung erst an, wenn alle bekannten Ursachen und betroffenen Bereiche bereinigt wurden.

Sind unbekannte Administratoren oder Passwort-E-Mails ein Beweis?

Ein unbekannter Administrator ist ein konkreter unbefugter Zugang, bis seine Herkunft geklärt ist. Manchmal gehört das Konto zu einer früheren Agentur, einem Hoster oder einem Wartungsdienst. Ist es niemandem zuzuordnen, muss geprüft werden, wann und durch wen es angelegt wurde, welche Aktionen erfolgt sind und ob weitere Zugänge bestehen.

Auch unerwartete E-Mails über Passwortänderungen, neue Anwendungspasswörter oder geänderte E-Mail-Adressen sind ernst zu nehmen. Das Löschen des sichtbaren Kontos beendet den Vorfall nicht zwingend. Ein Angreifer kann zusätzlich:

weitere Benutzer oder Anwendungspasswörter angelegt haben,
vorhandene Administratorkonten übernommen haben,
Code in Plugins, Themes oder Uploads hinterlassen haben,
geplante Aufgaben für eine spätere Rückkehr verwenden,
Hosting-, Datenbank-, E-Mail- oder Domainzugänge kennen.

Der Beitrag zu unbekannten Administratoren und Anwendungspasswörtern erklärt die einzelnen Prüfstellen ausführlicher.

Bedeutet eine langsame oder nicht erreichbare WordPress-Website einen Angriff?

Nein, aber ein Angriff gehört zu den möglichen Ursachen. Häufiger sind ausgelastetes Hosting, langsame Datenbankabfragen, ein defekter Cache, eine nicht erreichbare externe Schnittstelle, DNS-Probleme oder eine fehlerhafte Erweiterung. Google nennt bei nicht erreichbaren URLs unter anderem Serverüberlastung, Zeitüberschreitungen, DNS-Fehler und abgelehnte Verbindungen.

Ein Sicherheitsbezug wird wahrscheinlicher, wenn die Auslastung ohne normalen Besucheranstieg hochgeht, viele auffällige Requests eintreffen, unbekannte PHP-Prozesse laufen oder massenhaft Spam-Seiten erzeugt werden. Auch Brute-Force-Versuche und aggressive Bots können eine schwache Hostingumgebung überlasten, ohne dass bereits ein erfolgreicher Einbruch nachgewiesen ist.

Für die Diagnose sind Zeitreihen wichtig: Wann begann die Störung? Welche Requests, Prozesse und Datenbankabfragen liefen zu diesem Zeitpunkt? Was wurde kurz davor geändert? Eine Momentaufnahme nach einem Neustart kann den entscheidenden Hinweis bereits verloren haben.

Was sollten Sie in den ersten Minuten prüfen, ohne Spuren zu zerstören?

Dokumentieren und sichern Sie zuerst, bevor Sie wahllos Plugins löschen oder ein altes Backup einspielen. Das gilt besonders, wenn ein Hack nicht ausgeschlossen ist.

genauen Wortlaut, betroffene URL, Uhrzeit und Bildschirmfoto des Symptoms festhalten
prüfen, ob der Fehler auf mehreren Geräten und Netzen gleich erscheint
letzte geplante Änderungen, Updates und Deployments notieren
Warnungen von Hoster, Browser, Search Console und Sicherheitsdiensten sichern
verfügbare Zugriffs-, Fehler-, PHP- und WordPress-Protokolle aufbewahren
vor Änderungen eine Sicherung des aktuellen Zustands erstellen
im Erstkontakt nur URL und Symptom senden, keine Passwörter

Wenn die Website aktiv Besucher umleitet, Schadsoftware verteilt oder Zugangsdaten abfragt, kann eine vorübergehende Sperrung notwendig sein. Die Entscheidung sollte die konkrete Gefährdung, Beweissicherung und geschäftliche Auswirkung berücksichtigen. Unsere Sofortmaßnahmen für die erste Stunde beschreiben die Reihenfolge ausführlicher.

Wie lässt sich zuverlässig unterscheiden, ob ein Hack oder ein normaler Defekt vorliegt?

Eine saubere Diagnose prüft beide Hypothesen parallel. Nur nach Schadcode zu suchen übersieht Konfigurations- und Betriebsfehler. Nur den sichtbaren PHP-Fehler zu reparieren übersieht möglicherweise den Grund, warum die Datei beschädigt wurde.

Eine sinnvolle Prüfung umfasst je nach Zugriff:

Erreichbarkeit, HTTP-Status, DNS, TLS und Weiterleitungskette
zeitliche Einordnung von Updates, Änderungen und ersten Symptomen
PHP-, Webserver-, Zugriffs- und WordPress-Protokolle
WordPress-Core, Plugins und Themes im Vergleich mit vertrauenswürdigen Quellen
Benutzer, Rollen, Sitzungen und Anwendungspasswörter
Datenbankinhalte, Optionen, geplante Aufgaben und Serverregeln
Search Console, Hosterwarnungen und auffällige indexierte URLs
weitere Websites und Konten im selben Hostingzugang

Ein Malware-Scanner ist dabei ein Werkzeug, aber keine vollständige Diagnose. Er kann bekannte Muster melden oder Dateien übersehen. Mehr dazu steht im Vergleich Malware-Scan versus forensische Untersuchung.

Können wir auch helfen, wenn die Website nicht gehackt wurde?

Ja. Die erste Aufgabe ist nicht, einen Hack zu behaupten, sondern die tatsächliche Ursache zu finden. Wenn sich kein Sicherheitsvorfall bestätigt, können wir je nach Befund auch normale WordPress-Probleme beheben. Dazu gehören beispielsweise Plugin- und Theme-Konflikte, PHP-Fehler, fehlgeschlagene Updates, Cacheprobleme, Datenbankfehler sowie fehlerhafte Weiterleitungs- oder WordPress-Konfigurationen.

Das Ziel ist in beiden Fällen dasselbe: Die Website soll möglichst schnell und ohne übersehene Folgeschäden wieder erreichbar sein. Bei einem technischen Fehler reparieren wir die Störung. Bei einem bestätigten Hack folgt eine vollständige WordPress-Bereinigung, bei der wir zusätzlich Umfang, Zugangsweg und verbleibende Persistenz prüfen.

Ist ein Shop betroffen, müssen zusätzlich Warenkorb, Checkout, Zahlungsablauf, Bestellhinweise und geplante Aufgaben berücksichtigt werden. Die Shop-Notfallhilfe erklärt, welche Sicherheitsvorfälle und geschäftskritischen Shopausfälle wir übernehmen und wann ein separates Angebot erforderlich ist.

Wenn Sie nicht einordnen können, was hinter der weißen Seite, der Weiterleitung oder der Warnung steckt, senden Sie uns über die kostenlose Ersteinschätzung die Website-Adresse, den Zeitpunkt des ersten Auftretens und eine kurze Beschreibung. Wir ordnen ein, ob die Hinweise eher für einen technischen Defekt oder einen Sicherheitsvorfall sprechen und welcher nächste Schritt sinnvoll ist. Für eine belastbare Bestätigung können anschließend technische Zugriffe und Protokolle erforderlich sein. Zugangsdaten gehören nicht in das Formular. Für allgemeine WordPress-Fehler können Sie uns ebenfalls direkt über die Kontaktseite erreichen.

WordPress zeigt nur eine weiße Seite: Fehler oder Hack?