Fehler 500 in WordPress beheben: Ursachen finden und systematisch lösen

Ein 500 Internal Server Error gehört zu den unangenehmeren WordPress-Fehlern, weil die Meldung zunächst kaum etwas über die eigentliche Ursache verrät. Der Webserver hat die Anfrage erhalten, konnte sie aber aufgrund eines internen Problems nicht erfolgreich verarbeiten.

Bei einer WordPress-Website können unter anderem PHP-Fehler, Plugins, Themes, fehlerhafte Regeln in .htaccess, ein ausgeschöpftes Speicherlimit oder Probleme nach einer Änderung beziehungsweise Aktualisierung beteiligt sein.

Wichtig ist deshalb, den HTTP-Status 500 nicht mit der eigentlichen Fehlerursache zu verwechseln.

Kurz erklärt: Ein Fehler 500 bedeutet nicht automatisch, dass WordPress beschädigt ist. Prüfe zuerst, wann und wo der Fehler auftritt. Kontrolliere danach Error Logs und die unmittelbar zuvor vorgenommenen Änderungen. Erst anhand dieser Informationen solltest du Plugins, Theme, PHP, .htaccess oder andere Komponenten gezielt untersuchen.

Was bedeutet HTTP 500 Internal Server Error? #

HTTP-Statuscodes beschreiben das Ergebnis einer Anfrage zwischen Client und Server.

Ein Statuscode aus der 500er-Gruppe weist auf einen serverseitigen Fehler hin. Bei 500 Internal Server Error konnte der Server die Anfrage aufgrund eines internen Fehlers nicht wie vorgesehen abschliessen.

Die Meldung beschreibt damit zunächst nur das Ergebnis – nicht dessen konkrete Ursache.

Bei WordPress können beispielsweise folgende Bereiche beteiligt sein:

• PHP
• WordPress-Core
• Plugins
• Themes oder Child-Themes
• .htaccess beziehungsweise Rewrite-Regeln
• PHP-Speicherlimit
• Dateien und Dateiberechtigungen
• Serverkonfiguration

Wie sieht ein Fehler 500 aus? #

Je nach Browser, Webserver und Hosting-Umgebung kann die sichtbare Meldung unterschiedlich aussehen.

Typische Bezeichnungen sind beispielsweise:

500 Internal Server Error

oder lediglich:

HTTP ERROR 500

Manchmal erscheint statt einer expliziten 500-Seite auch eine weitgehend leere Seite oder eine andere allgemeine Fehlermeldung.

Deshalb ist es hilfreich, den tatsächlichen HTTP-Status und vorhandene Serverprotokolle zu berücksichtigen.

1. Prüfen, ob wirklich ein HTTP-500-Fehler vorliegt #

Bevor du WordPress veränderst, solltest du das Fehlerbild möglichst genau bestimmen.

Ein HTTP 500 ist etwas anderes als:

• 404 Not Found
• 403 Forbidden
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout
• DNS-Fehler
• SSL-Zertifikatsfehler
• Fehler beim Aufbau einer Datenbankverbindung

Wenn die Website grundsätzlich überhaupt nicht erreicht werden kann, solltest du zunächst die breitere Diagnose unter WordPress-Website nicht erreichbar: Ursachen systematisch prüfen verwenden.

2. Welche Bereiche der Website sind betroffen? #

Teste nicht nur die Startseite.

Rufe beispielsweise folgende Bereiche auf:

https://deine-domain.ch

https://deine-domain.ch/eine-unterseite

https://deine-domain.ch/wp-admin

Dadurch lässt sich der Fehler weiter eingrenzen.

Mögliche Situationen sind:

• gesamte Website zeigt Fehler 500
• nur der Adminbereich zeigt Fehler 500
• nur das Frontend ist betroffen
• nur eine einzelne Seite ist betroffen
• Fehler tritt nur bei einer bestimmten Aktion auf
• Fehler tritt nur sporadisch auf

