Fixing a 500 Internal Server Error

A 500 Internal Server Error is among the most common server-side website errors. The message means that the web server received a request but could not process it successfully due to an internal error.

The status code 500 without yet naming the actual cause. Frequently, PHP errors, a faulty .htaccess, incompatible plugins or themes, incorrect PHP settings, or file and permission issues behind it.

In this guide, we will show you how to fix a 500 Internal Server Error in CURIAWEB web hosting systematically diagnose and find the actual cause.

Important: A 500 error is a generic catch-all message. Therefore, do not randomly change the PHP version, file permissions, plugins, and .htaccess simultaneously. The fastest way to a solution usually leads through the exact time of the error and the error log.

What does 500 Internal Server Error mean? #

Simplified, a request works as follows:

Browser sends request
        ↓
Web server receives request
        ↓
Server-side processing fails
        ↓
500 Internal Server Error

In doing so, the browser usually does not know which internal error occurred on the server. Therefore, only the general HTTP status code is used. 500 displayed.

What can a 500 error look like? #

Depending on the web server, application, and browser, the visible message may be phrased differently.

Examples are:

500 Internal Server Error

Internal Server Error

HTTP ERROR 500

The server encountered an internal error
and was unable to complete your request.

What matters is not the exact phrasing, but that the request with the HTTP status code 500 fails.

differentiate between 500, 403, 404, and 503 #

Status	Simply put, he
403 Forbidden	Access denied
404 Not Found	Resource not found
500 Internal Server Error	Internal server-side processing failed
503 Service Unavailable	Service temporarily unable to process the request

If a 403 is actually displayed, use our guide instead Fix 403 Forbidden.

First, narrow down the symptom. #

Before you change anything, check when and where the error occurs.

For example, determine:

• Is the entire website affected?
• Just a single page?
• Only the WordPress admin area?
• Just a specific action?
• Just a PHP script?
• Just an import or export?
• Did the error occur immediately after a change?
• Is the error permanent or just sporadic?

This information helps to significantly narrow down troubleshooting.

1. Note date, time, and affected URL #

Note as precisely as possible when the error occurs.

Example:

28.08.2026
3:42 PM
https://example.ch/wp-admin/
500 Internal Server Error

If the error only occurs during a specific action, note that as well.

For example:

WordPress works
→ Update plugin
→ 500 Internal Server Error

The exact time is important so that you can then find the corresponding entry in the error log.

2. Check cPanel Error Log #

Open in CURIAWEB-cPanel:

Measured values → Errors

Search for entries that coincide in time with the 500 error.

The error log is one of the most important diagnostic points in the event of a 500 Internal Server Error.

We explain in detail how to read the messages correctly at Read cPanel Error Log and find website errors.

Practical Tip: If the error is reproducible, note the current time, access the faulty page once, and then check the error log directly. This often makes it easier to identify the relevant entry.

The exact error message is more important than „Error 500“ #

The visible 500 error is merely the symptom.

An error log entry, on the other hand, might contain hints such as:

PHP Fatal error

Allowed memory size exhausted

Call to undefined function

Class not found

Permission denied

.htaccess configuration error

This information brings us much closer to the actual cause.

3. Check recent changes #

If a website used to work, the most important question is often:

What was changed immediately before the first 500 error?

Check, for example:

• Plugin installed or updated
• Theme updated
• WordPress is updating
• PHP version changed
• .htaccess edited
• PHP settings changed
• Files uploaded or replaced
• Website migrated
• modified custom PHP code
• set up new cron job

A close temporal relationship is an important diagnostic indicator.

4. Check .htaccess #

A faulty Apache directive in a .htaccessfile can cause a 500 Internal Server Error.

This is particularly likely if the error began immediately after a manual change to this file.

The .htaccess is frequently located in the document root of the website.

If it is not visible in the file manager, read first Show hidden files like .htaccess in cPanel.

.Do not simply delete the .htaccess file #

The file may contain important rules, for example for:

• WordPress permalinks
• Redirects
• Access protection
• individual server instructions

Therefore, create a backup copy first.

We explain how to make changes in a controlled manner at .htaccess explained and safely edited.

Undo last inserted .htaccess rule #

If the procedure is clear:

Website working
        ↓
.htaccess changed
        ↓
500 Internal Server Error

you should first undo this exact change.

