WordPress 500 Internal Server Error: Ursachen & Lösung

Ein Fehler 500 ist die unpräziseste Meldung, die ein Webserver kennt. Sie bedeutet nur: Irgendwo zwischen Webserver, PHP und WordPress ist etwas schiefgegangen. Je nach Hoster sehen Sie eine schlichte Textzeile, eine gestaltete Fehlerseite des Hosters oder eine leere Browserseite mit dem Hinweis „HTTP ERROR 500“.

Weil die Meldung so allgemein ist, hilft Raten wenig. Die gute Nachricht: Der Server schreibt die eigentliche Ursache fast immer in ein Protokoll. Dieser Ratgeber zeigt, wie Sie sie finden – und was in welchem Fall zu tun ist.

Schritt 1: Was ist zuletzt passiert?

Bevor Sie etwas ändern, beantworten Sie diese Frage. Sie grenzt die Ursache stark ein:

Nach einem Update – von WordPress, einem Plugin oder dem Theme? Dann ist das zuletzt aktualisierte Element der Hauptverdächtige.
Nach einem Umzug zu einem neuen Hoster oder auf eine neue Domain? Dann stehen .htaccess, PHP-Version und Dateirechte im Vordergrund.
Nur im Backend unter /wp-admin/, während die Website selbst läuft? Dann liegt es meist an einem Plugin, das nur im Admin-Bereich Code ausführt, oder am Arbeitsspeicher.
Ohne erkennbaren Anlass? Dann prüfen Sie, ob der Hoster die PHP-Version umgestellt hat oder ob ein Plugin sich automatisch aktualisiert hat.

Schritt 2: Sichern

Bevor Sie Dateien umbenennen oder bearbeiten, sichern Sie den aktuellen Stand – Dateien und Datenbank. Die meisten Hoster bieten das im Kundenbereich an. Wo nicht: Dateien per FTP herunterladen, Datenbank über phpMyAdmin exportieren. Diese Sicherung ist Ihre Rückfalllinie, falls bei der Fehlersuche etwas schiefgeht.

Schritt 3: Das Fehlerprotokoll lesen

Das ist der wichtigste Schritt, und er wird am häufigsten übersprungen.

Fehlerprotokoll des Hosters. Fast jeder Hoster stellt im Kundenbereich ein „Error Log“ bereit. Suchen Sie die Einträge zum Zeitpunkt Ihres Seitenaufrufs. Steht dort ein Hinweis auf .htaccess – etwa „Invalid command“ oder „RewriteRule“ –, liegt es an der Konfigurationsdatei. Steht dort PHP Fatal error mit einem Pfad in wp-content/plugins/ oder wp-content/themes/, haben Sie den Verursacher.

WordPress-eigenes Protokoll. In der wp-config.php können Sie oberhalb von /* That's all, stop editing! */ die Protokollierung einschalten:

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

WordPress schreibt Fehler dann in die Datei wp-content/debug.log. Lassen Sie WP_DEBUG_DISPLAY auf false, damit Besucher keine Fehlermeldungen sehen, und schalten Sie die Protokollierung nach der Fehlersuche wieder ab. Ein dauerhaft offenes Debug-Log auf einer Live-Seite ist ein Sicherheitsrisiko.

Bleibt debug.log leer, obwohl der Fehler auftritt, ist das ein Hinweis: Dann scheitert der Aufruf schon, bevor WordPress überhaupt startet – meist an der .htaccess oder an der Serverkonfiguration.

Schritt 4: Die .htaccess testen

Die Datei .htaccess liegt im Hauptverzeichnis Ihrer Installation. Sie steuert unter anderem die Permalinks. Ein einziger fehlerhafter Eintrag – von einem Plugin, einem Sicherheitswerkzeug oder von Hand – reicht für einen Fehler 500 auf allen Seiten.

So testen Sie es, ohne etwas zu verlieren:

Benennen Sie .htaccess per FTP in .htaccess-alt um. Manche FTP-Programme blenden Dateien mit Punkt am Anfang aus; aktivieren Sie dann die Anzeige versteckter Dateien.
Laden Sie die Startseite neu. Funktioniert sie, war die Datei die Ursache.
Melden Sie sich im Backend an, öffnen Sie Einstellungen → Permalinks und klicken Sie ohne Änderung auf Speichern. WordPress legt dann eine neue .htaccess mit den Standardregeln an.
Übernehmen Sie eigene Regeln aus der alten Datei – Weiterleitungen, Caching, Sicherheitsregeln – einzeln und prüfen Sie nach jeder, ob die Seite noch lädt.