Ein Fehler, der ausschließlich beim Absenden eines bestimmten Formulars auftritt, hat beispielsweise eine andere Ausgangslage als eine Website, die bei jeder Anfrage mit HTTP 500 antwortet.

3. Was wurde unmittelbar vor dem Fehler geändert? #

Der zeitliche Zusammenhang ist einer der wichtigsten Hinweise bei der Fehlersuche.

Überlege, ob unmittelbar vor Auftreten des Fehlers beispielsweise:

• WordPress aktualisiert wurde
• ein Plugin installiert wurde
• ein Plugin aktiviert wurde
• ein Plugin aktualisiert wurde
• ein Theme aktualisiert wurde
• das Theme gewechselt wurde
• PHP geändert wurde
• .htaccess bearbeitet wurde
• wp-config.php verändert wurde
• PHP-Code eingefügt wurde
• ein Code-Snippet aktiviert wurde

Wenn der Fehler unmittelbar nach einer konkreten Änderung begonnen hat, solltest du dort mit der Diagnose beginnen.

Praxis-Tipp: Ändere während der Fehlersuche möglichst immer nur eine Komponente gleichzeitig. Sonst kann die Website zwar plötzlich wieder funktionieren, die tatsächliche Ursache bleibt aber unbekannt.

4. Error Logs prüfen #

Bei einem HTTP-500-Fehler sind Server- beziehungsweise PHP-Fehlerprotokolle häufig wesentlich hilfreicher als die sichtbare Browsermeldung.

Ein Error Log kann beispielsweise Hinweise enthalten auf:

• PHP Fatal Error
• Syntaxfehler
• nicht vorhandene Funktionen oder Klassen
• Speicherüberschreitung
• Plugin-Dateien
• Theme-Dateien
• Probleme mit PHP-Erweiterungen
• Datei- oder Pfadprobleme

Entscheidend sind vor allem Einträge, deren Zeitstempel zum Auftreten des Fehlers passt.

Wenn der Fehler beispielsweise um 14:32 Uhr ausgelöst wurde, sind alte Warnungen von mehreren Tagen zuvor normalerweise nicht der erste Ansatzpunkt.

5. Dateipfad im Error Log auswerten #

Der in einer PHP-Fehlermeldung genannte Dateipfad kann einen wichtigen Hinweis liefern.

Ein Pfad wie:

wp-content/plugins/beispiel-plugin/...

weist darauf hin, dass Code eines Plugins am Fehler beteiligt ist.

Ein Pfad wie:

wp-content/themes/beispiel-theme/...

führt dagegen in Richtung Theme beziehungsweise Child-Theme.

Ein Dateipfad ist allerdings nicht immer der vollständige Beweis für die eigentliche Ursache. Eine Komponente kann einen Fehler auslösen, der erst beim Aufruf von Code einer anderen Komponente sichtbar wird.

6. WordPress-Debugging verwenden #

Wenn vorhandene Serverprotokolle nicht ausreichen, können die Debugging-Funktionen von WordPress zusätzliche Informationen liefern.

Wichtige Konstanten sind:

WP_DEBUG

WP_DEBUG_LOG

WP_DEBUG_DISPLAY

Bei entsprechender Konfiguration kann WordPress Fehlermeldungen beispielsweise in:

wp-content/debug.log

protokollieren.

Wie du Debugging auf einer produktiven Website kontrolliert einsetzt und Logs richtig liest, behandeln wir ausführlich unter WordPress Debugging aktivieren und Fehlerprotokolle verwenden.

Achtung: Detaillierte PHP-Fehlermeldungen sollten auf einer produktiven Website nicht dauerhaft öffentlich angezeigt werden. Fehlerprotokolle können interne Pfade und weitere technische Informationen enthalten.

7. Plugin als Ursache eines Fehler 500 prüfen #

Plugins gehören bei WordPress zu den möglichen Ursachen eines HTTP-500-Fehlers.

Besonders verdächtig ist ein Plugin, wenn der Fehler unmittelbar nach:

