Weißer Bildschirm. Fünf Zeichen: 500 Internal Server Error. Die Seite ist nicht erreichbar, der Kunde schreibt Ihnen, und Sie wissen nicht, wo Sie anfangen sollen.

Der 500-Fehler ist der frustrierendste HTTP-Statuscode. Anders als 404 („Seite nicht gefunden") oder 403 („Zugriff verweigert") nennt er keinen Verursacher. Er sagt lediglich: „Auf dem Server ist etwas schiefgelaufen." Danach sind Sie auf sich allein gestellt: ein Plugin, ein Theme, fehlerhaftes PHP, Hosting, eine beschädigte .htaccess. Es gibt Dutzende Möglichkeiten, und jede erfordert eine andere Lösung.

Die gute Nachricht: Ein 500-Fehler lässt sich immer beheben. Ohne Panik, ohne WordPress komplett neu zu installieren und in den meisten Fällen ohne Entwickler. In 7 Schritten (von der 30-Sekunden-Diagnose bis zum gezielten Austausch von Systemdateien) finden Sie die Ursache und bringen Ihre Seite wieder online. Jede Methode enthält konkrete Dateien, Codezeilen und Screenshots.

💡 Kurzüberblick:

• Schritt 1: WP_DEBUG aktivieren und die Logs lesen, um sofort zu sehen, welche Datei den Fehler verursacht
• Schritt 2: Hosting-Probleme ausschließen, während Sie den Code durchsuchen
• Schritt 3: .htaccess reparieren, die laut Support-Statistiken häufigste Ursache
• Schritt 4: Das PHP-Speicherlimit erhöhen, ein typischer Auslöser beim Hochladen von Medien oder beim Login ins Backend
• Schritt 5: Den WordPress-Core neu hochladen, wenn Dateien durch eine fehlgeschlagene automatische Aktualisierung beschädigt wurden
• Schritt 6: Plugins per FTP deaktivieren, eine Methode, die mehr als die Hälfte aller Fälle löst
• Schritt 7: Auf das Standard-Theme zurücksetzen, ein Schritt, der oft übersehen wird

Was der 500-Fehler ist und woher er kommt

HTTP 500 ist eine Serverantwort, die „interner Fehler" bedeutet. Die Anfrage des Browsers kam an, Apache oder Nginx hat sie angenommen, PHP begann mit der Ausführung und ist dann abgestürzt. Anders als bei 404 oder 403 (wo der Server bewusst mit „Nein" antwortet), bedeutet eine Fünf am Anfang des Codes, dass etwas im Skript kaputtgegangen ist und der Server nicht weiß, was.

In WordPress tritt der 500-Fehler in vier typischen Szenarien auf:

• Sie haben ein Plugin installiert oder aktualisiert, und es kollidiert mit anderem Code im System.
• Sie haben die .htaccess geändert, und ein Syntaxfehler hat Apache abstürzen lassen.
• Ein PHP-Skript hat seinen zugewiesenen Speicher erschöpft (weißer Bildschirm mit Allowed memory size of X bytes exhausted in den Logs).
• Core-Dateien sind beschädigt: eine fehlgeschlagene automatische Aktualisierung, ein abgebrochener FTP-Transfer, ein fehlerhaftes Plugin, das Systemordner verändert hat.

Seltener: ein Theme mit einem fatalen Fehler in der functions.php, hostseitige Probleme (Überlastung, deaktiviertes PHP-Modul) oder ein defekter Shortcode eines entfernten Plugins im Seiteninhalt.

Bevor Sie beginnen: Erstellen Sie ein vollständiges Backup Ihrer Seite. Ohne Backup ist jede Aktion an Serverdateien ein Risiko. Die meisten Hoster bieten im Control Panel (cPanel, ISPmanager, aaPanel) eine Backup-Schaltfläche mit nur zwei Klicks an.

1. WP_DEBUG aktivieren und die Logs lesen