Do not randomly remove all existing rules.

.Rename .htaccess for testing purposes #

If you strongly suspect .htaccess have, but cannot recognize which rule is faulty, you can temporarily rename the file after making a backup beforehand.

For example:

.htaccess
→
.htaccess-test

Then open the website again.

If the 500 error disappears, the cause is very likely within the previous .htaccess-Configuration available.

Important: Renaming is a diagnostic step and not a final solution. Features such as WordPress permalinks or redirects may temporarily stop working correctly as a result.

5. Check PHP version #

A 500 error can occur if a website is not compatible with the PHP version being used.

This is particularly relevant if the error occurred immediately after a PHP version change.

In CURIAWEB, you generally manage a domain's PHP version via:

Software → MultiPHP Manager

You can find the complete instructions at Change PHP version in cPanel.

Do not change the PHP version randomly #

Do not test random PHP versions one after another in the hope that one of them will work.

Check first:

• which PHP version is currently being used
• which version worked before
• which version the application supports
• whether plugins and themes are compatible with it

If the error started immediately after a PHP change, a controlled switch back to the previously working and still suitable version can be a useful test.

6. Check for PHP Fatal Errors #

A PHP fatal error can cause a request not to be successfully completed.

Typical messages can begin like this, for example:

PHP Fatal error:

The rest of the message text is crucial for the diagnosis.

For example, he can:

• a specific PHP file
• a WordPress plugin
• a theme
• a missing function
• a missing class
• a memory error

point out.

Read path in the error message #

If the message contains a file path, it can provide an important clue about the causing component.

Example:

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

indicates that code within this plugin directory is involved in the error.

This does not automatically prove that the entire plugin is faulty, but it narrows down the investigation considerably.

7. Checking for missing PHP extensions #

After a PHP version change or migration, an application may expect a PHP extension that is not available in the PHP environment being used.

Typical notices include, for example:

Call to undefined function ...

Class ... not found

requires ext-...

We explain how to investigate such cases under Enabling and Managing PHP Extensions in cPanel.

Consider PHP extensions and PHP version together #

PHP extensions are version-dependent.

Therefore, if an error begins immediately after changing the PHP version, you should not only look at the version number, but also check whether the application finds all required functions in this PHP environment.

8. Check PHP Memory Limit #

If the error log contains the following message, for example:

Allowed memory size of ... bytes exhausted

does a PHP process have its configured memory_limit reached.

This is a specific clue and should not be confused with the CloudLinux Physical Memory.

We explain how to check PHP limits and set them appropriately at Set PHP memory limit, upload size, and execution time.

Do not increase the memory limit arbitrarily #

If an application requires an unusual amount of memory, a higher limit may merely postpone the symptom without eliminating the root cause.

Therefore, also check:

• which process requires the memory
• whether the need for the task in question is plausible
• whether a plugin or script is working incorrectly

9. Check further PHP settings #

If the error started after changes to the PHP configuration, check the most recently modified values.

For CURIAWEB, you generally use the:

Software → MultiPHP INI Editor

You can find our instructions at Change PHP settings in cPanel.

Do not change PHP values blindly. Use the error message and the application's requirements as a basis.

10. Check file permissions #

Inappropriate file or directory permissions can also cause server-side issues.

Open:

Files → File Manager

Check in particular files and directories that were modified, uploaded, or extracted immediately before the error.

Typical websites often use the following values:

Files:       644
Directories: 755

You can find the exact procedure at How to correctly set file permissions 644 and 755 in cPanel.

Attention: Do not set permissions globally to 777. This is not a clean solution for a 500 error and can cause security issues.

11. Check files after migration or upload #

If the error started after a migration or a manual upload, check:

• whether all files were transferred
• whether the files are in the correct document root
• whether archives have been completely extracted
• whether configuration files exist
• whether permissions are plausible
• whether the PHP version matches the application

An incompletely transferred plugin, theme, or framework can also cause server-side errors.

12. Check Document Root #

If you might be examining files in the wrong directory, check under:

Domains → Domains

the document root of the affected domain.

You can find our instructions for this at Add and manage a domain in cPanel.

13. Inspect WordPress plugins #

In WordPress, plugins are among the most common application components that can be involved in a 500 error.

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

• Installation
• Activation
• Update
• Configuration change

this plugin has started.

Check the error log first. Does the error message contain a path within:

/wp-content/plugins/

Can you focus the investigation on the extension in question.

Disable WordPress plugin when wp-admin is inaccessible #

If a faulty plugin makes the WordPress admin area inaccessible, it may be necessary to deactivate the extension outside of the WordPress backend.

You can find the appropriate instructions at Deactivate or delete WordPress plugin.

Do not disable all plugins at once if the cause is known #

If the error log clearly points to a specific extension, you should first examine that exact component.

A complete deactivation of all plugins is rather a diagnostic step if the cause cannot be narrowed down.

14. Inspect WordPress theme #

A theme can also contain PHP code that causes a fatal error.

If the error log contains a path like:

/wp-content/themes/mein-theme/

shows, the theme component in question should be examined.

This is especially true if the error started immediately after a theme update or a code change.

Systematically check for plugin and theme conflicts #

If the cause is not clear, use the instructions Identify and resolve WordPress plugin and theme conflicts.

Proceed in a controlled manner and document every change.

15. Use WordPress debugging #

If the normal error log does not provide enough information, targeted debugging or logging can be helpful in WordPress.

WordPress can cause errors, for example, in:

wp-content/debug.log

log if debugging has been configured accordingly.

We explain how to set this up securely at Using WordPress debugging and error logs.

Important: Do not permanently enable detailed error output for visitors on a production website. Error messages can expose technical details and internal paths.

16. Address critical WordPress error #

WordPress can also display its own message about a critical error instead of a classic 500 error in the event of certain PHP fatal errors.

Both error patterns can have the same technical cause.

When WordPress displays the message:

There has been a critical error on your website.

displays, additionally use Fix WordPress critical error or white screen.

17. Error on a single page only #

If the homepage works, but a single URL generates a 500 error, you should focus your diagnosis on that request.

Possible causes include, for example:

• specific plugin
• custom PHP code
• corrupted data
• specific database query
• Rewrite rule
• memory-intensive function

Do not change the entire hosting configuration if the error occurs only in a single function.

18. Error only in the WordPress admin area #

If the public website works, but /wp-admin/ generated a 500 error, a general DNS or domain issue is unlikely.

Check especially:

• Error Log
• Plugins
• Theme or individual code
• PHP version
• PHP Memory Limit
• recent updates

19. Error only when saving or updating #

When WordPress loads normally, but saving a post fails with a 500 error, for example, the server-side processing of this exact action must be investigated.

Reproduce the error once and check the error log immediately afterward.

Such an error pattern can be related, for example, to a plugin, PHP code, or resource-intensive processing.

20. Error during uploads #

If the 500 error only occurs when uploading larger files, also check the PHP limits.

For example, relevant factors may include:

upload_max_filesize
post_max_size
memory_limit
max_execution_time

Note that these values have different tasks and should not be increased arbitrarily.

21. Error in imports #

If only a large import with 500 fails while the rest of the website works, you should investigate the import processing.

Check in particular:

• Error Log
• PHP Memory Limit
• Execution time
• PHP compatibility
• Import size
• Error of the import application used

If possible, an application can support smaller processing batches. Which setting makes sense depends on the import tool used.

22. Error in cron jobs #

A PHP script can fail in a cron job even though the website generally works in the browser.

If the error occurs in connection with a scheduled process, check:

• Cron job command
• PHP path or PHP version
• File path
• Permissions
• Error message

You can find the detailed diagnosis under Cron job not working: Causes and solutions.

23. Check CloudLinux resources #

If the 500 error occurs only sporadically or under load, you should also check the CloudLinux resource usage at the same time.

Open:

Metrics → Resource Usage

Check if a resource limit was reached at the time of the error.

We explain how to interpret the values at Understanding CloudLinux Resource Usage in cPanel.

500 and Resource Limit Is Reached are not the same #

A CloudLinux limit and an HTTP 500 error are different things.

However, a resource bottleneck can affect the processing of an application. Therefore, a temporal comparison is useful in the case of sporadic errors.

If expressly 508 Resource Limit Is Reached is displayed, use our guide Resource Limit Is Reached: Identify and Fix CloudLinux Limits.

24. Check storage space #

A fully occupied hosting account can impair various applications and write operations.

If the error occurs during updates, cache creation, uploads, or other write operations, for example, also check the available storage space.

You can find the procedure under Check disk space and bandwidth in cPanel.