• Installation
• Aktivierung
• Update
• Änderung seiner Konfiguration

begonnen hat.

Ist der WordPress-Adminbereich noch erreichbar, deaktiviere zunächst das betreffende Plugin und teste die fehlerhafte Anfrage erneut.

Verschwindet der Fehler, sollte anschließend geklärt werden, warum das Plugin das Problem verursacht.

8. Plugin deaktivieren, wenn der Adminbereich nicht erreichbar ist #

Wenn ein Plugin den Fehler verursacht und der WordPress-Adminbereich ebenfalls nicht mehr funktioniert, kann das betreffende Plugin bei entsprechender Erfahrung über den Dateizugriff deaktiviert werden.

Plugins befinden sich normalerweise unter:

wp-content/plugins/

Ein Plugin-Verzeichnis könnte beispielsweise lauten:

wp-content/plugins/beispiel-plugin/

Wenn dieses Verzeichnis vorübergehend umbenannt wird, kann WordPress das Plugin unter seinem bisherigen Pfad nicht mehr laden.

Diese Methode sollte gezielt eingesetzt werden, wenn das betroffene Plugin bekannt oder zumindest stark verdächtig ist.

9. Wenn kein bestimmtes Plugin bekannt ist #

Ist kein konkretes Plugin als Ursache bekannt, kann eine systematische Konfliktprüfung notwendig sein.

Dabei werden Plugins kontrolliert deaktiviert und anschließend schrittweise wieder aktiviert, bis sich der Fehler reproduzieren lässt.

Das Ziel ist nicht einfach, die Website irgendwie ohne Plugins zum Laufen zu bringen. Entscheidend ist, die tatsächlich beteiligte Komponente beziehungsweise Kombination zu identifizieren.

Die ausführliche Vorgehensweise findest du unter Plugin- oder Theme-Konflikte in WordPress erkennen und beheben.

10. Theme als Ursache prüfen #

Auch das aktive Theme kann PHP-Code enthalten, der einen HTTP-500-Fehler auslöst.

Das ist besonders relevant, wenn der Fehler nach:

• einem Theme-Update
• einem Theme-Wechsel
• einer Änderung des Child-Themes
• einer Änderung an functions.php

aufgetreten ist.

Ist der Adminbereich erreichbar, kann zur Diagnose vorübergehend auf ein geeignetes aktuelles WordPress-Standardtheme gewechselt werden.

Funktioniert die Website damit wieder, sollte das bisher aktive Theme genauer untersucht werden.

11. Theme manuell untersuchen #

Wenn der Adminbereich nicht erreichbar ist, befinden sich die Theme-Dateien normalerweise unter:

wp-content/themes/

Das Verzeichnis des aktiven Themes kann für eine gezielte Diagnose vorübergehend umbenannt werden.

Damit WordPress anschließend auf ein anderes Theme zurückgreifen kann, muss jedoch ein geeignetes anderes Theme installiert sein.

Wichtig: Ein Theme-Wechsel kann das Erscheinungsbild und bestimmte Funktionen der Website stark verändern. Er dient in diesem Fall der Diagnose und sollte nicht mit einer endgültigen Designentscheidung verwechselt werden.

12. .htaccess als mögliche Ursache #

Auf Apache-basierten beziehungsweise kompatiblen Webserver-Konfigurationen kann WordPress die Datei:

.htaccess

für Rewrite-Regeln und weitere Konfigurationen verwenden.

Fehlerhafte Direktiven oder Regeln können unter bestimmten Bedingungen einen HTTP-500-Fehler verursachen.

Das kann beispielsweise nach:

• manueller Bearbeitung
• Änderungen durch ein Plugin
• Einfügen ungeeigneter Serverregeln
• Migration zwischen unterschiedlichen Serverumgebungen

auftreten.

13. .htaccess nicht einfach löschen #

Wenn .htaccess als Ursache vermutet wird, solltest du die bestehende Datei zunächst sichern.

Eine mögliche Diagnose besteht darin, sie vorübergehend umzubenennen, beispielsweise in:

.htaccess-backup

und anschließend die Website erneut zu testen.

Funktioniert die Website danach wieder, ist dies ein starker Hinweis darauf, dass eine Regel in der bisherigen Datei beteiligt war.

Achtung: Eine .htaccess-Datei kann neben WordPress-Permalinks auch Sicherheitsregeln, Weiterleitungen oder andere individuelle Konfigurationen enthalten. Überschreibe sie deshalb nicht ungeprüft.

14. WordPress-Regeln für Permalinks neu erzeugen #

Wenn der Adminbereich wieder erreichbar ist und eine normale WordPress-Permalink-Konfiguration verwendet wird, können die Rewrite-Regeln über:

Einstellungen → Permalinks

neu geschrieben werden, indem die Einstellungen gespeichert werden.

Das ist insbesondere bei Permalink- und Rewrite-Problemen relevant.

Wenn dein eigentliches Fehlerbild HTTP 404 betrifft, findest du die detaillierte Vorgehensweise unter Fehler 404 in WordPress beheben und Permalinks reparieren.

15. Fehler nach einer Änderung der PHP-Version #

Wenn der HTTP-500-Fehler unmittelbar nach einem Wechsel der PHP-Version aufgetreten ist, sollte die Kompatibilität der WordPress-Komponenten geprüft werden.

Ein älteres Plugin oder Theme kann beispielsweise PHP-Code enthalten, der unter einer neueren PHP-Version nicht mehr funktioniert.

Umgekehrt können moderne Plugins Funktionen voraussetzen, die mit einer sehr alten PHP-Version nicht verfügbar sind.

Ändere PHP deshalb nicht wahllos zwischen verschiedenen Versionen hin und her.

Die sichere Vorgehensweise behandeln wir unter PHP-Version für WordPress ändern und Kompatibilität prüfen.

16. PHP Memory Limit als Ursache #

Wenn ein PHP-Prozess mehr Arbeitsspeicher benötigt als erlaubt, kann die Ausführung mit einem fatalen Fehler abbrechen.

Im Error Log erscheint dann häufig eine Meldung mit einem Bestandteil wie:

Allowed memory size ... exhausted

Ein solcher Fehler kann sich je nach Umgebung auch als HTTP 500 bemerkbar machen.

Das bedeutet allerdings nicht automatisch, dass das Speicherlimit einfach möglichst hoch gesetzt werden sollte.

Ein hoher Speicherverbrauch kann beispielsweise auf ein Plugin, eine aufwendige Operation oder einen Programmierfehler hinweisen.

Die genaue Diagnose behandeln wir unter PHP Memory Limit in WordPress: Fehler erkennen und beheben.

17. WP_MEMORY_LIMIT und PHP memory_limit unterscheiden #

Bei Speicherproblemen ist wichtig, verschiedene Grenzwerte nicht miteinander zu verwechseln.

PHP besitzt unter anderem die Einstellung:

memory_limit

WordPress kennt zusätzlich Konstanten wie:

WP_MEMORY_LIMIT

und für bestimmte administrative Prozesse:

WP_MAX_MEMORY_LIMIT

Ein in WordPress eingetragener Wert kann jedoch kein übergeordnetes serverseitiges Limit beliebig außer Kraft setzen.

Deshalb sollte zunächst festgestellt werden, welcher Grenzwert tatsächlich erreicht wurde.

18. Syntaxfehler in PHP-Code #

Ein einziger Syntaxfehler kann dazu führen, dass PHP eine Datei nicht mehr korrekt ausführen kann.

Das kann beispielsweise passieren, wenn unmittelbar zuvor Code in:

functions.php

wp-config.php

oder eine andere PHP-Datei eingefügt beziehungsweise verändert wurde.

Auch ein fehlerhaftes Code-Snippet kann einen fatalen Fehler verursachen.

Wenn der Fehler direkt nach einer manuellen Codeänderung auftritt, sollte diese Änderung zuerst geprüft und gegebenenfalls auf den vorherigen funktionierenden Stand zurückgesetzt werden.

