Kualo / docs
On this page

How to fix a 500 Internal Server Error on your website

Learn how to systematically diagnose and fix a 500 Internal Server Error on your Kualo hosting account without raising a support ticket.

8 min read Updated 8 Jun 2026

A 500 Internal Server Error means the server hit an unexpected condition and could not complete your request. The good news is that the cause is almost always something you can fix yourself by working through the checks below.

What a 500 error actually means

The 500 status code is deliberately vague - the server knows something went wrong but does not tell the browser what. The real cause is always recorded in your error logs, not shown on screen. Common triggers include a broken .htaccess file, wrong file permissions, a PHP fatal error, or hitting a resource limit. In almost every case you can resolve it without contacting our support team.

Before making any changes, create a backup of your account so you have a restore point if something goes wrong.

Step 1 - Check your error logs first

The error log is always your starting point. It tells you exactly which file caused the problem and often gives you a line number.

Finding the error log in cPanel

  1. Log in to cPanel.
  2. Go to Metrics and click Errors. [Placeholder: confirm the exact section label and tool name for the Error Log viewer in the current cPanel theme.]
  3. The page shows the most recent log entries. The last few lines are almost always the ones you need.

Accessing raw log files

Raw log files are also available via File Manager or FTP. On Kualo shared hosting, look for your error log at:

~/logs/

or, for some configurations:

~/public_html/error_log

[Placeholder: confirm the exact default error log path on Kualo shared hosting servers.]

If you have SSH access, you can watch the log in real time as you reproduce the error:

tail -f ~/logs/error_log

If the log is empty, PHP error logging may not be enabled yet. Enable it first (see the PHP errors section below), then reproduce the error and check again.

Once you have an error message, note the file path and line number mentioned and move on to the relevant cause below.

Step 2 - Fix .htaccess syntax errors

A broken .htaccess file is one of the most common causes of a 500 error, especially after installing a plugin or editing the file manually.

Testing whether .htaccess is the cause

  1. Open File Manager in cPanel and navigate to your website's root folder (usually public_html).
  2. Right-click .htaccess and rename it to .htaccess_old.
  3. Reload your website in a browser.

If the error clears, the .htaccess file was the problem. If the error persists, rename the file back and move on to the next cause.

Fixing the .htaccess file

  • Remove any rules you added recently and test again after each removal.
  • Check for typos, unclosed tags, or directives that are not supported on shared hosting.
  • If you are using WordPress, you can regenerate a clean .htaccess by going to Settings > Permalinks in your WordPress dashboard and clicking Save Changes without changing anything.
  • Plugins such as Yoast SEO and WooCommerce also write to .htaccess - deactivating a recently installed plugin and regenerating the file can resolve conflicts.

Remember that .htaccess files can exist in subdirectories as well as the web root. If the error only affects a specific path, check for a .htaccess file in that subdirectory too.

For a deeper look at .htaccess problems, see our guide to troubleshooting .htaccess issues.

Step 3 - Correct file and directory permissions

Incorrect permissions are another frequent cause. The correct permissions for most shared hosting files and directories are:

  • Files: 644
  • Directories: 755

Permissions set too loosely, such as 777, can actually trigger a 500 error on hardened servers like ours because they are treated as a security risk. This is a common mistake when people try to "fix" a permissions problem by making everything writable.

Checking and fixing permissions in File Manager

  1. In cPanel, open File Manager.
  2. Navigate to the file or folder you want to check.
  3. Right-click it and choose Change Permissions.
  4. Set the correct value and click Change Permissions.

Resetting permissions in bulk

File Manager allows you to change permissions recursively across a directory. Select the folder, right-click, choose Change Permissions, and tick the option to apply changes recursively to files and subdirectories. [Placeholder: confirm whether the current cPanel File Manager on Kualo supports recursive permission changes and what the exact option label is.]

CGI and Perl scripts sometimes need 755 permissions to execute, but this is uncommon for most shared hosting customers. If you are not running CGI scripts, stick to 644 for files and 755 for directories.

For a full walkthrough, see how to use File Manager in cPanel.

Step 4 - Resolve PHP errors

PHP fatal errors are a very common trigger for 500 errors. By default, PHP errors are suppressed from the browser and written to the error log instead, which is the correct behaviour for a live site.

Enabling PHP error logging

