WordPress weißer Bildschirm nach Update: Plugin-Konflikt ohne Backend beheben

Deine WordPress-Seite zeigt einen weißen Bildschirm, vielleicht auch einen 500er. Ins Backend kommst du nicht mehr. Du weißt, dass du kurz vorher etwas gemacht hast, ein Update oder ein neues Plugin, aber welches davon die Seite umgeworfen hat, ist unklar.

Das ist mit hoher Wahrscheinlichkeit ein Plugin-Konflikt, das häufigste technische Problem, das mir auf WordPress-Installationen begegnet. Es gibt einen festen Weg, ihn zu finden, und der funktioniert auch dann, wenn du nicht mehr ins Backend kommst. Ich gehe ihn hier einmal komplett durch, von der ersten Einordnung über FTP und Datenbank bis zu der Frage, wie du das Problem dauerhaft loswirst.

Warum ein Plugin die ganze Seite mitnehmen kann

WordPress ist modular gebaut. Jedes Plugin hängt sich über Hooks in den Kern ein, die beiden Grundmechanismen heißen add_action() und add_filter(). Solange sich alle Plugins an die Regeln halten, geht das gut. Wenn zwei Plugins dieselbe Funktion definieren, wirft PHP einen Fatal Error und die Seite ist sofort tot. Wenn Plugin A ein Ergebnis verändert, auf dem Plugin B aufbaut, bekommst du undefiniertes Verhalten, mal geht es, mal nicht. Laden zwei Plugins unterschiedliche Versionen derselben JavaScript-Bibliothek, senden Formulare nicht mehr ab oder der Checkout bricht ab. Und wenn sich zwei Stylesheets in die Quere kommen, sieht das Layout nach einem Update plötzlich zerschossen aus, ohne dass jemand am Design war.

Ein Punkt ist dabei wichtig, weil er viele auf die falsche Fährte führt: Der Auslöser ist nicht immer die Ursache. Du aktualisierst Plugin C, aber der eigentliche Konflikt besteht zwischen A und B, die seit dem letzten Kern-Update auf Kollisionskurs lagen. Plugin C war nur der letzte Tropfen.

Das Symptom einordnen

Bevor du irgendetwas deaktivierst, lohnt ein Blick darauf, was du genau siehst. Das sagt dir schon, wo du suchen musst.

Ein komplett weißer Bildschirm ist fast immer ein fataler PHP-Fehler. Das Backend ist dann oft trotzdem noch erreichbar, also ruf /wp-admin direkt auf, bevor du zum FTP-Zugang greifst.

Ein 500 Internal Server Error kann ein PHP-Fehler sein, ein Speicherlimit oder eine beschädigte .htaccess. Schau zuerst in das PHP-Fehlerprotokoll deines Servers, dort steht in den meisten Fällen die verursachende Datei samt Zeile.

Wenn das Backend nicht erreichbar ist, brauchst du FTP- oder Datenbankzugriff. Das ist der unangenehmste Fall, aber kein Grund zur Panik, der Weg dahin steht weiter unten.

Wenn Formulare nicht abschicken, der Checkout abbricht oder ein Slider nicht lädt, ist es ein JavaScript-Fehler. Öffne die Browser-Konsole (F12, Reiter „Console“), bevor du irgendetwas deaktivierst. Dort steht, welches Script den Fehler wirft und aus welchem Plugin es kommt. Das spart dir das komplette Ausschlussverfahren.

Ist nach dem Update nur das Design kaputt, liegt es häufig an einem CSS-Konflikt oder schlicht am Cache. Leere zuerst alle Caches, im Browser, im Caching-Plugin und auf dem Server. Oft ist es damit erledigt.

Zwei Dinge vor dem Debuggen

Seit WordPress 5.2 gibt es den Recovery Mode. Tritt ein fataler PHP-Fehler auf, schickt WordPress automatisch eine Mail mit einem Recovery-Link an die hinterlegte Admin-Adresse. Über den Link kommst du in ein eingeschränktes Backend, in dem das fehlerhafte Plugin bereits markiert ist. Prüfe also dein Postfach, bevor du FTP oder Datenbank anfasst. In vielen Fällen ist das der schnellste Weg zurück.

Und wenn du noch irgendwie an die Datenbank kommst, zieh jetzt einen Dump über phpMyAdmin. Alles, was du ab hier tust, kann den Schaden vergrößern, wenn dabei etwas schiefgeht.

