Die Kernaussage: Die meisten WordPress-Fehler — weißer Bildschirm, 500-Fehler, Speicher erschöpft, 404-Fehler nach einer Migration — lassen sich auf eine von vier Grundursachen zurückführen: einen Plugin-/Theme-Konflikt, ein PHP-Speicher- oder Ausführungslimit, eine beschädigte .htaccess-Datei oder ein Datenbankverbindungsproblem. Zu diagnostizieren, welche davon vorliegt, statt wahllos Korrekturen auszuprobieren, bringt eine Site am schnellsten wieder online.
Warum immer dieselbe Handvoll Fehler zurückkehrt
WordPress läuft auf PHP, einem Webserver und einer Datenbank, und die meisten Fehler, auf die Website-Betreiber stoßen, sind eigentlich Ausfälle in einer dieser drei Ebenen, die durch WordPress an die Oberfläche kommen, statt Fehler im WordPress-Kern selbst. Das zu wissen ist nützlich, weil die Lösung meist nicht "WordPress neu installieren" lautet — sondern herauszufinden, welche Ebene ausgefallen ist, und genau das zu beheben.
Die vier unten aufgeführten Grundursachen machen die große Mehrheit der in Support-Foren und Hosting-Tickets gemeldeten WordPress-Fehler aus, und jede hat eine spezifische, wiederholbare Lösung statt eines vagen "Cache leeren".
Der White Screen of Death (WSOD)
Eine komplett leere weiße Seite ohne sichtbare Fehlermeldung bedeutet fast immer, dass ein PHP-Fatalfehler aufgetreten ist, WordPress' Standardkonfiguration Fehler aber vor Besuchern verbirgt, statt sie anzuzeigen. Die zwei häufigsten Auslöser sind ein Plugin oder Theme, das nicht mit der aktuellen PHP-Version der Site kompatibel ist, und die Site, die mitten in einer Anfrage ihr zugewiesenes PHP-Speicherlimit erschöpft.
Zum Diagnostizieren: Aktiviere den Debug-Modus, indem du zwei Zeilen zur wp-config.php hinzufügst — define('WP_DEBUG', true); und define('WP_DEBUG_LOG', true); — dies schreibt den tatsächlichen PHP-Fehler in eine debug.log-Datei innerhalb von wp-content, statt ihn zu verbergen. Das ist in WordPress' eigenem offiziellen Debugging-Leitfaden dokumentiert. Sobald der spezifische Fehler und die Datei sichtbar sind, besteht die Lösung meist darin, das eine im Protokoll genannte Plugin oder Theme zu deaktivieren.
Wenn FTP oder ein Dateimanager der einzige verfügbare Zugriff ist (weil der WSOD auch das Admin-Dashboard blockiert), zwingt das Umbenennen des plugins-Ordners innerhalb von wp-content alle Plugins dazu, sich gleichzeitig zu deaktivieren — die Site sollte wieder laden, und Plugins können einzeln reaktiviert werden, um den Übeltäter zu finden.
500 Internal Server Error
Anders als der weiße Bildschirm ist ein 500-Fehler eine generische Fehlermeldung auf Serverebene, keine WordPress-spezifische — er kann von einer beschädigten .htaccess-Datei, einem Plugin-Konflikt, einem PHP-Ausführungs-Timeout oder einer Serverfehlkonfiguration stammen, die nichts mit dem eigentlichen WordPress-Code zu tun hat. Deshalb ist die Prüfung des tatsächlichen Server-Fehlerprotokolls (in den meisten Hosting-Kontrollpanels verfügbar) ein zuverlässigerer erster Schritt als Raten.
Häufige Lösungen, nach Häufigkeit ihrer Wirksamkeit geordnet:
- .htaccess vorübergehend umbenennen (WordPress erzeugt beim erneuten Speichern der Permalinks-Einstellungen eine neue Standarddatei) — behebt beschädigungsbedingte 500-Fehler sofort.
- Alle Plugins über phpMyAdmin deaktivieren, indem die active_plugins-Zeile der wp_options-Tabelle umbenannt wird, falls der Admin-Zugriff nicht funktioniert.
- Das PHP-Ausführungszeitlimit erhöhen, wenn der Fehler nur bei aufwendigen Vorgängen wie großen Importen auftritt.
"Allowed Memory Size Exhausted"-Fehler
Dieser spezifische, ausführliche PHP-Fehler ("Allowed memory size of X bytes exhausted") bedeutet, dass ein Skript versucht hat, mehr Speicher zu nutzen als PHP erlaubt, und ist einer der selbsterklärenderen WordPress-Fehler, da er das genaue Problem bereits in der Meldung nennt.
Die Lösung hat zwei Ebenen. Zuerst das eigene Speicherlimit von WordPress erhöhen, indem define('WP_MEMORY_LIMIT', '256M'); zur wp-config.php hinzugefügt wird. Zweitens, falls das nicht hilft, muss möglicherweise auch das zugrunde liegende, von der Hosting-Umgebung selbst festgelegte PHP-memory_limit erhöht werden — WordPress' Konstante kann nicht überschreiten, was der Server erlaubt, sodass ein Support-Ticket beim Host oder eine Bearbeitung der php.ini manchmal unvermeidlich ist.
Schnellreferenztabelle
| Fehler | Häufigste Ursache | Erste zu versuchende Lösung |
|---|---|---|
| Weißer Bildschirm (WSOD) | Plugin-/Theme-PHP-Fatalfehler | WP_DEBUG aktivieren, debug.log prüfen |
| 500 Internal Server Error | Beschädigte .htaccess oder Plugin-Konflikt | .htaccess über Permalinks regenerieren |
| Speicher erschöpft | PHP-Speicherlimit zu niedrig | WP_MEMORY_LIMIT in wp-config.php erhöhen |
| 404 auf allen Seiten außer Startseite | Rewrite-Regeln nicht synchron | Permalinks-Einstellungen erneut speichern |
| Datenbankverbindungsfehler | Falsche Zugangsdaten oder beschädigte Tabelle | DB-Zugangsdaten in wp-config.php prüfen |
404-Fehler nach einer Migration oder einem Update
Wenn die Startseite lädt, aber jede andere Seite einen 404 zurückgibt, ist die in der WordPress-Datenbank gespeicherte Permalink-Struktur mit den in der .htaccess gespeicherten Rewrite-Regeln nicht mehr synchron — eine häufige Nebenwirkung eines Hostwechsels, einer Backup-Wiederherstellung oder eines Serverwechsels. Das erneute Speichern der Permalinks-Einstellungen im WordPress-Admin (Einstellungen → Permalinks → Änderungen speichern, ohne dass tatsächliche Änderungen nötig sind) regeneriert die .htaccess und behebt das meist sofort.
Datenbankverbindungsfehler
"Error establishing a database connection" bedeutet, dass WordPress die MySQL/MariaDB-Datenbank überhaupt nicht erreichen kann, was sich von den obigen Fehlern unterscheidet, da es passiert, bevor WordPress überhaupt so weit laden kann, um seine eigene Fehlerdarstellung zu zeigen. Die zwei häufigsten Ursachen sind falsche Datenbank-Zugangsdaten in der wp-config.php (oft nach einer Migration) und eine beschädigte Datenbanktabelle, meist wp_options. Die Konstanten DB_NAME, DB_USER, DB_PASSWORD und DB_HOST in der wp-config.php gegen das tatsächliche Hosting-Panel zu prüfen, löst den Fall falscher Zugangsdaten; ein vom Host bereitgestelltes Datenbank-Reparaturtool löst meist Tabellenbeschädigungen.
Ein systematischer Weg, jeden WordPress-Fehler zu diagnostizieren
- Den tatsächlichen Fehler prüfen, nicht nur das Symptom — WP_DEBUG aktivieren oder das Server-Fehlerprotokoll prüfen, statt von einem leeren Bildschirm oder einer generischen Meldung zu raten.
- Auf einer Kopie testen, nicht auf der Live-Site, wann immer die Lösung das Deaktivieren von Plugins oder das Bearbeiten von Kerndateien beinhaltet — eine Staging-Site existiert genau dafür.
- Jeweils nur eine Sache ändern — alle Plugins gleichzeitig zu deaktivieren sagt dir, dass ein Plugin die Ursache ist, nicht welches.
- Ursachen auf Hosting-Ebene ausschließen — PHP-Versionskonflikte und niedrige Speicherlimits sind oft ein Hosting-Konfigurationsproblem, kein WordPress-Problem; siehe unseren umfassenderen WordPress-Geschwindigkeits- und Konfigurationsleitfaden für die Hosting-Ebenen-Faktoren, die auch Fehlerraten beeinflussen.
Diese Fehler von vornherein verhindern
Schlecht programmierte Plugins — besonders schwere Bildgalerien oder Medienverarbeitungstools, die bei jeder Anfrage große Bibliotheken in den Speicher laden — sind eine unverhältnismäßig häufige Quelle von Speicher-Erschöpfungs-Abstürzen. Eine leichtere Alternative, die die nativen Bildbibliotheken des Servers nutzt, statt einen externen Verarbeitungsstack zu laden, wie Erdo Image Optimizer, fügt spürbar weniger Speicher-Overhead hinzu als schwerere All-in-one-Medien-Plugins.
Über die Plugin-Wahl hinaus machen dieselben Gewohnheiten, die Fehler verhindern, sie auch schneller behebbar, wenn sie doch auftreten: regelmäßige Backups, Tests von Updates auf einer Staging-Kopie vor dem Livegang, und PHP sowie WordPress-Kern einigermaßen aktuell halten, damit sich Kompatibilitätsfehler nicht Jahr für Jahr durch Vernachlässigung aufsummieren.
Häufige Fehler bei der Behebung von WordPress-Fehlern
- Den WordPress-Kern als erste Reaktion neu installieren, obwohl die tatsächliche Ursache fast immer ein bestimmtes Plugin, Theme oder eine Hosting-Ebenen-Einstellung ist.
- Plugins auf der Live-Site während der Geschäftszeiten einzeln deaktivieren und reaktivieren, wenn eine Staging-Kopie den Übeltäter ohne besucherseitige Ausfallzeit finden ließe.
- Das Fehlerprotokoll komplett ignorieren und wahllose Korrekturen basierend auf dem sichtbaren Symptom (einer leeren Seite) statt dem tatsächlichen PHP-Fehler dahinter ausprobieren.
- wp-config.php ohne vorherige Sicherungskopie bearbeiten, wodurch ein behebbarer Fehler zu einer komplett nicht ladenden Site wird, falls ein Tippfehler eingeführt wird.
- Annehmen, ein 500-Fehler sei immer WordPress' Schuld, obwohl serverseitige Fehlkonfiguration und generische PHP-Ausfälle dieselbe Meldung erzeugen.
Zusammenfassung
Kurz gesagt: Der weiße Bildschirm, 500-Fehler, Speichererschöpfung und kaputte Permalinks, die den Großteil der WordPress-Support-Anfragen ausmachen, lassen sich alle auf eine kleine Anzahl von Grundursachen zurückführen — Plugin-/Theme-Konflikte, PHP-Limits, .htaccess-Beschädigung oder Datenbankprobleme — jede mit einer spezifischen, wiederholbaren Lösung. Den Debug-Modus zu aktivieren und den tatsächlichen Fehler zu lesen, statt vom sichtbaren Symptom zu raten, ist die eine Gewohnheit, die einen stressigen Ausfall in eine Fünf-Minuten-Korrektur verwandelt.