Deine WordPress-Website zeigt einen weißen Bildschirm. Oder einen 500er. Das Backend ist nicht mehr erreichbar. Du weißt, dass du kurz vorher etwas verändert hast – ein Update, ein neues Plugin – aber welches genau das Problem verursacht, ist unklar.
Das ist ein Plugin-Konflikt. Kein seltener Ausnahmefall, sondern das häufigste technische Problem auf WordPress-Installationen. Die gute Nachricht: Es gibt einen klaren, reproduzierbaren Weg zur Lösung – auch dann, wenn du keinen WP-Admin-Zugriff mehr hast.
Dieser Artikel zeigt dir den kompletten Debugging-Prozess: von der Fehlerdiagnose über FTP- und SQL-Zugriff bis zur dauerhaften Lösung. Und falls du irgendwo hängst – kein Problem, das kriegen wir hin.
Was technisch passiert – und warum der Auslöser nicht immer die Ursache ist
WordPress ist modular aufgebaut. Jedes Plugin hängt sich über Hooks in den Core ein – add_action() und add_filter() sind die Grundmechanismen.
Konflikte entstehen wenn:
Namenskollisionen auftreten: Zwei Plugins definieren eine Funktion mit demselben Namen. PHP wirft einen Fatal Error – die Seite ist sofort tot.
Hook-Konflikte entstehen: Plugin A modifiziert ein Ergebnis, auf das Plugin B aufbaut. Das Resultat ist undefiniertes Verhalten – mal funktioniert es, mal nicht.
JavaScript-Konflikte auftreten: Zwei Plugins laden unterschiedliche Versionen derselben Bibliothek. Formulare senden nicht ab, Slider laden nicht, der Checkout bricht ab.
CSS-Kollisionen entstehen: Konkurrierende Stylesheets zerstören das Layout nach einem Update ohne erkennbaren Grund.
Das Wichtigste dabei: Auslöser und Ursache sind nicht immer dasselbe Plugin. Du updatest Plugin C – aber der eigentliche Konflikt besteht zwischen Plugin A und B, die seit dem letzten Core-Update auf Kollisionskurs lagen. Plugin C war nur der letzte Tropfen. Klassiker.
Symptome richtig einordnen
Bevor du anfängst zu debuggen, klassifiziere das Symptom – es gibt dir einen direkten Hinweis darauf, wo du suchen musst.
Weißer Bildschirm (White Screen of Death) Fast immer ein fataler PHP-Fehler. Wichtig: Das WP-Admin ist oft trotzdem noch erreichbar. Versuch /wp-admin direkt aufzurufen, bevor du zum FTP-Zugang greifst.
500 Internal Server Error Kann ein PHP-Fehler, ein Speicherlimit oder eine beschädigte .htaccess sein. Schau zuerst in die PHP-Fehlerlog deines Servers – sie nennt dir in den meisten Fällen direkt die verursachende Datei und Zeile.
WP-Admin nicht erreichbar Der unangenehmste Fall. Du brauchst jetzt FTP- oder Datenbankzugriff. Ruhig bleiben – der Weg dahin ist weiter unten beschrieben.
JavaScript-Fehler im Frontend Formular sendet nicht ab, Checkout bricht ab, Slider lädt nicht. Öffne die Browser-Konsole (F12 → Console) bevor du irgendwas deaktivierst – dort siehst du direkt welches Script den Fehler wirft und aus welchem Plugin es kommt. Das spart dir das komplette Ausschlussverfahren.
Zerstörtes Design nach Update Häufig ein CSS-Konflikt oder ein Caching-Problem. Bevor du debuggst: Cache leeren – Browser-Cache, Plugin-Cache, Server-Cache. Oft reicht das schon aus.
Vor dem Debuggen: Recovery Mode prüfen und Backup sichern
Recovery Mode zuerst prüfen
Seit WordPress 5.2 gibt es den Recovery Mode. Wenn ein fataler PHP-Fehler auftritt, schickt WordPress automatisch eine E-Mail an die hinterlegte Admin-Adresse mit einem Recovery-Link. Über diesen Link kommst du in ein eingeschränktes Backend, in dem das fehlerhafte Plugin bereits markiert ist.
Prüfe deine Mails, bevor du FTP oder SQL anfasst. In vielen Fällen ist das der schnellste Weg zurück.
Backup sichern
Wenn du noch irgendwie an die Datenbank rankommst – erstell jetzt einen manuellen Dump über phpMyAdmin, bevor du weitermachst. Alles was du jetzt tust, kann den Schaden vergrößern wenn dabei etwas schiefgeht.
Schritt 1: PHP-Fehlerlog lesen – bevor du blind deaktivierst
Das ist der Schritt, den die meisten überspringen. Und der dir in der Praxis die meiste Zeit spart. Ich sehe es regelmäßig: Leute deaktivieren blind drauflos, obwohl die Fehlerlog ihnen den Schuldigen direkt ins Gesicht schreit.
Die meisten Hosting-Provider zeigen die PHP-Fehlerlog direkt im Dashboard oder in cPanel. Dort steht in den meisten Fällen exakt, in welcher Datei und welcher Zeile der Fehler passiert – und damit welches Plugin schuld ist.
Wenn keine Log vorhanden ist, aktiviere das WordPress-Debug-Logging manuell in der wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY auf false ist dabei entscheidend – du willst Fehler nicht öffentlich im Frontend anzeigen, sondern still ins Log schreiben. Die drei Zeilen gehören oberhalb von /* That's all, stop editing! */ eingefügt. Die Log-Datei landet unter /wp-content/debug.log.
Du möchtest mehr über das Log erfahren? Dann schau dir den folgenden Artikel an: WordPress debug.log aktivieren und lesen: Fehler in 2 Minuten finden
Schritt 2: Plugins deaktivieren – drei Wege je nach Situation
Weg A: Via Backend
Wenn du noch WP-Admin-Zugriff hast, navigiere zu Plugins → Installierte Plugins, markiere alle Plugins über die Checkbox oben, wähle unter „Massenaktionen“ den Punkt „Deaktivieren“ und klicke auf „Übernehmen“. Lädt die Seite danach wieder, war ein Plugin der Auslöser.
Weg B: Via FTP – wenn das Backend nicht erreichbar ist
Verbinde dich per SFTP mit deinem Server (FileZilla oder ein anderer SFTP-Client) und navigiere nach /wp-content/. Benenne den Ordner plugins um – zum Beispiel in plugins_disabled.
WordPress findet den Ordner nicht mehr und deaktiviert alle Plugins automatisch aus Selbstschutz. Lädt die Seite danach wieder, war ein Plugin der Auslöser. Benenne den Ordner anschließend sofort wieder in plugins zurück, bevor du mit der Einzeldiagnose anfängst.
Weg C: Via SQL – wenn kein FTP-Zugriff möglich ist
-- Alle Plugins auf einmal deaktivieren
UPDATE wp_options
SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';Nur direkt über phpMyAdmin oder einen Datenbank-Client wie TablePlus ausführen – nie über ein WordPress-Plugin. Und nur wenn du weißt was du tust.
Schritt 3: Prüfen ob die Website wieder läuft
Läuft die Website nach dem Deaktivieren wieder? Gut – das bestätigt dass ein Plugin der Auslöser ist.
Läuft sie immer noch nicht, liegt das Problem tiefer: am Theme, an der PHP-Version, an der Datenbank oder an der wp-config.php. Das ist kein Plugin-Konflikt mehr, sondern ein anderes Debugging-Szenario.
Zum Ausschluss: Wechsle testweise auf ein WordPress-Standard-Theme wie Twenty Twenty-Five. Wenn das Problem damit verschwindet, liegt es am Theme, nicht an einem Plugin.
Schritt 4: Den Übeltäter isolieren
Aktiviere die Plugins jetzt einzeln nacheinander – direkt im WP-Admin. Nach jeder Aktivierung die Website neu laden und prüfen ob der Fehler zurückkommt.
Nicht zufällig anfangen. Aktiviere zuerst die Plugins, die du zuletzt installiert oder aktualisiert hast. In der Praxis liegt der Auslöser fast immer dort.
Wenn der Fehler zurückkommt: Das zuletzt aktivierte Plugin ist entweder direkt das Problem, oder es hat einen latenten Konflikt mit einem der bereits aktiven Plugins ausgelöst.
Schritt 5: Zwei-Plugin-Konflikt eingrenzen
Tritt der Fehler nicht auf wenn das verdächtige Plugin alleine aktiv ist? Dann liegt ein Konflikt zwischen zwei Plugins vor.
Vorgehen: Nur das verdächtige Plugin aktiv lassen, alle anderen deaktiviert. Dann die anderen nacheinander dazuschalten und nach jeder Aktivierung prüfen. Sobald der Fehler wieder auftritt hast du das Konfliktpaar gefunden.
Mit dieser Information kannst du gezielt auf die Support-Foren beider Plugins gehen – meistens gibt es dort bereits einen bekannten Workaround oder einen Fix in der Pipeline.
Was nach dem Debugging zu tun ist
Du hast die Ursache gefunden. Drei Optionen:
Plugin ersetzen – Für die meisten Plugin-Kategorien gibt es mehrere gepflegte Alternativen. Prüfe bei der Alternative: letztes Update-Datum, „Tested up to“-Version im Plugin-Verzeichnis, Aktivierungszahl und Support-Aktivität im Forum.
Auf alte Version zurückrollen – Mit WP Rollback kannst du direkt im Backend auf eine frühere Plugin-Version downgraden. Sinnvoll als kurzfristige Maßnahme bis ein offizieller Fix verfügbar ist – aber kein Dauerzustand, da ältere Versionen keine Sicherheits-Updates bekommen.
Entwickler kontaktieren – Wenn das Plugin aktiv gepflegt wird, lohnt es sich den Konflikt detailliert zu melden: WordPress-Version, PHP-Version, das andere konfliktierende Plugin, und die exakte Fehlermeldung aus dem Debug-Log. Gute Plugin-Entwickler reagieren auf solche Reports – sie wollen ihre Kompatibilitätsrate im Plugin-Verzeichnis schützen.
Wie du Plugin-Konflikte in Zukunft vermeidest
Plugin-Konflikte sind nicht vollständig vermeidbar. Aber deutlich seltener, wenn du ein paar Grundregeln einhältst:
Updates nie pauschal – „Alle aktualisieren“ ist bequem, aber das ist auch der Grund warum ich regelmäßig Anrufe bekomme. Einzeln updaten, nach jedem Update kurz die Website prüfen. Besonders bei Plugins die tief ins System eingreifen: Page Builder, SEO-Plugins, Caching, Security.
Plugins mit Verfallsdatum kennen – Jedes Plugin das seit über 12 Monaten kein Update hatte und nicht explizit als kompatibel mit deiner aktuellen WP-Version markiert ist, ist ein aktives Risiko. Regelmäßig prüfen, bei Bedarf ersetzen.
Staging-Umgebung nutzen – Updates dort zuerst testen, bevor sie auf Produktion gehen. Die meisten modernen Managed-WordPress-Hoster bieten das mit einem Klick an. Der einmalige Einrichtungsaufwand zahlt sich bei jedem Update-Zyklus aus.
Vor jedem Update-Zyklus ein Backup – Das klingt selbstverständlich. Ist es aber in der Praxis häufig nicht.
Wenn du das alles beherzigst wirst du Plugin-Konflikte nicht komplett vermeiden – aber du wirst sie deutlich schneller lösen. Und falls du an dem Punkt bist wo 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 WordPress Plugin-Konflikten
Was tun wenn WordPress nach einem Update weiß bleibt?
Prüfe zuerst deine Admin-E-Mail auf einen WordPress Recovery Mode Link. Wenn das Backend noch erreichbar ist, 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?
Aktiviere das Debug-Logging in der wp-config.php mit define('WP_DEBUG_LOG', true). Die Log-Datei unter /wp-content/debug.log zeigt dir in den meisten Fällen direkt welches Plugin den Fehler verursacht. Alternativ: Plugins einzeln nacheinander reaktivieren und nach jeder Aktivierung die Website prüfen.
Kann ich Plugins ohne WP-Admin deaktivieren?
Ja, auf zwei Wegen. Via FTP: Den Ordner /wp-content/plugins/ umbenennen – WordPress deaktiviert dann alle Plugins automatisch. Via SQL: UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins' in phpMyAdmin ausführen. Beide Wege erfordern Server- oder Datenbankzugriff.
Was ist der Unterschied zwischen White Screen of Death und 500 Internal Server Error?
Beide deuten meist auf einen fatalen PHP-Fehler hin, unterscheiden sich aber in der Ausgabe. Der White Screen zeigt gar nichts – kein Fehlertext, keine Seite. Der 500er ist ein HTTP-Statuscode den der Server selbst zurückgibt, oft mit einer Fehlermeldung des Hosters. In beiden Fällen hilft die PHP-Fehlerlog als erster Diagnoseschritt.
Kann ein Plugin-Konflikt erst Wochen nach der Installation auftreten?
Ja. Konflikte entstehen oft nicht beim Installieren, sondern wenn ein weiteres Update eine bestehende Inkompatibilität aktiviert. Ein Plugin das seit Monaten problemlos läuft kann durch das Update eines anderen Plugins plötzlich einen Fatal Error auslösen.