Der schnellste Weg, die Ursache zu finden, ist, WordPress dazu zu bringen, sie preiszugeben. Standardmäßig blendet der Core PHP-Fehler hinter einem weißen Bildschirm aus (das ist der Modus „Besucher nicht verschrecken"). Aber WordPress verfügt über einen eingebauten Debugging-Mechanismus: die WP_DEBUG-Konstanten.

Debug-Modus aktivieren

Öffnen Sie die wp-config.php im Wurzelverzeichnis Ihrer Seite per FTP oder über den Dateimanager Ihres Hosters. Suchen Sie diese Zeile:

1
/* That's all, stop editing! Happy blogging. */

Fügen Sie davor diesen Block ein:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Was hier passiert:

• WP_DEBUG ist der Hauptschalter; ohne true funktionieren die anderen Konstanten nicht.
• WP_DEBUG_LOG leitet alle Fehler in die wp-content/debug.log um, statt sie auf dem Bildschirm anzuzeigen. Besucher sehen keine beängstigenden Meldungen.
• WP_DEBUG_DISPLAY + @ini_set unterdrückt die Anzeige von Fehlern in der Seitenausgabe erzwingend.

Speichern Sie die Datei, laden Sie die problematische Seite Ihrer Website neu und laden Sie die wp-content/debug.log per FTP herunter. Im Log sehen Sie die konkrete Datei und Zeile: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Deaktivieren Sie das Debugging nach der Diagnose. Kommentieren Sie die hinzugefügten Zeilen aus oder löschen Sie sie. WP_DEBUG auf einer Live-Seite verlangsamt die Performance, und die debug.log kann mit der Zeit auf Gigabytes anwachsen.

2. Kontaktieren Sie Ihren Hosting-Anbieter

Wenn die Logs leer sind oder nicht erstellt wurden, liegt der Fehler möglicherweise auf Serverseite und nicht im WordPress-Code. Das kommt besonders häufig bei günstigen Shared-Hosting-Tarifen mit strikten Prozesslimits vor.

Eröffnen Sie ein Support-Ticket und fügen Sie drei Dinge bei:

• Den genauen Zeitpunkt des Auftretens des Fehlers, mit der Zeitzone des Servers.
• Die URL der Seite, auf der der Fehler reproduzierbar ist.
• Einen Screenshot des Fehlers, falls verfügbar.

Der Support prüft die Server-Logs von Apache oder Nginx, die CPU- und Speicherauslastung sowie die verfügbaren PHP-Module. Probleme werden oft in diesem Schritt behoben: Ein Host-Administrator startet PHP-FPM neu oder passt das Prozesslimit an.

So erkennen Sie, auf wessen Seite das Problem liegt

Erstellen Sie eine Datei namens info.php mit einer einzigen Zeile:

1
<?php phpinfo(); ?>

Laden Sie sie per FTP ins Wurzelverzeichnis Ihrer Seite hoch und öffnen Sie your-site.com/info.php. Wenn Sie eine Tabelle mit PHP-Parametern sehen, funktioniert der Server und der Fehler liegt im WordPress-Code. Wenn Sie einen 500-Fehler sehen, liegt der Fehler auf Serverebene; geben Sie diese URL an den Support weiter.

Nach dem Test **löschen Sie **info.php. phpinfo() legt Serverversionen, Pfade und Module offen und schafft so ein Sicherheitsrisiko.

3. Die.htaccess-Datei reparieren

.htaccess ist eine Apache-Konfigurationsdatei im Wurzelverzeichnis Ihrer Seite. WordPress nutzt sie für lesbare URLs, Weiterleitungen und grundlegende Sicherheitsregeln. Eine überflüssige Klammer, ein Konflikt zwischen Regeln zweier Plugins, und die gesamte Seite geht mit einem 500-Fehler offline. Laut Support-Ticket-Statistiken ist .htaccess die häufigste Ursache.

Schnellcheck: Benennen Sie .htaccess per FTP in .htaccess_old um und laden Sie die Seite neu. Wenn sie funktioniert, liegt das Problem definitiv in dieser Datei.

Stellen Sie nun die .htaccess wieder her: Gehen Sie in die WordPress-Administration, Einstellungen → Permalinks und klicken Sie auf „Änderungen speichern", ohne die Struktur zu verändern. WordPress erzeugt eine neue, saubere .htaccess mit den Standardregeln:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Falls Sie benutzerdefinierte Regeln in der .htaccess hatten (Weiterleitungen, Caching, Sicherheit), fügen Sie diese nacheinander wieder hinzu und prüfen Sie die Website nach jeder einzelnen. So identifizieren Sie die problematische Zeile.

4. PHP-Arbeitsspeicher-Limit erhöhen

WordPress-PHP-Skripte benötigen RAM. Wenn ein Plugin oder Theme mehr anfordert, als zugewiesen ist, stürzt das Skript ab. Das Ergebnis: ein 500-Fehler oder eine weiße Seite mit Allowed memory size of X bytes exhausted.

Das Standardlimit liegt bei vielen Hostern noch bei 64 MB. Für eine moderne WordPress-Website mit einem Dutzend Plugins ist das katastrophal niedrig. Das empfohlene Minimum beträgt 256 MB.

Methode 1: über die wp-config.php (bevorzugt)

Fügen Sie dies in die wp-config.php ein, vor /* That's all, stop editing! */:

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

Diese Konstante überschreibt das PHP-Limit für das Frontend der Website. Für den Admin-Bereich erhöht WordPress die Obergrenze automatisch auf WP_MAX_MEMORY_LIMIT (standardmäßig 256 MB).

Methode 2: über die php.ini (falls Ihr Hoster keine Bearbeitung der wp-config erlaubt)

Erstellen Sie eine php.ini-Datei mit folgendem Inhalt:

1
memory_limit = 256M

Laden Sie sie ins Stammverzeichnis der Website und in den Ordner wp-admin/ hoch. Hilft das nicht, erstellen oder bearbeiten Sie die .user.ini im Stammverzeichnis mit derselben Zeile.

Funktionieren beide Methoden nicht, begrenzt Ihr Hosting-Tarif den Arbeitsspeicher physisch. Dann ist es Zeit für ein Tarif-Upgrade oder einen Hosterwechsel.

5. WordPress-Core-Dateien erneut hochladen

Eine beschädigte Core-Datei ist eine seltene, aber heimtückische Ursache. Ein fehlgeschlagenes Auto-Update, ein abgebrochener FTP-Transfer, ein Plugin, das Systemdateien verändert hat, und wp-admin oder wp-includes enthalten Datenmüll.

Vorgehen:

• Laden Sie ein frisches WordPress-ZIP-Archiv von wordpress.org herunter.
• Entpacken Sie das Archiv auf Ihrem Computer.
• Gehen Sie per FTP in das Wurzelverzeichnis Ihrer Website und löschen Sie die Ordner wp-admin und wp-includes (nur diese beiden; wp-content nicht anfassen!).
• Laden Sie die Ordner wp-admin und wp-includes aus dem frischen Archiv hoch.
• Überschreiben Sie wp-content nicht; dort befinden sich Ihre Themes, Plugins und Uploads.

Die Wurzeldateien (wp-settings.php, index.php und andere) können ebenfalls durch frische Versionen aus dem Archiv ersetzt werden. Ausnahme: wp-config.php; fassen Sie diese Datei nicht an, denn sie enthält Ihre Datenbank-Zugangsdaten. Laden Sie die Seite nach dem Austausch neu; der Fehler verschwindet, wenn beschädigte Systemdateien die Ursache waren.

6. Plugins deaktivieren

Ein problematisches Plugin ist die wahrscheinlichste Ursache für einen 500-Fehler. Sie haben mehrere Plugins gleichzeitig aktualisiert und eines kollidierte mit einem anderen: Willkommen beim weißen Bildschirm.

Wenn der Admin-Bereich funktioniert

Gehen Sie zu Plugins → alle auswählen → Massenaktion „Deaktivieren" → „Anwenden". Verschwindet der Fehler, aktivieren Sie die Plugins einzeln und laden Sie die Seite nach jedem Schritt neu. Haben Sie den Verursacher gefunden, löschen Sie ihn oder melden Sie das Problem dem Entwickler.

Wenn der Admin-Bereich nicht erreichbar ist

Verbinden Sie sich per FTP mit dem Server und benennen Sie den Ordner wp-content/plugins in plugins_off um. WordPress stellt das Laden aller Plugins ein und die Website funktioniert wieder. Geben Sie dem Ordner seinen ursprünglichen Namen zurück und benennen Sie die Plugin-Unterordner nacheinander um; so finden Sie das problematische Plugin, ohne den Admin-Bereich zu betreten.

Worauf Sie achten sollten: Caching-Plugins (W3 Total Cache, WP Rocket) schreiben mitunter eigene Regeln in .htaccess und wp-config.php. Nach der Deaktivierung eines solchen Plugins kann der Fehler bestehen bleiben; prüfen Sie diese Dateien und entfernen Sie die Zeilen zwischen Markierungen wie # BEGIN W3TC und # END W3TC oder ähnlichen.

7. Zum Standard-Theme wechseln

Das aktive Theme ist eine unterschätzte, aber reale Quelle für 500-Fehler. Besonders dann, wenn Sie einen Snippet mit einem fatalen Fehler in die functions.php eingefügt haben.

Die Prüfung ist einfach: Benennen Sie per FTP den Ordner des aktiven Themes in wp-content/themes/ um (zum Beispiel mytheme → _mytheme). WordPress erkennt, dass das aktive Theme fehlt, und wechselt automatisch zu einem Standard-Theme: Twenty Twenty-Five oder ein anderes im System installiertes Default-Theme.

Funktioniert die Website mit dem Standard-Theme, liegt das Problem an Ihrem Theme. Geben Sie dem Theme seinen ursprünglichen Namen zurück, öffnen Sie die functions.php und suchen Sie nach Fehlern im eigenen Code. Haben Sie den Code nicht selbst hinzugefügt, kontaktieren Sie den Theme-Entwickler.

⁉️🤔 Häufig gestellte Fragen

Was tun, wenn der 500-Fehler nur beim Einloggen ins Admin-Panel auftritt?

Höchstwahrscheinlich reicht das PHP-Speicherlimit speziell für das Admin-Panel nicht aus, das alle Plugins auf einmal lädt und ressourcenintensiver ist als das Frontend. Fügen Sie die Zeile define( 'WP_MAX_MEMORY_LIMIT', '512M' ); in die wp-config.php ein; dies ist ein separates, höheres Limit für den Admin-Bereich als das Frontend-Limit WP_MEMORY_LIMIT. Prüfen Sie auch Ihren Plugin-Ordner: Unserer Erfahrung nach sind die häufigsten Übeltäter Sicherheits-Plugins wie Wordfence oder Backup-Plugins, die beim Laden der Admin-Leiste Speicher verbrauchen. Deaktivieren Sie diese per FTP (über den Ordner plugins_off aus Schritt 6) und prüfen Sie erneut.

Kann ich einen 500-Fehler ohne FTP-Zugang beheben?

Ja. Die meisten Hoster bieten einen Dateimanager im Control Panel an: cPanel → Dateimanager, ISPmanager → Dateien. Darüber können Sie .htaccess, Plugin- und Theme-Ordner umbenennen und die wp-config.php bearbeiten; alle Schritte sind identisch. Ohne jeglichen Dateizugriff bleibt nur der Support Ihres Hosters. Profitipp: Wenn Sie ein Snippet-Plugin installiert haben (Code Snippets, WPCode) und Ihre letzte Aktion das Hinzufügen eines Snippets war, versuchen Sie, die URL your-site.com/?code_snippets_safe_mode=1 oder eine ähnliche Safe-Mode-URL für Ihr Plugin aufzurufen. Das deaktiviert alle Snippets ohne FTP.

Der 500-Fehler erscheint nur auf einer Seite. Was ist die Ursache?

Eine fehlerhafte Funktion oder ein Shortcode innerhalb des Inhalts dieser spezifischen Seite. Öffnen Sie die Seite im WordPress-Editor (wenn der Admin-Bereich funktioniert) und entfernen Sie vorübergehend alle Shortcodes, Gutenberg-Blöcke und Code-Einbettungen. Ist der Admin-Bereich nicht erreichbar, suchen Sie den Beitrag per phpMyAdmin in der Datenbank (Tabelle wp_posts), kopieren Sie den Inhalt in einen Texteditor und entfernen Sie verdächtige Shortcodes. Die häufigsten Übeltäter: Shortcodes von gelöschten Plugins ([dead_plugin] ist noch vorhanden, aber das Plugin fehlt), fehlerhaftes PHP in Inhaltsblöcken oder falsch verschachtelte Gutenberg-Blöcke.

Nach der Wiederherstellung kehrt der 500-Fehler nach einigen Stunden zurück. Wie finde ich die Ursache?

Ein zyklischer Fehler mit einem Intervall ist fast immer eines von drei Szenarien: Ein WordPress-Cron-Job führt planmäßig einen fehlerhaften Prozess aus, ein Caching-Plugin erzeugt beschädigten Cache, oder der Hoster erreicht periodisch Prozesslimits (besonders auf günstigen Shared-Hosting-Tarifen). Installieren Sie WP Crontrol und prüfen Sie die Liste der Cron-Aufgaben; finden Sie diejenige, die zeitlich mit dem Absturz zusammenfällt. Leeren Sie den Cache Ihres Caching-Plugins. Fragen Sie Ihren Hoster nach dem Limit für Entry Processes oder PHP Workers; auf Shared-Tarifen sind diese oft auf 5-10 begrenzt, und eine Traffic-Spitze legt die Website lahm.

Muss ich alle 7 Schritte durchgehen oder kann ich einige überspringen?

Die ersten beiden Schritte (WP_DEBUG und Hosting) sind diagnostisch: Sie zerstören nichts und liefern Informationen. In unserer Erfahrung mit der Betreuung von WordPress-Websites lösen Schritt 3 (.htaccess) und Schritt 6 (Plugins) die allermeisten Fälle. Der Rest entfällt auf PHP-Speicher, beschädigten Core und das Theme. In einer typischen Situation lösen Sie das Problem bei Schritt 3 oder 6, ohne die gesamte Kette durchlaufen zu müssen.

Womit Sie jetzt beginnen sollten

Wiederholen Sie nicht das typische Szenario: Panik → wahllos alles löschen → alles noch schlimmer machen. Halten Sie sich an die Reihenfolge von der Diagnose zur Lösung:

Die oberste Regel bei WordPress-Reparaturen: eine Aktion, eine Prüfung. Führen Sie niemals zwei Korrekturen gleichzeitig durch; Sie wissen sonst nicht, welche gewirkt hat. Und notieren Sie genau, welches Plugin oder welche Bearbeitung den Fehler verursacht hat. Beim nächsten Mal beheben Sie alles in 30 Sekunden.