19. Typische PHP-Fehler im Log #

Bei der Diagnose können verschiedene PHP-Fehlertypen auftreten.

Besonders relevant sind beispielsweise Meldungen wie:

PHP Fatal error

Uncaught Error

Call to undefined function

Class ... not found

Allowed memory size ... exhausted

Die genaue Meldung zusammen mit Dateipfad und Zeilennummer liefert wesentlich mehr Informationen als der allgemeine HTTP-500-Status.

20. Fehler nach WordPress-Update #

Tritt der Fehler unmittelbar nach einem WordPress-Core-Update auf, solltest du nicht automatisch davon ausgehen, dass WordPress selbst defekt ist.

Ein Update kann beispielsweise eine bestehende Inkompatibilität mit:

• einem älteren Plugin
• einem älteren Theme
• eigenem Code
• einer ungeeigneten PHP-Version

sichtbar machen.

Prüfe deshalb zuerst Error Logs und beteiligte Komponenten.

21. Unvollständiges WordPress-Update #

Wird ein Update unterbrochen, können Dateien unter Umständen nicht vollständig aktualisiert werden.

Dadurch kann eine inkonsistente Installation entstehen.

Bevor WordPress-Core-Dateien ersetzt werden, sollte jedoch geklärt werden, ob tatsächlich Hinweise auf fehlende oder beschädigte Core-Dateien vorliegen.

Besonders wichtig ist die Unterscheidung zwischen WordPress-Core und:

wp-content/

Dort befinden sich unter anderem Plugins, Themes und Uploads. Dieser Bereich darf bei einer Core-Reparatur nicht unüberlegt überschrieben werden.

22. Fehlerhafte oder fehlende Dateien #

Ein HTTP-500-Fehler kann auch auftreten, wenn benötigte PHP-Dateien fehlen, beschädigt oder nicht lesbar sind.

Mögliche Ursachen können beispielsweise sein:

• unterbrochener Upload
• fehlgeschlagenes Update
• manuelles Löschen
• unvollständige Migration
• fehlerhafte Wiederherstellung

Das Error Log enthält in solchen Fällen häufig Hinweise auf die betroffene Datei.

23. Dateiberechtigungen prüfen – aber nicht blind verändern #

Ungeeignete Datei- oder Verzeichnisberechtigungen können verhindern, dass der Webserver benötigte Dateien korrekt lesen oder ausführen kann.

Die konkrete Konfiguration hängt jedoch von der Hosting-Umgebung ab.

Achtung: Setze nicht pauschal alle Dateien oder Verzeichnisse auf weit offene Berechtigungen wie 777, nur um einen Fehler zu beseitigen. Das kann ein erhebliches Sicherheitsproblem erzeugen und ist keine fachgerechte Reparatur.

24. Besitzer und Berechtigungen sind nicht dasselbe #

Neben klassischen Dateiberechtigungen kann auf Serverebene auch relevant sein, welchem Benutzer beziehungsweise welcher Gruppe Dateien gehören.

Bei einer normalen WordPress-Verwaltung im Hosting sollte dies nicht wahllos manuell verändert werden.

Probleme können beispielsweise nach manuellen Servermigrationen oder Dateiübertragungen mit ungeeigneten Benutzerrechten auftreten.

25. PHP-Erweiterungen und Serverumgebung #

Plugins oder Themes können bestimmte PHP-Erweiterungen voraussetzen.

Fehlt eine benötigte Erweiterung, kann die Software je nach Programmierung mit einer verständlichen Meldung reagieren – oder mit einem PHP-Fehler abbrechen.

Das Error Log kann dann beispielsweise auf eine nicht vorhandene Funktion oder Klasse hinweisen.

Installiere oder aktiviere PHP-Erweiterungen nicht auf Verdacht. Prüfe zunächst die Anforderungen der betroffenen Software.

26. Fehler nur bei einer bestimmten Aktion #

