Fixing Error 500 in WordPress: Finding Causes and Solving Systematically

A 500 Internal Server Error is one of the more unpleasant WordPress errors because the message initially reveals very little about the actual cause. The web server received the request, but could not successfully process it due to an internal problem.

For a WordPress website, among other things, PHP errors, plugins, themes, faulty rules in .htaccess, an exhausted storage limit, or problems after a modification or update may be involved.

It is therefore important not to confuse the HTTP 500 status with the actual cause of the error.

Briefly explained: A 500 error does not automatically mean that WordPress is broken. First, check when and where the error occurs. Then, check the error logs and the changes made immediately before. Only based on this information should you [check/handle] plugins, theme, PHP, .htaccess or investigate other components in a targeted manner.

What does HTTP 500 Internal Server Error mean? #

HTTP status codes describe the result of a request between client and server.

A status code from the 5xx group indicates a server-side error. In 500 Internal Server Error the server could not complete the request as intended due to an internal error.

Thus, the report initially describes only the result – not its specific cause.

For example, the following areas can be involved in WordPress:

• PHP
• WordPress Core
• Plugins
• Themes or child themes
• .htaccess or rewrite rules
• PHP memory limit
• Files and file permissions
• Server configuration

What does a 500 error look like? #

Depending on the browser, web server, and hosting environment, the visible message may vary.

Typical designations include, for example:

500 Internal Server Error

or simply:

HTTP ERROR 500

Sometimes, instead of an explicit 500 page, a largely blank page or another generic error message appears.

Therefore, it is helpful to consider the actual HTTP status and existing server logs.

1. Check if an HTTP 500 error is actually present #

Before you modify WordPress, you should determine the error pattern as precisely as possible.

An HTTP 500 is something different than:

• 404 Not Found
• 403 Forbidden
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout
• DNS error
• SSL certificate error
• Error establishing a database connection

If the website cannot be reached at all fundamentally, you should first perform the broader diagnosis under WordPress website not accessible: systematically check causes use.

2. Which areas of the website are affected? #

Do not test only the home page.

For example, access the following areas:

https://deine-domain.ch

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

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

This allows the error to be narrowed down further.

Possible situations are:

• Entire website shows error 500
• only the admin area shows error 500
• only the frontend is affected
• only a single page is affected
• Error only occurs with a specific action
• Error occurs only sporadically

An error that occurs exclusively when submitting a specific form, for example, has a different starting point than a website that responds with HTTP 500 on every request.

3. What was changed immediately before the error? #

The temporal relationship is one of the most important clues when troubleshooting.

Consider whether immediately before the occurrence of the error, for example:

• WordPress has been updated
• a plugin was installed
• a plugin was activated
• a plugin was updated
• a theme has been updated
• the theme was changed
• PHP has been changed
• .htaccess has been edited
• wp-config.php has been changed
• PHP code was inserted
• a code snippet was activated

If the error started immediately after a specific change, you should start diagnosing there.

Practical Tip: During troubleshooting, try to change only one component at a time whenever possible. Otherwise, the website might suddenly start working again, but the actual cause will remain unknown.

4. Check error logs #

In the case of an HTTP 500 error, server or PHP error logs are often much more helpful than the visible browser message.

An error log may contain indications of, for example:

• PHP Fatal Error
• Syntax error
• non-existent functions or classes
• Out of memory
• Plugin files
• Theme files
• Problems with PHP extensions
• File or path issues

Above all, entries whose timestamps match the occurrence of the error are crucial.

For example, if the error was triggered at 2:32 PM, old warnings from several days prior are usually not the first starting point.

5. Evaluate file path in error log #

The file path mentioned in a PHP error message can provide an important clue.

A path like:

wp-content/plugins/sample-plugin/...

indicates that code from a plugin is involved in the error.

A path like:

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

leads in contrast toward the theme or child theme.

However, a file path is not always complete proof of the actual root cause. A component can trigger an error that only becomes visible when calling code from another component.

6. Use WordPress debugging #

When existing server logs are not sufficient, WordPress debugging features can provide additional information.

Important constants are:

WP_DEBUG

WP_DEBUG_LOG

WP_DEBUG_DISPLAY

With the appropriate configuration, WordPress can output error messages, for example, in:

wp-content/debug.log

log.

How you can use debugging in a controlled manner on a live website and read logs correctly is covered in detail at Enable WordPress debugging and use error logs.

Attention: Detailed PHP error messages should not be permanently displayed publicly on a production website. Error logs can contain internal paths and further technical information.

7. Check for a plugin as the cause of a 500 error #

Plugins are among the potential causes of an HTTP 500 error in WordPress.

A plugin is particularly suspicious if the error occurs immediately after:

• Installation
• Activation
• Update
• Modification of its configuration

begun.

If the WordPress admin area is still accessible, first deactivate the plugin in question and test the faulty request again.

If the error disappears, it should subsequently be clarified why the plugin caused the problem.

8. Disable plugin when admin area is inaccessible #

If a plugin causes the error and the WordPress admin area also no longer works, the plugin in question can be deactivated via file access if you have the appropriate experience.

Plugins are usually located under:

wp-content/plugins/

An example plugin directory could be:

wp-content/plugins/beispiel-plugin/

If this directory is temporarily renamed, WordPress will no longer be able to load the plugin under its previous path.

This method should be used selectively when the affected plugin is known or at least strongly suspected.

9. If no specific plugin is known #

If no specific plugin is known as the cause, a systematic conflict check may be necessary.

This involves systematically disabling plugins and then gradually re-enabling them until the error can be reproduced.