25. Consider database errors #

An application can generate a 500 error if server-side code fails during a database operation.

However, that does not mean you should immediately repair or modify tables in phpMyAdmin.

First, check the specific error message.

If a database issue is mentioned, note:

• exact error message
• affected table, if specified
• affected application
• Time

Do not edit the database on suspicion #

Do not delete or modify any tables just because a 500 error occurs.

A bug in application code can just as easily cause the database query.

You can find the basics of database management under Use phpMyAdmin in cPanel.

26. Error after website migration #

If a website generates a 500 error immediately after a migration, you should check the following points in particular:

• PHP version
• required PHP extensions
• PHP settings
• .htaccess
• File permissions
• complete file transfer
• Database connection
• application-specific paths and configurations

Do not try to change all points at once. The error log should guide the diagnosis here as well.

27. Error after PHP switch #

If the chronological sequence is:

Website works
        ↓
PHP version changed
        ↓
500 Internal Server Error

check first:

• Application compatibility
• Plugins and Themes
• required PHP extensions
• Error Log

Reverting to the previously working and still supported version can be useful as a controlled test.

28. Error after plugin update #

If a 500 error starts immediately after a plugin update, check the error log first for a corresponding plugin path.

If the extension is indeed involved, the following steps may be useful depending on the situation:

• Deactivate plugin
• Check compatibility
• Correct the update or cleanly reinstall it.
• Check manufacturer instructions

Do not downgrade to an insecure or known buggy version without assessing the impact.

29. Error after theme update #

The same applies to themes.

If the error log shows:

/wp-content/themes/...

If the error is related to this component and began immediately after a theme update, focus your troubleshooting on this component.

30. Error after editing functions.php #

Even a single syntax or programming error in custom PHP code within a theme file can cause execution to stop.

If the error occurs immediately after a change to:

functions.php

If this occurs, first restore the previously working version of this change.

Do not edit production PHP code without a backup.

31. Error after code snippet #

The same principle applies to PHP code inserted manually using a snippet plugin.

If:

Snippet activated
        ↓
500 Internal Server Error

This snippet is an obvious starting point for the diagnosis.

Check the error log and specifically disable the relevant code, provided this can be done safely.

32. Error after extracting an archive #

If a website returns a 500 error after uploading and extracting a ZIP archive, check the following:

• whether the archive has been completely extracted
• whether files are in the correct directory
• File permissions
• .htaccess
• PHP compatibility
• Configuration files

We explain how to process archives correctly at Compress and extract ZIP files in cPanel.

33,500 only occasionally #

A sporadic 500 error is harder to diagnose than a consistently reproducible error.

Therefore, note down every known time and compare:

Time of the 500 error
        ↓
Error Log
        ↓
CloudLinux Resources
        ↓
Cron Jobs / Background Tasks
        ↓
Traffic / Unusual Activity

Recurring time patterns can be particularly helpful.

34,500, always at the same time #

If the error occurs regularly at about the same time, check for scheduled processes.

This may include, for example:

• Cron jobs
• Import
• Export
• Synchronizations
• Backup plugins
• WordPress background tasks

The recurring timing is a strong diagnostic clue.

35,500 only under heavy load #

If the error occurs only during periods of high load, also check CloudLinux and the type of requests.

High traffic alone does not necessarily prove that the hosting package is the cause.

Slow PHP processes, inefficient database queries, or a lack of caching can also cause requests to back up more significantly under heavy load.

36. Check Caching #

In WordPress, suitable caching can reduce dynamic processing.

To this end, CURIAWEB provides AccelerateWP in the hosting environment.

We explain how to use it at AccelerateWP in cPanel explained.

However, caching is not a fix for a PHP fatal error or a faulty .htaccess.

37. Do not install multiple cache systems as a troubleshooting measure #

A 500 error should not be addressed by installing additional performance plugins.

This can actually make the technical situation even more complicated.

First find the cause of the error.

38. The browser cache is rarely the cause of a true 500 error #

An HTTP 500 is generated on the server side.

A private browser window can still be helpful for testing, but it doesn't change the underlying server cause.

If the web server continues to return 500, the server-side processing must be investigated.

39. DNS is usually not the cause of a 500 #

If you are already receiving an HTTP 500 from a web server, a server has basically been reached.

A classic DNS outage manifests itself differently.