Ein HTTP 500 muss nicht bei jedem Seitenaufruf auftreten.

Möglicherweise erscheint der Fehler nur bei:

• Speichern eines Beitrags
• Öffnen einer bestimmten Seite
• Import großer Datenmengen
• Export
• Erstellen eines Backups
• Ausführen eines bestimmten Plugins
• Absenden eines Formulars
• WooCommerce-Aktion

In diesem Fall ist die konkrete Aktion ein wichtiger Teil der Diagnose.

Reproduziere den Fehler nach Möglichkeit kontrolliert und prüfe unmittelbar danach die entsprechenden Logeinträge.

27. Fehler nur im WordPress-Adminbereich #

Wenn das Frontend funktioniert, aber bestimmte Bereiche unter:

/wp-admin/

einen HTTP-500-Fehler erzeugen, sollte untersucht werden, welche Komponenten speziell dort ausgeführt werden.

Ein Plugin kann beispielsweise ausschließlich bei administrativen Aktionen zusätzlichen Code laden.

Auch ein höherer Speicherbedarf bestimmter Backend-Prozesse kann eine Rolle spielen.

28. Fehler nur im Frontend #

Funktioniert der Adminbereich, aber das Frontend zeigt HTTP 500, können unter anderem Theme, Templates, Frontend-Plugins oder bestimmte Inhalte beteiligt sein.

Teste unterschiedliche Seiten und prüfe, ob der Fehler überall oder nur bei bestimmten Seitentypen auftritt.

29. Fehler nur auf einer einzelnen Seite #

Wenn fast die gesamte Website funktioniert und nur eine bestimmte URL einen HTTP-500-Fehler erzeugt, ist ein globaler Serverausfall eher unwahrscheinlich.

Untersuche dann insbesondere:

• Inhalt der Seite
• verwendete Blöcke
• Shortcodes
• Template
• Page Builder
• Formulare
• Plugins, die nur auf dieser Seite aktiv werden

Ein Blick ins Error Log unmittelbar nach dem Aufruf dieser URL ist besonders hilfreich.

30. Sehr lange Prozesse und Timeouts #

Eine aufwendige PHP-Anfrage kann technische Zeitlimits erreichen.

Das kann beispielsweise bei:

• grossen Importen
• Backups
• Bildverarbeitung
• umfangreichen Datenoperationen
• externen API-Abfragen

auftreten.

Bevor Ausführungszeiten einfach erhöht werden, sollte geprüft werden, warum der Prozess so lange benötigt.

31. Ressourcenlimits richtig einordnen #

Je nach Hosting-Umgebung stehen einer Website definierte Ressourcen zur Verfügung.

Das Erreichen eines Limits kann Anfragen beeinflussen. Ein Ressourcenlimit ist jedoch nicht automatisch die eigentliche Ursache.

Beispielsweise kann ein einzelnes fehlerhaftes Plugin ungewöhnlich viel CPU oder Arbeitsspeicher beanspruchen.

Die richtige Frage lautet deshalb nicht nur:

Welches Limit wurde erreicht?

sondern auch:

Warum wurde dieses Limit erreicht?

32. Cache verursacht normalerweise keinen PHP-Fatal-Error #

Cache-Systeme können eine zuvor erzeugte Fehlerseite zwischenspeichern oder nach einer Reparatur einen veralteten Zustand anzeigen.

Das Leeren des Caches kann deshalb nach einer Fehlerbehebung sinnvoll sein.

Es ersetzt aber keine Diagnose eines serverseitigen Fehlers.

Praxis-Tipp: Wenn das Error Log einen konkreten PHP Fatal Error nennt, konzentriere dich zunächst auf diesen Fehler. „Cache löschen“ ist keine Reparatur für fehlerhaften PHP-Code.

33. Security-Plugins und Serverregeln #

Sicherheitslösungen können Server- beziehungsweise Rewrite-Regeln verändern oder Zugriffe beeinflussen.

