WordPress 500 Internal Server Error beheben

Statt deiner Seite steht da nur „HTTP 500 — Interner Serverfehler” oder „Die Website kann diese Anfrage momentan nicht bearbeiten”. Kein Hinweis, kein Stacktrace, nichts. Das ist Absicht: Der Server verschluckt die echte Fehlermeldung, damit er sie nicht an Besucher (und Angreifer) ausplaudert. Klingt nach Totalschaden, ist aber fast immer in 15 Minuten gelöst. Wichtig vorab: Ein 500er ist serverseitig. Der Fehler passiert auf dem Server, bevor PHP fertig rendern konnte — und genau deshalb steht die Ursache irgendwo in einem Log. Das ist deine Abkürzung.

Soforthilfe

Bevor du irgendwas änderst, sichere dir den Zugang und ein Backup:

1. FTP/SFTP oder Datei-Manager im Hosting-Panel öffnen. Du brauchst Datei-Zugriff auf das WordPress-Verzeichnis. Das Admin-Backend (/wp-admin) ist beim 500er oft mit tot — verlass dich nicht darauf.
2. Komplettes Backup ziehen — Dateien plus Datenbank. Wenn dein Hoster Snapshots anbietet, lös einen aus. So kannst du jeden Schritt gefahrlos rückgängig machen.
3. Reproduzieren: Tritt der Fehler nur im Frontend auf, nur im Backend, oder überall? Das grenzt die Ursache schon stark ein (Backend-only deutet oft auf ein Plugin, überall eher auf .htaccess oder PHP).

Der schnellste Weg: das Server-Error-Log lesen

Bei einem 500er ist das Log nicht „auch ganz nett” — es ist der Schlüssel. Der Server schreibt die echte Fehlermeldung dorthin, die er dir im Browser verschweigt.

Du findest es an einer dieser Stellen:

• Hosting-Panel (Plesk, cPanel, KIS): Bereich „Logs”, „Fehlerprotokolle” oder „Error Log”.
• Per FTP: eine Datei error_log direkt im WordPress-Ordner oder im betroffenen Unterverzeichnis.
• Server-weit: /var/log/apache2/error.log bzw. nginx/error.log, falls du SSH hast.

Schau dir die letzten Zeilen an. Typische Klartext-Ursachen: PHP Fatal error: Allowed memory size exhausted (Speicherlimit), Premature end of script headers (oft .htaccess/PHP-Config), Call to undefined function (Plugin/Theme inkompatibel zur PHP-Version). Diese eine Zeile spart dir das blinde Durchprobieren.

Ursache 1: beschädigte .htaccess

Die .htaccess im WordPress-Root steuert Permalinks und Rewrites. Ein kaputter Eintrag — oft durch ein Plugin, ein Caching-Tool oder einen Migrationsschritt — wirft sofort einen 500er.

So testest du es:

1. .htaccess per FTP in .htaccess_alt umbenennen (nicht löschen).
2. Seite neu laden. Geht sie jetzt? Dann war die Datei die Ursache.
3. Im WordPress-Backend auf Einstellungen → Permalinks gehen und einmal „Änderungen speichern” klicken — auch ohne etwas zu ändern. WordPress schreibt eine frische, saubere .htaccess.

Ursache 2: PHP-Speicherlimit erschöpft

Wenn das Log memory size exhausted zeigt, ist PHP der Arbeitsspeicher ausgegangen — typisch bei vielen aktiven Plugins, großen Imports oder einem schweren Page-Builder. Trag in deiner wp-config.php (vor der Zeile /* That's all, stop editing! */) ein:

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

Hilft das nicht, blockt dein Hosting-Tarif das Limit serverseitig. Dann musst du im Panel die php.ini-Direktive memory_limit anheben — oder beim Hoster nachfragen, denn manche Shared-Tarife deckeln hart.

Ursache 3: falsche oder zu neue PHP-Version