Schritt 1: Das Fehlerprotokoll lesen

Diesen Schritt überspringen die meisten, dabei spart er die meiste Zeit. Ich sehe regelmäßig, wie Leute Plugins auf Verdacht abschalten, während das Fehlerprotokoll den Schuldigen längst beim Namen nennt.

Die meisten Hoster zeigen das PHP-Fehlerprotokoll direkt im Kundenmenü oder in cPanel. Dort steht, in welcher Datei und in welcher Zeile der Fehler passiert, und damit, welches Plugin es ist.

Gibt es kein Protokoll beim Hoster, schalte das eigene Protokoll von WordPress ein. Wie das geht und wie du die Einträge liest, steht Schritt für Schritt im Artikel WordPress debug.log aktivieren und lesen. Für hier reicht: Die Datei /wp-content/debug.log nennt Datei und Zeile des Fehlers, und damit das Plugin.

Schritt 2: Alle Plugins deaktivieren

Je nachdem, wo du noch hinkommst, gibt es drei Wege.

Hast du noch Zugang zum WP-Admin, geh auf Plugins → Installierte Plugins, markiere alle über die Checkbox oben, wähle unter „Massenaktionen“ den Punkt „Deaktivieren“ und klick auf „Übernehmen“. Lädt die Seite danach wieder, war ein Plugin der Auslöser.

Kommst du nicht mehr ins Backend, verbinde dich per SFTP mit dem Server (FileZilla oder ein anderer SFTP-Client) und geh nach /wp-content/. Benenne den Ordner plugins um, zum Beispiel in plugins_disabled. WordPress findet den Ordner nicht mehr und deaktiviert alle Plugins aus Selbstschutz. Lädt die Seite danach wieder, war ein Plugin der Auslöser. Benenne den Ordner sofort wieder in plugins zurück, bevor du mit der Einzeldiagnose anfängst, sonst fehlen dir die Plugins beim Reaktivieren.

Geht auch FTP nicht, bleibt die Datenbank. In phpMyAdmin oder einem Datenbank-Client wie TablePlus:

UPDATE wp_options
SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';

Das setzt die Liste der aktiven Plugins auf leer. Führ das nur direkt über den Datenbank-Client aus, nie über ein WordPress-Plugin, und nur, wenn du weißt, was du tust.

Schritt 3: Läuft die Seite wieder?

Wenn ja, ist bestätigt, dass ein Plugin der Auslöser war. Weiter mit Schritt 4.

Wenn nein, liegt das Problem tiefer, am Theme, an der PHP-Version, an der Datenbank oder an der wp-config.php. Das ist dann kein Plugin-Konflikt mehr, sondern ein anderes Problem. Zum Ausschluss kannst du testweise auf ein Standard-Theme wie Twenty Twenty-Five wechseln. Verschwindet der Fehler damit, liegt es am Theme.

Schritt 4: Den Übeltäter finden

Aktiviere die Plugins jetzt einzeln nacheinander im WP-Admin. Nach jeder Aktivierung die Seite neu laden und schauen, ob der Fehler zurück ist.

Fang dabei nicht irgendwo an. Zuerst kommen die Plugins dran, die du zuletzt installiert oder aktualisiert hast, denn dort sitzt der Auslöser in der Praxis fast immer. Kommt der Fehler zurück, ist das zuletzt aktivierte Plugin entweder selbst das Problem oder es hat einen Konflikt mit einem der bereits aktiven Plugins geweckt.

Schritt 5: Ein Konfliktpaar eingrenzen

Tritt der Fehler nicht auf, wenn das verdächtige Plugin allein aktiv ist, streiten sich zwei Plugins. Lass nur das verdächtige aktiv, alle anderen aus, und schalte die übrigen nacheinander dazu. Sobald der Fehler wieder da ist, hast du das Paar. Mit dieser Information kannst du in den Support-Foren beider Plugins nachsehen, meistens gibt es dort schon einen bekannten Workaround oder einen angekündigten Fix.

Was danach zu tun ist

Du kennst jetzt die Ursache. Drei Möglichkeiten bleiben.

Du kannst das Plugin ersetzen. Für die meisten Aufgaben gibt es mehrere gepflegte Alternativen. Schau bei der Alternative auf das Datum des letzten Updates, die Angabe „Tested up to“ im Plugin-Verzeichnis, die Zahl der aktiven Installationen und darauf, ob im Support-Forum jemand antwortet.