Wenn ein HTTP-500-Fehler unmittelbar nach einer Änderung an einer Sicherheitslösung auftritt, sollte auch diese Konfiguration geprüft werden.

Deaktiviere Sicherheitsmechanismen jedoch nicht pauschal und dauerhaft, ohne die Auswirkungen zu kennen.

34. Weiterleitungsregeln prüfen #

Fehlerhafte Regeln in .htaccess oder anderen Konfigurationsebenen können ebenfalls Probleme verursachen.

Besonders nach Migrationen solltest du prüfen, ob alte Regeln für:

• Domains
• Verzeichnisse
• HTTPS
• www beziehungsweise non-www
• Sicherheitsfunktionen

noch zur neuen Umgebung passen.

35. Fehler nach einer Website-Migration #

Wenn HTTP 500 unmittelbar nach einem Umzug auftritt, können zusätzliche Ursachen infrage kommen:

• andere PHP-Version
• andere PHP-Konfiguration
• inkompatible .htaccess-Regeln
• fehlende Dateien
• unvollständige Übertragung
• unterschiedliche Servermodule
• falsche Dateiberechtigungen

Vergleiche deshalb die alte und neue Umgebung, bevor du WordPress neu installierst.

36. WordPress nicht vorschnell neu installieren #

Eine Neuinstallation von WordPress ist bei einem HTTP-500-Fehler normalerweise nicht der erste sinnvolle Schritt.

Wenn beispielsweise ein Plugin einen Syntaxfehler verursacht, ändert eine Neuinstallation des WordPress-Core nichts an diesem Plugin.

Ebenso repariert eine Neuinstallation keine ungeeignete PHP-Version oder fehlerhafte individuelle Serverregel.

Diagnose sollte deshalb vor Neuinstallation kommen.

37. Backup nicht automatisch zurückspielen #

Auch ein vollständiger Restore ist nicht bei jedem Fehler 500 die beste erste Maßnahme.

Wenn das Error Log beispielsweise eindeutig ein einzelnes Plugin nennt, kann dessen Deaktivierung wesentlich zielgerichteter sein.

Bei dynamischen Websites kann ein Restore zudem neuere Daten überschreiben.

Ein Backup ist besonders wertvoll, wenn:

• Dateien beschädigt wurden
• eine Änderung nicht sauber rückgängig gemacht werden kann
• ein bekannter funktionierender Stand wiederhergestellt werden muss
• größere Änderungen an Dateien oder Datenbank vorgenommen wurden

38. Fehler 500 nach Backup-Restore #

Wenn der Fehler erst nach einer Wiederherstellung auftritt, sollte geprüft werden, ob:

• alle Dateien vollständig wiederhergestellt wurden
• Datenbank und Dateien zum selben Stand gehören
• die PHP-Version passt
• .htaccess zur aktuellen Serverumgebung passt
• Dateiberechtigungen korrekt sind

Ein Restore ist nur dann zuverlässig, wenn der wiederhergestellte Zustand technisch konsistent ist.

39. Fehlerprotokoll nach jeder Änderung erneut prüfen #

Wenn du eine vermutete Ursache behoben hast, rufe die betroffene URL erneut auf und prüfe anschließend das Log.

Dadurch kannst du feststellen:

• ob derselbe Fehler erneut auftritt
• ob ein neuer Fehler sichtbar wird
• ob die Anfrage jetzt erfolgreich verarbeitet wird

Bei komplexen Fehlerketten kann nach Behebung des ersten Fehlers ein zweiter sichtbar werden.

40. HTTP 500 und kritischer WordPress-Fehler #

Ein PHP-Fatal-Error kann sich sowohl als allgemeiner HTTP-500-Fehler als auch über WordPress‘ eigene Fehlerbehandlung bemerkbar machen.

Wenn WordPress ausdrücklich meldet, dass auf der Website ein kritischer Fehler aufgetreten ist, solltest du auch Recovery Mode und Administrator-E-Mail berücksichtigen.

Dafür haben wir die separate Anleitung WordPress zeigt eine weisse Seite oder einen kritischen Fehler: Was tun?.

