WordPress weißer Bildschirm? So beheben Sie die häufigsten WordPress-Fehler

Kurzfassung

Der White Screen of Death (WSOD) und 500er-Fehler bei WordPress haben fast immer dieselben Ursachen: ein PHP-Fatal-Error, ein Plugin-Konflikt, ein erschöpftes Speicherlimit oder eine kaputte .htaccess-Datei. Der schnellste Weg zur Diagnose: WP_DEBUG aktivieren, Fehlerprotokolle prüfen, alle Plugins deaktivieren und auf ein Standard-Theme wechseln. Diese Anleitung führt dich Schritt für Schritt durch jeden Fall — mit Befehlen zum direkten Kopieren und Einfügen.

Voraussetzungen

• SSH-Zugang zum Server (mindestens FTP/SFTP)
• Ein Terminal mit bash oder vergleichbarer Shell
• MySQL/MariaDB-Client (Kommandozeile oder phpMyAdmin)
• WP-CLI installiert (dringend empfohlen)
• Ein aktuelles Backup von Dateien und Datenbank
• Der Installationspfad deiner WordPress-Instanz (hier wird /var/www/html verwendet)

White Screen of Death

Eine komplett weiße Seite bedeutet, dass PHP auf einen fatalen Fehler gestoßen ist, die Fehlerausgabe aber unterdrückt wird. Erster Schritt: Fehler sichtbar machen.

Schritt 1: WP_DEBUG aktivieren

Öffne die wp-config.php und füge folgende Zeilen vor der Zeile /* That's all, stop editing! */ ein:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );

Per Kommandozeile geht es schneller:

cd /var/www/html

wp config set WP_DEBUG true --raw --allow-root
wp config set WP_DEBUG_LOG true --raw --allow-root
wp config set WP_DEBUG_DISPLAY true --raw --allow-root

Seite neu laden — statt der weißen Seite sollte jetzt die eigentliche PHP-Fehlermeldung erscheinen. Außerdem wird alles in wp-content/debug.log protokolliert.

Schritt 2: Debug-Log prüfen

tail -50 /var/www/html/wp-content/debug.log

Suche nach Zeilen mit Fatal error. Dort steht die betroffene Datei und Zeilennummer.

Schritt 3: PHP-Speicherlimit erhöhen

Wenn der Fehler Allowed memory size exhausted lautet:

// In wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Zusätzlich in der PHP-Konfiguration:

# Aktive php.ini finden
php -i | grep "Loaded Configuration File"

# Speicherlimit setzen
sudo sed -i 's/memory_limit = .*/memory_limit = 256M/' /etc/php/8.2/fpm/php.ini
sudo systemctl restart php8.2-fpm

500 Internal Server Error

Ein 500er-Fehler heißt, der Webserver konnte die Anfrage nicht verarbeiten. Die häufigsten Ursachen: kaputte .htaccess und PHP-Ressourcenlimits.

.htaccess umbenennen

cd /var/www/html
mv .htaccess .htaccess.kaputt

Seite testen. Wenn sie lädt, Permalinks neu generieren:

wp rewrite flush --allow-root

Oder eine saubere Standard-.htaccess schreiben:

cat > /var/www/html/.htaccess << 'EOF'
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
EOF
chown www-data:www-data /var/www/html/.htaccess

PHP-Limits für 500er-Fehler anpassen

# Aktuelle Limits prüfen
php -i | grep -E 'max_execution_time|max_input_vars|post_max_size|upload_max_filesize'

# Limits erhöhen
sudo tee /etc/php/8.2/fpm/conf.d/99-wordpress.ini << 'EOF'
max_execution_time = 300
max_input_vars = 5000
post_max_size = 64M
upload_max_filesize = 64M
memory_limit = 256M
EOF

sudo systemctl restart php8.2-fpm

Plugin-Konflikte debuggen

Plugin-Konflikte sind die mit Abstand häufigste Fehlerquelle bei WordPress. Die systematische Vorgehensweise: alle Plugins deaktivieren und einzeln wieder einschalten.

Methode 1: Per WP-CLI (bevorzugt)

cd /var/www/html

# Aktive Plugins auflisten
wp plugin list --status=active --allow-root

# Alle auf einmal deaktivieren
wp plugin deactivate --all --allow-root

# Seite testen, dann einzeln reaktivieren
wp plugin activate plugin-name --allow-root

Methode 2: Plugin-Ordner umbenennen

Wenn WP-CLI nicht verfügbar ist oder die Seite gar nicht mehr reagiert:

cd /var/www/html/wp-content
mv plugins plugins.deaktiviert
mkdir plugins

WordPress deaktiviert automatisch alle Plugins, weil die Dateien nicht mehr gefunden werden. Nach der Diagnose:

rm -rf plugins
mv plugins.deaktiviert plugins