Du kannst auf die alte Version zurück. Mit WP Rollback geht das direkt im Backend. Das ist eine gute Übergangslösung, bis ein Fix da ist, aber kein Dauerzustand, weil alte Versionen keine Sicherheitsupdates mehr bekommen.

Oder du meldest den Konflikt dem Entwickler. Wenn das Plugin aktiv gepflegt wird, lohnt sich ein genauer Bericht mit WordPress-Version, PHP-Version, dem anderen beteiligten Plugin und der exakten Fehlermeldung aus dem Protokoll. Gute Entwickler reagieren darauf, weil ihre Kompatibilitätsbewertung im Verzeichnis daran hängt.

Wie du Plugin-Konflikte seltener bekommst

Ganz vermeiden lassen sie sich nicht. Deutlich seltener werden sie mit vier Gewohnheiten.

Aktualisiere nie alles auf einmal. „Alle aktualisieren“ ist bequem und der Grund für einen guten Teil der Anrufe, die ich bekomme. Einzeln updaten, nach jedem Update kurz die Seite prüfen, besonders bei Plugins, die tief ins System greifen: Page Builder, SEO, Caching, Sicherheit.

Kenne die Plugins mit Verfallsdatum. Ein Plugin, das seit über zwölf Monaten kein Update hatte und nicht als kompatibel mit deiner WordPress-Version markiert ist, ist ein Risiko. Regelmäßig prüfen, bei Bedarf ersetzen.

Teste Updates auf einer Kopie. Die meisten Managed-WordPress-Hoster bieten eine Staging-Umgebung mit einem Klick. Der Aufwand beim Einrichten zahlt sich bei jedem Update-Zyklus aus.

Und mach vor jedem Update-Zyklus ein Backup. Das klingt selbstverständlich, ist es in der Praxis aber nicht.

Wenn du das beherzigst, wirst du Konflikte nicht komplett los, aber du löst sie deutlich schneller. Und falls du an dem Punkt bist, an dem du sagst „ich will mich damit einfach nicht mehr beschäftigen“, genau dafür gibt es PatchBude. Du chillst, ich patche.

Häufige Fragen zu Plugin-Konflikten

Was tun, wenn WordPress nach einem Update weiß bleibt?

Prüfe zuerst deine Admin-Mailadresse auf einen Recovery-Link von WordPress. Ist das Backend noch erreichbar, deaktiviere alle Plugins über Plugins → Installierte Plugins → Alle markieren → Deaktivieren. Wenn nicht, benenne den Ordner /wp-content/plugins/ per FTP in plugins_disabled um. Lädt die Seite danach wieder, war ein Plugin der Auslöser.

Wie finde ich heraus, welches Plugin den Konflikt verursacht?

Schalte das Debug-Logging in der wp-config.php mit define('WP_DEBUG_LOG', true) ein. Die Datei /wp-content/debug.log nennt in den meisten Fällen direkt das Plugin. Sonst hilft nur, die Plugins einzeln nacheinander zu aktivieren und nach jeder Aktivierung die Seite zu prüfen.

Kann ich Plugins ohne WP-Admin deaktivieren?

Ja, auf zwei Wegen. Per FTP den Ordner /wp-content/plugins/ umbenennen, dann deaktiviert WordPress alle Plugins automatisch. Oder per SQL in phpMyAdmin: UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins'. Beide Wege brauchen Server- oder Datenbankzugriff.

Was ist der Unterschied zwischen weißem Bildschirm und 500er?

Beide deuten meist auf einen fatalen PHP-Fehler hin, sie unterscheiden sich in der Ausgabe. Der weiße Bildschirm zeigt gar nichts, weder Text noch Seite. Der 500er ist ein HTTP-Statuscode, den der Server selbst zurückgibt, oft mit einer Fehlerseite des Hosters. In beiden Fällen ist das PHP-Fehlerprotokoll der erste Anlaufpunkt.

Kann ein Plugin-Konflikt erst Wochen nach der Installation auftreten?

Ja. Konflikte entstehen oft nicht beim Installieren, sondern wenn ein späteres Update eine schon vorhandene Unverträglichkeit weckt. Ein Plugin, das seit Monaten läuft, kann durch das Update eines anderen Plugins plötzlich einen Fatal Error auslösen.