Website lädt nicht - 500 internal Server Error

Ihre Website zeigt nur eine weiße Seite und den Hinweis „500 Internal Server Error“? Das passiert häufig. Die schlechte Nachricht: Es gibt nicht die eine Ursache. Die gute Nachricht: Mit einem strukturierten Vorgehen finden Sie die Ursache in der Regel schnell heraus und können sie beheben.

Wichtig ist jetzt: ruhig bleiben. Der nächste Schritt ist der Blick in die Fehlerprotokolle (Logs). Dort finden Sie fast immer den entscheidenden Hinweis.

Fehlerprotokolle prüfen

Die Logs erreichen Sie über den FTP-Zugang oder in Ihrer Hosting-Verwaltung. Entscheidend ist, dass Sie die Fehler (Errors) anzeigen lassen.

Plesk: Websites & Domains → Protokolle → Filter auf „Fehler“
cPanel: Metriken → Fehler (zeigt die letzten ~300 Einträge)
Direkt am Server: /var/www/vhosts/IHRE-DOMAIN/logs/error_log

In den Protokollen finden Sie nun die entsprechenden Hinweise. Schauen Sie, ob Sie Einträge mit Error 500 finden. Ist dies der Fall, schauen Sie welche Dateien betroffen sind oder ob Pfade aufgeführt werden. Mit etwas Glück finden Sie so bereits die Ursache. Handelt es sich um ein Plugin oder eine Erweiterung, können Sie dies testweise deaktivieren.

Häufige Ursachen

Fehlerhafte Plugins oder Themes (WordPress)

Sehr oft liegt die Ursache an einem Plugin oder Theme, besonders nach einem Update. Im Log sehen Sie dann Hinweise auf bestimmte Ordner oder Dateien. Wenn Sie sich unsicher sind, dann kopieren Sie die Fehlermeldung aus dem Log und suchen mit dieser in Google nach Informationen. Alternativ können Sie auch probieren den Support Ihres Hosting Anbieters zu kontaktieren.

Lösung: Benennen Sie per FTP den Ordner wp-content/plugins in plugins.off um. Damit werden alle Plugins deaktiviert. Benennen Sie den Ordner des aktiven Themes (z. B. astra) ebenfalls um, damit WordPress ein Standard-Theme lädt. Lädt die Seite wieder, aktivieren Sie die Plugins und das Theme nacheinander, bis der Auslöser gefunden ist.

Kaputte .htaccess-Datei und WordPress

Eine fehlerhafte .htaccess kann die komplette Seite lahmlegen. Benennen Sie die Datei testweise um. Lädt die Website dann wieder, setzen Sie die Standard-Regeln neu ein:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Falsche PHP-Version oder fehlende Erweiterungen

Manche Anwendungen brauchen eine bestimmte PHP-Version oder Erweiterungen wie mbstring oder intl. Wenn etwas fehlt, sehen Sie im Log Meldungen wie „Call to undefined function“. Prüfen Sie auch, welche PHP Version Sie aktuell einsetzen.

So prüfen Sie das:

Plesk: Websites & Domains → PHP-Einstellungen
cPanel: Software → MultiPHP Manager (Version) und Select PHP Version (Erweiterungen)

Wichtige Erweiterungen: curl, dom, exif, gd/imagick, intl, json, mbstring, mysqli, openssl, simplexml, zip

Außerdem ist es sinnvoll zu prüfen, ob es kürzlich Updates gegeben hat. Manchmal aktualisiert sich Software automatisch. Also auch wenn Sie nicht explizit ein Update angestoßen haben, so ist es grundsätzlich möglich, dass sich die Software aktualisiert haben könnte. Prüfen Sie welche Version der Software Sie einsetzen und ganz wichtig, prüfen Sie ebenso, mit welcher PHP Version die Software kompatibel ist. Selbst wenn die eigentliche Software mit der von Ihnen genutzten PHP Version kompatibel ist, muss dies nicht auf etwaig verwendete Erweiterungen oder Plugins zu treffen.

Speicher- oder Zeitlimit erreicht

Im Log erkennen Sie das an Meldungen wie „Allowed memory size exhausted“ oder „Maximum execution time exceeded“.

Lösung: Erhöhen Sie das memory_limit (z. B. 256M oder 512M) und die max_execution_time (z. B. 120). Das geht über php.ini, .user.ini oder im Hosting-Panel. In WordPress können Sie in der wp-config.php auch folgenden Eintrag ergänzen:

define('WP_MEMORY_LIMIT','256M');

Wenn Sie selbst keine Änderungen an PHP Einstellungen vornehmen können oder Ihnen es schlicht und einfach nicht gelingt, wenden Sie sich an den Support Ihres Hosting Anbieters. Dieser sollte Ihnen dies bezüglich helfen können.

Falsche Dateirechte oder Eigentümer

Meldungen wie „Permission denied“ oder „open_basedir restriction in effect“ deuten darauf hin.

Ordner sollten auf 755 gesetzt sein
Dateien auf 644
wp-config.php auf 640

In Plesk kann das Repair Kit (falls verfügbar) Rechte automatisch reparieren.

Falsches Document Root oder fehlende index.php

Besonders nach einem Umzug taucht das auf. Im Log steht dann oft „Primary script unknown“. Insbesondere nach Umzügen kann es sich zudem auszahlen den Cache zu leeren. Ist dies über die Software nicht möglich, können Sie den Inhalt des Cache Verzeichnisses auch manuell leeren oder das Verzeichnis umbenennen. Gibt es Probleme, können Sie ein neues, leeres Verzeichnis mit dem Namen Cache erstellen.