The standard way to manage PHP settings on Kualo shared hosting is through the CloudLinux PHP Selector. This is available to all customers on our shared servers and its settings take priority over other methods.

  1. In cPanel, go to Software and click Select PHP Version. [Placeholder: confirm the exact section and label for the CloudLinux PHP Selector in the current cPanel theme.]
  2. Click Switch to PHP Options at the top of the page.
  3. Find error_log and make sure it points to a writable path, or enable log_errors to ensure errors are written to the log.
  4. Save your changes.

Do not enable display_errors on a live site. Showing raw PHP errors in the browser exposes information about your server and code to visitors.

For a full guide to the PHP Selector, see how to manage the PHP version in cPanel using the Select PHP Version tool.

If you are on a non-CloudLinux server (uncommon): use the MultiPHP INI Editor in cPanel under the Software section to adjust PHP settings. [Placeholder: confirm the exact menu label for MultiPHP INI Editor in the current cPanel theme.]

Temporary debugging via wp-config.php

If you need to see errors quickly on a WordPress site, you can add the following lines to wp-config.php as a temporary measure. Remove them once you have identified the problem.

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

This writes errors to wp-content/debug.log without displaying them on screen.

Common PHP causes to look for

  • A recently installed or updated plugin or theme that is incompatible with your PHP version.
  • A syntax error in a file you have edited manually.
  • The PHP memory limit being exceeded - look for Allowed memory size in the error log.
  • The wrong PHP version selected for your site. If your application requires PHP 8.1 but PHP 7.4 is selected, you will see fatal errors. Check and change the version in the PHP Selector.

For help changing your PHP version, see how to change the PHP version in cPanel.

CloudLinux PHP Selector settings override php.ini in many cases. If you have made changes to php.ini directly or via another method and they are not taking effect, check the PHP Selector settings first.

Step 5 - Check your inode usage

If your hosting account has reached its inode limit, the server may be unable to create new files, which can cause 500 errors for scripts that need to write temporary files, sessions, or cache data.

To check your inode usage:

  1. Log in to cPanel.
  2. Look at the Inodes figure in the account statistics panel on the left-hand side.
  3. For a folder-by-folder breakdown, go to Files and click Disk Usage.

If you are close to or at your limit, delete files you no longer need, empty your email trash, and remove old backups or log files. For more detail, see how to check the number of inodes in your hosting account.

A 508 error is related but different - it specifically means a CloudLinux resource limit (such as CPU or memory) was hit rather than an inode limit. If you are seeing 508 errors, see understanding resource usage in cPanel.

Other less common causes

If the checks above have not resolved the error, consider these less common possibilities:

  • Missing or corrupt index file. If your web root has no index.php or index.html, the server may return a 500 error depending on your directory listing settings.
  • Broken plugin or theme. Even if PHP logging is enabled, a severely broken plugin can sometimes prevent WordPress from loading enough to log the error. Try renaming the wp-content/plugins folder temporarily to disable all plugins at once.
  • Imunify360 false positive. In rare cases, our Imunify360 security system may block a legitimate script it has incorrectly flagged. If all other checks pass and the error is still unexplained, contact our support team and mention that you have worked through this checklist.
  • Server-side issue. If the error affects all sites on your account simultaneously and you have not made any recent changes, there may be a server-level issue. Check our status page and contact support if needed.

For WordPress-specific critical errors, our diagnosing critical errors in WordPress guide covers additional recovery steps.

Quick-reference diagnostic checklist

Use this list as a fast reference when you encounter a 500 error:

  1. Check the error log in cPanel (Metrics > Errors) and read the most recent entries.
  2. Test .htaccess by renaming it to .htaccess_old and reloading the page.
  3. Check file permissions - files should be 644, directories 755, never 777.
  4. Enable PHP error logging via the CloudLinux PHP Selector and reproduce the error.
  5. Check your PHP version in the PHP Selector and make sure it matches what your application needs.
  6. Check inode usage in cPanel and free up space if you are near the limit.
  7. Check for a missing index file in the affected directory.
  8. Disable plugins or themes one by one if the error is WordPress-specific.
  9. Contact our support team if all the above checks pass and the error persists.
Was this helpful?
Your feedback helps us find gaps in the docs.
Still need a hand?
Real people, around the clock - start a chat or open a ticket and we'll help you put it right.