# Dann über WP-CLI oder Admin-Oberfläche einzeln aktivieren

Methode 3: Per Datenbank

# Aktive Plugins anzeigen
wp db query "SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';" --allow-root

# Alle Plugins per SQL deaktivieren
wp db query "UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';" --allow-root

Theme-Probleme

Wenn das Deaktivieren der Plugins nicht hilft, liegt der Fehler möglicherweise am aktiven Theme.

Theme per WP-CLI wechseln

# Installierte Themes anzeigen
wp theme list --allow-root

# Auf Standard-Theme wechseln
wp theme activate twentytwentyfour --allow-root

# Falls kein Standard-Theme installiert ist
wp theme install twentytwentyfour --activate --allow-root

Theme per Datenbank wechseln

Falls WP-CLI nicht funktioniert:

mysql -u root -p wordpress_db << 'EOF'
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';
UPDATE wp_options SET option_value = 'Twenty Twenty-Four' WHERE option_name = 'current_theme';
EOF

Hinweis: Ersetze wp_options durch dein tatsächliches Tabellenpräfix, falls du es bei der Installation geändert hast.

Datenbank-Verbindungsfehler

Die gefürchtete Meldung „Error establishing a database connection“. Gehe diese Schritte der Reihe nach durch.

Schritt 1: Zugangsdaten in wp-config.php prüfen

grep -E 'DB_NAME|DB_USER|DB_PASSWORD|DB_HOST' /var/www/html/wp-config.php

Schritt 2: Verbindung manuell testen

# Zugangsdaten extrahieren und Verbindung testen
DB_NAME=$(wp config get DB_NAME --allow-root 2>/dev/null || grep "DB_NAME" /var/www/html/wp-config.php | cut -d"'" -f4)
DB_USER=$(wp config get DB_USER --allow-root 2>/dev/null || grep "DB_USER" /var/www/html/wp-config.php | cut -d"'" -f4)
DB_HOST=$(wp config get DB_HOST --allow-root 2>/dev/null || grep "DB_HOST" /var/www/html/wp-config.php | cut -d"'" -f4)

mysql -u "$DB_USER" -p -h "$DB_HOST" "$DB_NAME" -e "SELECT 1;"

Schritt 3: Läuft MySQL/MariaDB überhaupt?

# Dienststatus prüfen
sudo systemctl status mysql
# oder
sudo systemctl status mariadb

# Bei Bedarf neu starten
sudo systemctl restart mysql

# Lauscht der Port?
ss -tlnp | grep 3306

Schritt 4: Datenbank reparieren

// Temporär in wp-config.php einfügen
define( 'WP_ALLOW_REPAIR', true );

Dann https://deineseite.de/wp-admin/maint/repair.php aufrufen. Die Zeile danach sofort wieder entfernen.

Recovery Mode & Notfall-Login

Seit WordPress 5.2 wird bei fatalen Fehlern automatisch ein Recovery Mode aktiviert. WordPress schickt dem Admin einen speziellen Login-Link per E-Mail.

Wenn die E-Mail nicht angekommen ist

# Recovery-Keys in der Datenbank prüfen
wp db query "SELECT * FROM wp_options WHERE option_name LIKE '%recovery%';" --allow-root

# Notfall-Admin-Account anlegen
wp user create notfalladmin admin@example.com --role=administrator --user_pass='SicheresPasswort123!' --allow-root

Notfall-Login-Skript

Wenn wp-admin komplett unerreichbar ist, hilft ein temporäres PHP-Skript:

<?php
// Speichern als /var/www/html/notfall-login.php
// SOFORT NACH VERWENDUNG LÖSCHEN!
require_once('./wp-load.php');
$user = get_user_by('login', 'admin'); // dein Admin-Benutzername
if ($user) {
    wp_set_auth_cookie($user->ID, true);
    wp_redirect(admin_url());
    exit;
}
echo 'Benutzer nicht gefunden.';

Sicherheitshinweis: Diese Datei sofort löschen! Jeder, der die URL aufruft, wird als Admin eingeloggt.

PHP-Versionskompatibilität

Eine inkompatible PHP-Version ist ein häufiger Grund für den WSOD nach Server-Updates.

Aktuelle PHP-Version prüfen

# CLI-Version
php -v

# Version, die der Webserver nutzt (kann abweichen!)
wp eval 'echo phpversion();' --allow-root

# Oder temporär eine phpinfo-Datei anlegen
echo '<?php phpinfo();' > /var/www/html/phpinfo.php
# Im Browser aufrufen, dann sofort löschen
rm /var/www/html/phpinfo.php

Anforderungen von WordPress und Plugins prüfen

# WordPress-Version anzeigen
wp core version --allow-root
# WordPress 6.x benötigt PHP 7.4+, empfohlen ist 8.1+