Schritt 5: Plugins und Theme ausschließen

Hat die .htaccess nichts geändert, sind Plugins der nächste Verdacht.

Benennen Sie per FTP den Ordner wp-content/plugins in plugins-alt um. Damit sind alle Plugins deaktiviert, ihre Einstellungen bleiben in der Datenbank erhalten.

Die Seite lädt wieder? Benennen Sie den Ordner zurück und aktivieren Sie die Plugins im Backend einzeln. Nach jedem Schritt die Seite neu laden. Das Plugin, nach dem der Fehler zurückkommt, ist der Verursacher.
Der Fehler bleibt? Benennen Sie den Ordner Ihres aktiven Themes in wp-content/themes/ testweise um. WordPress fällt dann auf ein installiertes Standard-Theme zurück, sofern eines vorhanden ist.

Ausführlicher beschrieben ist dieses Vorgehen im Ratgeber zum kritischen Fehler / weißen Bildschirm, denn dort ist die Ursache oft dieselbe.

Schritt 6: Speichergrenze und PHP-Version

Arbeitsspeicher. Page-Builder, Shop-Plugins und Import-Funktionen brauchen viel Speicher. In der wp-config.php lässt sich die Grenze anheben:

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

WP_MAX_MEMORY_LIMIT gilt für Vorgänge im Backend – genau das, was bei einem Fehler 500 nur im wp-admin oft hilft. Setzt der Server selbst ein niedrigeres Limit, wirken diese Zeilen nicht; dann muss die Grenze beim Hoster angehoben werden.

PHP-Version. Ein Plugin, das seit Jahren kein Update bekommen hat, läuft auf einer neuen PHP-Version unter Umständen nicht mehr. Die eingestellte Version finden Sie im Kundenbereich des Hosters. Eine Rückstellung auf eine ältere Version kann als kurzfristiger Notbehelf die Seite wieder online bringen, ist aber keine Lösung: Ältere PHP-Versionen erhalten irgendwann keine Sicherheitsupdates mehr. Der richtige Weg ist, die betroffene Erweiterung zu aktualisieren oder zu ersetzen.

Sonderfall: Fehler 500 nach einem Umzug

Nach einem Hosterwechsel kommen drei weitere Ursachen dazu:

Einträge in der .htaccess, die der neue Server nicht kennt. Ein Beispiel sind Zeilen wie php_value oder php_flag: Sie funktionieren nur, wenn PHP als Apache-Modul läuft. Läuft PHP beim neuen Hoster über FastCGI oder PHP-FPM, lösen genau diese Zeilen einen Fehler 500 aus. Solche Einstellungen gehören dann in eine .user.ini oder in die PHP-Einstellungen im Kundenbereich.
Falscher RewriteBase. Lag WordPress vorher in einem Unterordner und jetzt im Hauptverzeichnis (oder umgekehrt), passt der Pfad in der .htaccess nicht mehr. Die neu erzeugte Datei aus Schritt 4 behebt das.
Dateirechte. Beim Hochladen werden Rechte manchmal falsch gesetzt. Üblich sind 755 für Ordner und 644 für Dateien. Ihr Hoster kann Ihnen sagen, welche Werte auf seinen Servern gelten.

Sonderfall: Fehler nach einem abgebrochenen Update

Bricht ein WordPress-Update mittendrin ab, können Kerndateien unvollständig sein. Laden Sie dann dieselbe WordPress-Version von wordpress.org herunter und überschreiben Sie per FTP die Ordner wp-admin und wp-includes. Der Ordner wp-content und die Datei wp-config.php bleiben unangetastet.

Sehen Sie statt eines Fehlers 500 die Meldung, die Seite sei wegen Wartungsarbeiten kurzzeitig nicht verfügbar, ist eine Datei namens .maintenance im Hauptverzeichnis liegen geblieben. Löschen Sie diese Datei, dann ist die Seite wieder erreichbar.

Umsetzungsplan

Arbeiten Sie die Punkte in dieser Reihenfolge ab.

Sofort

Klären, wann der Fehler aufgetreten ist: nach Update, nach Umzug, nur im wp-admin oder ohne Anlass.
Dateien und Datenbank sichern.
Fehlerprotokoll des Hosters lesen; bei Bedarf WP_DEBUG_LOG einschalten und wp-content/debug.log prüfen.