However, following DNS changes, a domain may accidentally point to a different server. Therefore, in the event of a recent migration, check whether you are actually reaching the expected hosting environment.

40. Differentiating between SSL errors and HTTP 500 #

A certificate error is also a different error class.

When the browser receives a real HTTP status code 500, the connection has already been established far enough for the web server to send an HTTP response.

Therefore, do not replace SSL certificates on suspicion.

41. Do not permanently expose 500 errors through display_errors #

It can be tempting to have PHP errors displayed directly on the public website.

On a production website, this is not a good permanent solution because error messages can expose internal information such as file paths or technical details.

Prefer to use error logs for diagnosis.

42. Reproduce the error again after the change #

After each targeted correction, you should retest the exact same URL or action.

A logical sequence is:

Reproduce error
↓
Check logs
↓
Change one cause
↓
Test same action again
↓
Compare result

This allows you to determine whether your change was actually relevant.

43. Do not change five things at once #

If you simultaneously:

you change PHP
delete the .htaccess
disable plugins
change permissions
clear cache

and the website works again afterwards, you don't know what the cause was.

This makes subsequent errors significantly more difficult.

Basic rule: In the event of a 500 Internal Server Error, the error log should provide the diagnosis. A specific error message is more valuable than ten changes made on a hunch.

Systematically diagnosing a 500 Internal Server Error #

1. Note the affected URL, date, and time.
2. Check whether the entire website or only a specific action is affected.
3. Open Measured values → Errors.
4. Find the chronologically matching error log entry.
5. Check the latest changes.
6. Examine the, with an appropriate indication, .htaccess.
7. Check PHP version and application compatibility.
8. Check reported PHP fatal errors.
9. Check any required PHP extensions.
10. In case of memory errors, check the PHP memory limit.
11. Check relevant file and directory permissions.
12. Check the plugin or theme path mentioned in the log in WordPress.
13. Check the CloudLinux resources for sporadic errors.
14. Take cron jobs and background tasks into account.
15. Change only one possible cause at a time.
16. Then test the exact same action again.

Quick diagnosis after error message #

Note	First checkpoint
PHP Fatal error	check the specified PHP path or component
Allowed memory size exhausted	Check PHP memory limit and causing process
Call to undefined function	Check PHP compatibility or extension
Class not found	Check application, autoloading, or required extension
Error immediately after .htaccess-Modification	check last modified rule
Error immediately after PHP change	Check PHP compatibility and extensions
Error right after plugin update	Check the error log and the relevant plugin
Error only under load	Check CloudLinux resources and application
Errors regularly at the same time	Check cron jobs and background tasks

What you should not do in the event of a 500 error #

Avoid in particular:

• File permissions across the board to 777 put
• .htaccess delete without backup
• Switch PHP versions randomly
• Extremely increase PHP memory limit
• delete all plugins without diagnostics
• modifying database tables on suspicion
• install multiple caching plugins
• Changing DNS or SSL without appropriate notice
• perform multiple technical changes simultaneously

When should you contact CURIAWEB support? #

If the 500 Internal Server Error persists or the cause is not clear from the error log, document the problem as accurately as possible.

Particularly helpful are:

• affected domain
• full affected URL
• Date and exact time
• visible error message
• relevant error log entry
• whether the entire website or only a specific action is affected
• recent changes
• currently used PHP version
• whether the error occurs permanently or sporadically
• in case of sporadic errors, check for conspicuous CloudLinux metrics if necessary

If the error is reproducible, also describe the exact steps that can be used to trigger it.

Summary #

A 500 Internal Server Error means that a server-side request could not be successfully processed. The status code itself does not yet name the actual cause.

Therefore, the most important first diagnostic point is the cPanel Error Log under Measured values → Errors. Compare the entry there with the exact time of the error.

Common causes are PHP fatal errors, faulty .htaccess-rules, incompatible plugins or themes, unsuitable PHP versions, missing PHP extensions, reached PHP limits, or problems after a migration or file change.

For sporadic errors, you should also investigate CloudLinux resource usage, cron jobs, and background tasks at the same time.

Do not change multiple components at the same time. Reproduce the error, check the log, formulate a specific cause, and then test exactly one targeted change.

The most important rule is: „500 Internal Server Error is not the diagnosis – the actual diagnosis begins with the error message in the log.