# Veraltete Funktionen im Theme/in Plugins suchen
grep -rn 'create_function\|mysql_connect\|each(' /var/www/html/wp-content/themes/dein-theme/
grep -rn 'create_function\|mysql_connect\|each(' /var/www/html/wp-content/plugins/

PHP-Version wechseln (Ubuntu/Debian)

# Verfügbare PHP-Versionen anzeigen
ls /etc/php/

# Apache-Modul wechseln
sudo a2dismod php7.4
sudo a2enmod php8.2
sudo systemctl restart apache2

# Oder PHP-FPM-Pool wechseln
sudo systemctl stop php7.4-fpm
sudo systemctl start php8.2-fpm
# Nginx/Apache-Vhost auf den neuen FPM-Socket anpassen

Fehlerprotokolle prüfen

Wenn WP_DEBUG nicht genug verrät, schau in die Fehlerprotokolle des Webservers.

Apache

# Standard-Fehlerlogs
tail -100 /var/log/apache2/error.log
tail -100 /var/log/httpd/error_log

# Konfiguriertes Log für deinen VHost finden
grep -r 'ErrorLog' /etc/apache2/sites-enabled/

Nginx

# Standard-Fehlerlog
tail -100 /var/log/nginx/error.log

# Konfiguriertes Log für deinen Server-Block finden
grep -r 'error_log' /etc/nginx/sites-enabled/

PHP-FPM

# PHP-FPM-Log (oft die eigentliche Ursache bei 502/503)
tail -100 /var/log/php8.2-fpm.log

# Pool-spezifische Logs finden
grep 'error_log\|slowlog' /etc/php/8.2/fpm/pool.d/www.conf

WordPress Debug-Log

# Live-Ansicht des WordPress-Debug-Logs
tail -f /var/www/html/wp-content/debug.log

Fehlerbehebung

WSOD nur im Admin-Bereich

Typischerweise ein Plugin, das sich ins Admin-Dashboard einklinkt. Plugins per WP-CLI oder Datenbank deaktivieren (siehe Plugin-Konflikte debuggen).

WSOD nur im Frontend

In der Regel ein Theme-Problem. Auf Standard-Theme wechseln (siehe Theme-Probleme).

Fehler nach WordPress-Core-Update

# Core-Dateien neu installieren (ohne wp-content anzufassen)
wp core download --force --skip-content --allow-root
wp core update-db --allow-root

„Wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar“

# Ein fehlgeschlagenes Update hat die Wartungsdatei hinterlassen
rm /var/www/html/.maintenance

Zu viele Weiterleitungen / Redirect-Schleife

# Seiten-URLs prüfen
wp option get siteurl --allow-root
wp option get home --allow-root

# Falls falsch, korrigieren
wp option update siteurl 'https://deineseite.de' --allow-root
wp option update home 'https://deineseite.de' --allow-root

Berechtigungsprobleme

# Korrekte Besitzrechte und Dateiberechtigungen setzen
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
sudo chmod 600 /var/www/html/wp-config.php

Prävention

1. Automatische Backups

Tägliche Backups von Dateien und Datenbank einrichten. Und vor allem: regelmäßig prüfen, ob die Wiederherstellung auch wirklich funktioniert.

# Datenbank-Backup per WP-CLI
wp db export /backups/wordpress-$(date +%Y%m%d).sql --allow-root

# Datei-Backup
tar czf /backups/wp-dateien-$(date +%Y%m%d).tar.gz /var/www/html/wp-content/

2. Staging-Umgebung

Nie direkt auf der Produktivseite updaten. Immer erst auf einer Staging-Kopie testen.

3. Update-Strategie

• Automatische Sicherheits-Updates aktiviert lassen (sind standardmäßig an)
• Größere Updates zuerst auf Staging testen
• Plugins einzeln updaten, nicht alle auf einmal
• Protokollieren, was wann aktualisiert wurde

4. Monitoring

# Einfacher Verfügbarkeitscheck per Cron
curl -sS -o /dev/null -w "%{http_code}" https://deineseite.de | grep -q 200 || echo "Seite nicht erreichbar" | mail -s "WordPress-Alarm" admin@example.com

5. Sicherheitshärtung

// In wp-config.php einfügen
define( 'DISALLOW_FILE_EDIT', true );   // Theme/Plugin-Editor deaktivieren
define( 'AUTOMATIC_UPDATER_DISABLED', false ); // Auto-Updates beibehalten
define( 'WP_AUTO_UPDATE_CORE', 'minor' );      // Minor-Releases automatisch

6. Fehlerprotokollierung im Produktivbetrieb

Debug-Logging aktiv lassen, aber die Anzeige für Besucher deaktivieren:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

So landen alle Fehler in wp-content/debug.log, ohne dass Besucher sie sehen. Die Log-Datei regelmäßig rotieren, damit sie nicht unkontrolliert wächst.