41. Systematische Reihenfolge bei einem WordPress-Fehler 500 #

1. Genaue Fehlermeldung und betroffene URL notieren.
2. Prüfen, welche Bereiche der Website betroffen sind.
3. Feststellen, was unmittelbar vor dem Fehler geändert wurde.
4. Error Logs zum passenden Zeitpunkt kontrollieren.
5. Genannten Dateipfad und Fehlertyp auswerten.
6. Bei Bedarf WordPress-Debugging kontrolliert einsetzen.
7. Verdächtiges Plugin oder Theme gezielt prüfen.
8. .htaccess untersuchen, wenn Hinweise darauf bestehen.
9. PHP-Version kontrollieren.
10. Memory-Limit prüfen, wenn das Log eine Speicherüberschreitung zeigt.
11. Manuelle Codeänderungen kontrollieren.
12. Dateien und Berechtigungen nur bei konkretem Verdacht untersuchen.
13. Ursache gezielt beheben.
14. Betroffene Anfrage erneut testen.
15. Error Log nochmals kontrollieren.
16. Frontend und Adminbereich abschließend prüfen.

42. Was du bei einem Fehler 500 besser nicht tun solltest #

• WordPress nicht sofort neu installieren
• nicht wahllos alle Plugins löschen
• nicht gleichzeitig PHP, Theme und Plugins verändern
• .htaccess nicht ohne Sicherung überschreiben
• Dateiberechtigungen nicht pauschal auf 777 setzen
• Memory Limit nicht ohne Diagnose beliebig erhöhen
• keine zufälligen PHP-Erweiterungen aktivieren
• keinen alten Datenbankstand ohne Prüfung einspielen
• detaillierte Fehlermeldungen nicht dauerhaft öffentlich anzeigen
• Server- oder Sicherheitsregeln nicht blind aus fremden Anleitungen übernehmen

43. Welche Informationen helfen dem CURIAWEB-Support? #

Wenn deine WordPress-Website bei CURIAWEB einen HTTP-500-Fehler zeigt, helfen möglichst konkrete Angaben bei der Diagnose.

Teile insbesondere mit:

• betroffene Domain
• betroffene URL
• genaue Fehlermeldung
• ungefähren Zeitpunkt des Fehlers
• ob der Fehler dauerhaft oder sporadisch auftritt
• ob Frontend und Adminbereich betroffen sind
• welche Änderung unmittelbar davor vorgenommen wurde
• ob Plugin, Theme oder PHP kürzlich aktualisiert beziehungsweise geändert wurden
• relevanten Logeintrag, sofern vorhanden

Ein kurzer relevanter Logabschnitt mit Zeitstempel ist normalerweise hilfreicher als ein vollständiges Fehlerprotokoll mit tausenden älteren Einträgen.

Sende Passwörter nicht unaufgefordert mit.

Zusammenfassung #

Ein 500 Internal Server Error bedeutet, dass der Server eine Anfrage aufgrund eines internen Fehlers nicht erfolgreich verarbeiten konnte. Der Statuscode selbst sagt noch nicht, welche WordPress-Komponente dafür verantwortlich ist.

Bei WordPress gehören PHP-Fehler, Plugins, Themes, .htaccess, inkompatible PHP-Versionen, Speicherprobleme und fehlerhafte Dateien zu den möglichen Ursachen.

Der wichtigste Diagnoseschritt ist deshalb die Auswertung des passenden Error Logs. Fehlertyp, Dateipfad, Zeilennummer und Zeitpunkt liefern häufig wesentlich konkretere Hinweise als die sichtbare 500-Fehlerseite.

Ändere anschließend nur die Komponente, für die ein konkreter Verdacht besteht, und teste nach jeder Änderung erneut. Eine systematische Diagnose ist zuverlässiger und sicherer als WordPress neu zu installieren, sämtliche Plugins zu deaktivieren oder Servereinstellungen auf Verdacht zu verändern.