Prüfen Sie: Zeigt das Document Root auf den richtigen Ordner? Bei Frameworks wie Laravel oder Symfony muss es meist auf /public zeigen. Auch defekte Symlinks können die Ursache sein.

PHP-FPM oder OPcache hängt

Manchmal hängt die PHP-Ausführung. Das zeigt sich ohne klare Meldung.

Plesk: PHP-Einstellungen öffnen und speichern (dadurch Neustart von FPM/OPcache), alternativ PHP Version ändern und wieder zurückstellen.
cPanel: PHP-Version kurz wechseln und wieder zurückstellen

Sicherheitsfilter (ModSecurity/WAF)

Wenn der Fehler nur bei bestimmten Aufrufen erscheint, blockiert evtl. die Web Application Firewall. Wichtig: Deaktivieren Sie nicht die gesamte WAF, sondern nur die betroffene Regel für die Domain. Beseitigen Sie anschließend die Ursache im Code. Die jeweilige Regel würde in so einem Fall in den Logs auftauchen. Daher bitte nur Regeln deaktivieren, wenn diese auch tatsächlich in Zusammenhang mit dem Fehler im Log zu finden sind.

Ressourcen-Limits (CloudLinux oder Anbieterlimits)

Unter Last können Limits wie „Entry Processes“ oder CPU-Limits erreicht werden. In cPanel sehen Sie das unter „Metriken → Ressourcenverwendung“, in Plesk unter „Ressourcennutzung“ (falls verfügbar). Bei häufigen Limit-Treffern hilft nur Optimierung oder ein Upgrade.

Die Ressourcen-Limits werden mit Fehlern wie z.B. 508 in den Logs aufgeführt. Stoßen Sie ohne „echten“ Traffic öfter an die Limits, könnte dies aufgrund von Bots oder Angriffen der Fall sein. Halten Sie Ihre Augen daher nach IP Adressen offen, die ggf. sehr oft, lange oder in großen Mengen Aufrufe verursachen. Ob eine IP Adresse nicht sauber ist, erfahren Sie mit Tools wie abuseipdb.com. Die Abfragen sind kostenlos und helfen Ihnen dabei zu verstehen, welche IP Adressen und Dienste Sie ggf. aussperren sollten.

Datenbankprobleme

Meldungen wie „SQLSTATE[HY000]“ oder „PDOException“ deuten auf Datenbankprobleme hin. Prüfen Sie in WordPress die wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Reparieren oder optimieren Sie ggf. Tabellen und prüfen Sie lange Abfragen.

Selbstverständlich können Sie auch Tabellen optimieren oder reparieren, wenn Sie kein WordPress verwenden. Dies ist in der Regel mit Tools wie phpMyAdmin möglich. In der Regel sind diese Tools über cPanel und Plesk zugänglich.

Systematisch testen

Gehen Sie strukturiert vor und testen Sie nach jedem Schritt:

Plugins deaktivieren und Standard-Theme aktivieren
.htaccess umbenennen
PHP-Version wechseln und Erweiterungen prüfen
Speicher- und Zeitlimits anpassen
Dateirechte kontrollieren

WordPress-Debug aktivieren

Falls Sie WordPress einsetzen, können Sie temporär den Debug-Modus aktivieren. Öffnen Sie die wp-config.php und fügen Sie oberhalb von /* That's all, stop editing! */ folgende Zeilen ein:

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

Die Fehler werden dann in wp-content/debug.log geschrieben. Nach der Analyse den Debug-Modus unbedingt wieder deaktivieren. Verwenden Sie kein WordPress können Sie in den PHP Einstellungen von cPanel und Plesk einstellen, dass Fehlermeldungen auch im Browser angezeigt werden und nicht nur ins Log geschrieben werden.

Wenn gar nichts mehr geht

Wenn Sie die Ursache nicht finden:

Spielen Sie ein Backup ein
Nutzen Sie eine Staging-Umgebung für Tests
Kontaktieren Sie den Support – am besten gleich mit Log-Ausschnitten, Datum, Uhrzeit und der genauen URL

Bei Support Anfragen ist wichtig, dass die oben genannten Informationen enthalten sind. Um so besser Sie das Problem schildern, um so schneller wird Ihnen der Support Ihres Hosting Anbieters helfen können. Wenn Sie bereits Schritte unternommen haben, dann erwähnen Sie dies auch unbedingt.

Vorbeugende Maßnahmen

Ganz vermeiden lässt sich diese Problematik nie. Alleine schon, wenn man auf automatisierte Aktualisierungen setzt. Allerdings gibt es einige Vorkehrungen die Sie treffen können. Die beiden wichtigsten sind dabei regelmäßige Backups anzulegen und Änderungen oder Updates immer zuerst in einer Testumgebung auszuprobieren.

Führen Sie Updates zuerst in einer Testumgebung durch
Verwenden Sie nur so viele Plugins wie nötig
Erstellen und testen Sie regelmäßig Backups
Überwachen Sie Ressourcen und Limits
Nutzen Sie Monitoring (z. B. Uptime-Checks mit Fehler-Alarm)
Prüfen Sie die Logs regelmäßig

Hinweis: Der 500-Fehler sieht immer gleich aus, aber die Ursache finden Sie fast immer im Log. Verwechseln Sie ihn nicht mit 502/503/504/508 – diese weisen eher auf Überlastungen oder Timeouts hin.