The goal is not simply to somehow get the website running without plugins. The crucial thing is to identify the component or combination actually involved.

You can find the detailed procedure under Identifying and Resolving Plugin or Theme Conflicts in WordPress.

10. Check theme as a cause #

The active theme can also contain PHP code that triggers an HTTP 500 error.

This is particularly relevant if the error occurs after:

• a theme update
• a theme change
• a modification of the child theme
• to a change in functions.php

occurred.

If the admin area is accessible, a suitable current WordPress default theme can be temporarily activated for diagnosis.

If the website works again as a result, the previously active theme should be examined in more detail.

11. Manually investigate topics #

If the admin area is not accessible, the theme files are usually located under:

wp-content/themes/

The directory of the active theme can be temporarily renamed for targeted diagnostics.

However, for WordPress to be able to fall back on a different theme afterwards, a suitable alternative theme must be installed.

Important: A theme change can significantly alter the appearance and certain functions of the website. In this case, it serves diagnostic purposes and should not be confused with a final design decision.

12. .htaccess as a possible cause #

On Apache-based or compatible web server configurations, WordPress can use the file:

.htaccess

for rewrite rules and further configurations.

Faulty directives or rules can cause an HTTP 500 error under certain conditions.

This can happen, for example, after:

• manual processing
• Changes made by a plugin
• Insertion of inappropriate server rules
• Migration between different server environments

occur.

13. Do not simply delete .htaccess #

If .htaccess if suspected to be the cause, you should back up the existing file first.

One possible diagnosis is to temporarily rename it, for example to:

.htaccess-backup

and then test the website again.

If the website works again afterwards, this is a strong indication that a rule in the previous file was involved.

Attention: A .htaccess- File may contain security rules, redirects or other custom configurations besides WordPress permalinks. Therefore, do not overwrite it without checking.

14. Regenerate WordPress permalink rules #

When the admin area is accessible again and a standard WordPress permalink configuration is used, the rewrite rules can be [reset/flushed] via:

Settings → Permalinks

be rewritten by saving the settings.

This is particularly relevant for permalink and rewrite issues.

If your actual error pattern concerns HTTP 404, you can find the detailed procedure under Fix 404 error in WordPress and repair permalinks.

15. Error after a PHP version change #

If the HTTP 500 error occurred immediately after changing the PHP version, the compatibility of the WordPress components should be checked.

For example, an older plugin or theme may contain PHP code that no longer works with a newer PHP version.

Conversely, modern plugins may require features that are not available with a very old PHP version.

Therefore, do not randomly switch PHP back and forth between different versions.

We cover the safe procedure under Change PHP version for WordPress and check compatibility.

16. PHP Memory Limit as the cause #

If a PHP process requires more memory than allowed, the execution can fail with a fatal error.

An error log frequently contains a message with a component such as:

Allowed memory size ... exhausted

Depending on the environment, such an error can also manifest as an HTTP 500.

However, that does not automatically mean that the memory limit should simply be set as high as possible.

High memory consumption can indicate, for example, a plugin, a complex operation, or a programming error.

We discuss the exact diagnosis under PHP Memory Limit in WordPress: Identify and fix errors.

17. Differentiate between WP_MEMORY_LIMIT and PHP memory_limit #

In the event of memory issues, it is important not to confuse various limit values with one another.

PHP has, among other things, the setting:

memory_limit

WordPress also knows constants such as:

WP_MEMORY_LIMIT

and for certain administrative processes:

WP_MAX_MEMORY_LIMIT

However, a value entered in WordPress cannot arbitrarily override a higher-level server-side limit.

Therefore, it should first be determined which limit value was actually reached.

18. Syntax error in PHP code #

A single syntax error can cause PHP to no longer execute a file correctly.

This can happen, for example, if immediately before, code in:

functions.php

wp-config.php

or another PHP file was inserted or modified.

Even a faulty code snippet can cause a fatal error.

If the error occurs immediately after a manual code change, this change should be checked first and, if necessary, reverted to the previous working state.

19. Typical PHP errors in the log #

During diagnosis, various types of PHP errors can occur.

Particularly relevant, for example, are reports such as:

PHP Fatal error

Uncaught Error

Call to undefined function

Class ... not found

Allowed memory size ... exhausted

The exact message along with the file path and line number provides significantly more information than the general HTTP 500 status.

20. Error after WordPress update #

If the error occurs immediately after a WordPress core update, you shouldn't automatically assume that WordPress itself is faulty.

An update can, for example, resolve an existing incompatibility with:

• an older plugin
• an older theme
• custom code
• an unsuitable PHP version

make visible.

Therefore, check error logs and involved components first.

21. Incomplete WordPress Update #

If an update is interrupted, files may not be completely updated under certain circumstances.

This can result in an inconsistent installation.

However, before replacing WordPress core files, you should check whether there are actually any signs of missing or damaged core files.

The distinction between WordPress Core and the following is particularly important:

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.

Possible causes can include, for example:

• 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.

Attention: 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
• Forms
• 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
• Image processing
• umfangreichen Datenoperationen
• externen API-Abfragen

occur.

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.

Practical Tip: 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
• Safety features

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
• missing files
• 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 shows a white screen or a critical error: What to do?.

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. Fix the root cause specifically.
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 put
• 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:

• affected domain
• betroffene URL
• exact error message
• ungefähren Zeitpunkt des Fehlers
• whether the error occurs permanently or sporadically
• whether the frontend and admin area are affected
• 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.

Do not send passwords unsolicited.

Summary #

A 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.