Ein PHP-Sprung (etwa von 7.4 auf 8.2) deaktiviert nicht selten ein älteres Plugin oder Theme, das die neue Version nicht kennt. Das Log zeigt dann undefined function oder syntax error. Geh im Hosting-Panel (Plesk: „PHP-Einstellungen”, cPanel: „MultiPHP Manager”) und stell die PHP-Version eine Stufe zurück — etwa von 8.3 auf 8.1. Läuft die Seite wieder, ist klar: Eine Komponente ist nicht auf dem aktuellen Stand. Update sie, dann kannst du PHP wieder hochsetzen.

Ursache 4: Plugin oder Theme

Crasht der 500er erst seit einem Update oder einer Neuinstallation, ist meist ein Plugin schuld:

1. Per FTP den Ordner wp-content/plugins in plugins_alt umbenennen. Damit sind alle Plugins deaktiviert.
2. Geht die Seite? Dann den Ordner zurückbenennen und die Plugins einzeln über das Backend reaktivieren, bis der Fehler zurückkommt. Der letzte ist der Übeltäter.
3. Für Themes dasselbe: aktives Theme umbenennen, WordPress fällt automatisch auf ein Standard-Theme (twentytwentyfour) zurück.

Ursache 5: falsche Dateirechte

Selten, aber real — besonders nach einer Migration oder einem manuellen Upload. Stimmen die Rechte nicht, verweigert der Server die Ausführung mit 500. Die korrekten Werte: Verzeichnisse 755, Dateien 644. wp-config.php darf auf 600 oder 640 stehen. Per FTP-Client (Rechtsklick → „Dateiberechtigungen”) oder im Datei-Manager setzbar. Niemals 777 setzen — das ist ein Sicherheitsrisiko, kein Fix.

Debug: WordPress den echten Fehler zeigen lassen

Wenn das Server-Log nichts Brauchbares hergibt, lass WordPress die PHP-Fehler in eine eigene Datei schreiben — sichtbar nur für dich, nicht für Besucher. In wp-config.php:

// WordPress-Debug-Modus, Ausgabe in Datei statt auf den Bildschirm
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // schreibt nach wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // nichts ans Frontend ausgeben
@ini_set( 'display_errors', 0 );

Seite einmal aufrufen, dann wp-content/debug.log per FTP öffnen. Dort steht die Datei plus Zeilennummer, die den Crash auslöst — dein Treffer. Wichtig: Nach der Fehlersuche alle drei WP_DEBUG-Zeilen wieder auf false setzen. Ein offener Debug-Modus auf einer Live-Seite verrät Pfade und Versionen.

So vermeidest du das künftig

• Vor jedem Update ein Backup — Dateien und Datenbank. Ein 500er nach einem Plugin-Update ist dann ein Klick rückgängig.
• PHP-Versionssprünge auf einer Staging-Kopie testen, nie direkt live. Viele Hoster bieten Staging mit einem Klick.
• Plugin-Friedhof aufräumen: Jedes inaktive Plugin ist eine potenzielle Fehlerquelle und ein Stück Speicher. Was du nicht brauchst, löschst du.
• Datei-Zugang griffbereit halten — FTP-Daten und Panel-Login dokumentieren, bevor es brennt.

Oder: Schluss mit WordPress-Bränden

Die ehrliche Wahrheit nach dem nächsten 500er: Dieser Fehler ist hausgemacht durch den Stack. Eine mit Astro gebaute Seite hat kein PHP, keine Plugins, keine Live-Datenbank — sie wird einmal zu statischen Dateien gebaut und ausgeliefert. Es gibt schlicht keinen serverseitigen Prozess, der mit „Internal Server Error” abstürzen könnte. Kein Speicherlimit, keine PHP-Version, die ein Plugin abschießt, keine .htaccess-Rewrites, die kippen. webAION migriert deine WordPress-Seite zum Festpreis nach Astro und übernimmt dabei deine Inhalte — du behältst, was du hast, und verlierst die Brandgefahr. Wenn du wissen willst, wie das läuft: WordPress zu Astro migrieren. Und falls dein aktueller Fehler ein anderer ist: alle WordPress-Fehler im Überblick.