In this article9 sections
The 500 Internal Server Error is the least helpful message a website can show. It says that something failed on the server but not what. On a cPanel account, the cause is almost always one of four things: a broken .htaccess file, a PHP error or memory limit, wrong file permissions, or a plugin or application that crashed on a request. This guide gives you an order of checks that finds the cause quickly, with the log that names it, the fix for each cause, and the steps to confirm the site works again.
If your site runs on SiteHarbour’s cPanel hosting, the error log for the account is in cPanel, so you do not need server access. The steps below work on any cPanel account.
Step 1: Read the error log first
Guessing wastes time, and the log names the problem. In cPanel, open Errors under Metrics. It shows the last errors for the account, with the file and line where each one happened. Look for the newest entry that matches the time you saw the 500 error.
Over SSH, the same information is in the error log for the domain:
tail -n 50 ~/logs/example.com.error.logExpected: a line for each failed request. Read the message, not only the code. The message tells you which of the causes below applies.
Step 2: Check the .htaccess file
A single wrong line in .htaccess causes a 500 on every page. This is the most common cause after an update or a plugin change. Rename the file to test:
mv ~/public_html/.htaccess ~/public_html/htaccess.bakLoad the site. If it works, the problem is in .htaccess. For WordPress, open the file again and let WordPress rebuild the default rules by saving Settings > Permalinks, then compare. If the site still fails, restore the file name and go on.
Expected: the site loads without the file. Put the file back as .htaccess once the cause is fixed, and keep a copy of the good version.
Step 3: Check the permissions
Wrong permissions cause 500 errors when the web server cannot read a file it needs. The standard is folders at 755 and files at 644:
find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;Run these in the site folder only, and not on the home folder, because they change every file under the path. Expected: the site loads, or the error log changes to a new message that names the next cause. A file set to 777 is a security hole, so do not leave it there.
Step 4: Check for a memory or time limit
When PHP runs out of memory or time, the request fails with a 500 instead of a page. The error log says Allowed memory size exhausted or Maximum execution time exceeded. Check the current limit in cPanel under Select PHP Version, or in the PHP settings for the domain. Raise the value one step at a time, and test after each change.
If the same error returns, the problem is the code or the plugin, not the limit. Raising it hides the cause and uses more of the account’s share. The limits themselves are covered in how to fix the 508 Resource Limit Is Reached error.
Step 5: Check the PHP version
A plugin or application that needs a newer PHP than the domain uses can fail with a fatal error on every request. Look at the error log for a message about a missing function or a syntax error. Compare the version you use with what the application requires, and change it in Select PHP Version if needed. Read how to choose the right PHP version and handler in cPanel before you switch, because the handler affects memory use too.
Step 6: Find the plugin or script that crashed
For WordPress, a plugin that crashes on load is a common cause. Turn on the debug log in wp-config.php, reproduce the error, and read the file it writes:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);The log is wp-content/debug.log. The file and the plugin named in the first fatal error is the one to disable. Turn debugging off again when you finish, because the log can grow large and it may reveal paths.
Step 7: Confirm the fix
Load the page that failed, the home page and one page that writes to the database, such as a login or a form. Then check the error log again after an hour. A fix that works once can fail on a later request, so the second check matters.
Common mistakes
- Editing the live site without a copy. Keep the original of any file before you change it.
- Raising limits to hide the error. The memory limit is a symptom, not the cause.
- Changing permissions to 777. That is never the fix for a 500 error, and it exposes the files.
- Leaving debug on. Turn WP_DEBUG_LOG off once you have the answer.
Frequently asked questions
Is a 500 error always on the server?
Yes, the server returns it, but the cause can be in a file, a plugin, a setting or the PHP version. The error log tells you which.
Why does the error only happen on some pages?
Usually one page runs code the others do not, such as a form, a search or a plugin that loads only there. Find the request in the log and read the file it names.
Can I fix this without SSH?
Yes. The error log in cPanel and File Manager cover most cases. SSH makes the checks faster, but it is not required.
What if the log is empty?
Turn on PHP error logging for the domain in Select PHP Version, reproduce the error, and check again. An empty log usually means errors are being hidden.
A 500 error is a question the log can answer. Read it, check the .htaccess file, the permissions, the limits, the PHP version and the plugin that crashed, in that order. Confirm the fix with a second look at the log. For an account that keeps running into resource problems, read how to keep your cPanel account and sites secure as well.