Danach

.htaccess testweise umbenennen; bei Erfolg über Einstellungen → Permalinks neu erzeugen.
Plugins über das Umbenennen von wp-content/plugins gesammelt deaktivieren und einzeln wieder einschalten.
Theme testweise ausschließen.
Speichergrenze mit WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT prüfen, PHP-Version im Kundenbereich kontrollieren.
Nach einem Umzug: php_value-Zeilen, RewriteBase und Dateirechte prüfen.
Debug-Protokollierung wieder abschalten.

Vorbeugen

Updates nicht ungeprüft auf der Live-Seite einspielen, sondern vorher auf einer Testkopie.
Automatische Sicherungen von Dateien und Datenbank einrichten.
Plugins entfernen, die seit langer Zeit kein Update mehr erhalten haben.
Die Seite überwachen lassen, damit ein Fehler 500 nicht erst Tage später auffällt – zum Beispiel über unser Managed Hosting.

Wir beheben das für Sie

Wenn das Protokoll nichts Verständliches liefert, mehrere Ursachen zusammenkommen oder Sie an der Seite lieber nichts selbst ändern möchten: Wir finden den Fehler und nennen Ihnen vorher einen festen Preis für die Reparatur. Läuft Ihre Seite auf einem anderen System als WordPress, hilft Website-Fehler beheben.

Wir beheben das für Sie
Schildern Sie kurz, was passiert ist – wir melden uns schnellstmöglich zurück.

Fehler beheben lassen → Notfall-Diagnose für 99 €

Die WordPress-Notfall-Diagnose kostet 99 € und umfasst die Sicherung, das Auslesen der Fehlerprotokolle und ein Festpreis-Angebot für die Reparatur – bei Beauftragung werden die 99 € angerechnet. Oder rufen Sie direkt an: 0 33 41 - 35 66 146.

Häufige Fragen

Was bedeutet „500 Internal Server Error“?

Der Fehler 500 ist eine allgemeine Meldung des Webservers: Bei der Verarbeitung der Anfrage ist etwas schiefgegangen, und der Server kann nicht genauer sagen, was. Bei WordPress sind die häufigsten Auslöser eine fehlerhafte .htaccess-Datei, ein Plugin oder Theme mit PHP-Fehler, eine zu niedrige Speichergrenze, eine nicht passende PHP-Version oder falsche Dateirechte. Die genaue Ursache steht im Fehlerprotokoll des Servers.

Warum tritt der Fehler 500 nach einem Update auf?

Nach einem Update läuft neuer Code auf Ihrem Server. Passt ein aktualisiertes Plugin nicht zur PHP-Version, kollidiert es mit einem anderen Plugin oder dem Theme, oder wurde das Update unvollständig abgebrochen, kann das einen Serverfehler auslösen. Der erste Verdacht gilt deshalb immer der Erweiterung, die zuletzt aktualisiert wurde.

Warum kommt der Fehler 500 nur im wp-admin?

Im Backend laden viele Plugins zusätzlichen Code, der auf der öffentlichen Seite gar nicht ausgeführt wird. Außerdem braucht das Backend mehr Arbeitsspeicher. Ein Plugin mit Fehler im Admin-Bereich oder eine zu knappe Speichergrenze zeigen sich deshalb oft nur dort. Prüfen Sie das Fehlerprotokoll und testen Sie die Plugins einzeln.

Wie setze ich die .htaccess-Datei zurück?

Benennen Sie die Datei .htaccess im Hauptverzeichnis Ihrer WordPress-Installation per FTP in .htaccess-alt um. Lädt die Startseite danach, war die Datei die Ursache. Melden Sie sich im Backend an, öffnen Sie Einstellungen › Permalinks und klicken Sie ohne Änderung auf Speichern. WordPress legt dann eine neue .htaccess mit den Standardregeln an. Eigene Regeln aus der alten Datei übernehmen Sie danach einzeln und prüfen nach jeder, ob die Seite noch lädt.

Ist ein 500er-Fehler schlecht für Google?

Kurzzeitig nicht dramatisch. Bleibt er über längere Zeit bestehen, kann Google die betroffenen Seiten seltener abrufen und schließlich aus dem Index nehmen. Beheben Sie den Fehler deshalb zügig und prüfen Sie danach in der Google Search Console, ob dort Serverfehler gemeldet werden.