500 Internal Server Error: Common Causes and How to Fix It

Your site loads to a blank white box with one line: "500 Internal Server Error." No plugin name, no file, no line number — just that. It's the most generic error code in hosting, and that's exactly why it's so frustrating to chase down. Here's how we actually find the cause and fix it, whether you're on shared cPanel hosting or a VPS.

What a 500 error actually means

A 500 is a server-side catch-all. It means something on the server broke while it was trying to build the page — a fatal PHP error, a bad Apache directive, a permissions problem, or a resource limit getting hit. Your browser didn't do anything wrong. Neither, usually, did your visitor's connection. The fault is somewhere between your web server and your application.

That's also why "just clear your cache" almost never fixes it. The error is happening before the page is even generated.

Step 1: Stop guessing, check the error log

Every 500 error leaves a trail. Find it before you touch any files.

• cPanel: go to Metrics → Errors. It shows the last 300 lines from your account's error log, newest at the top.
• File Manager: look for error_log inside public_html (or the folder where the error happened). It's a plain text file — open it with the built-in editor.
• SSH/VPS: tail -n 50 /home/USER/public_html/error_log or check the web server log directly, e.g. tail -n 100 /var/log/apache2/error.log or /var/log/nginx/error.log.

The bottom (or top, depending on the view) entry, timestamped closest to when you hit the error, is almost always your answer. Match it against the causes below.

The five causes we see most often

1. A corrupted or misconfigured .htaccess file

This is the single most common cause on shared cPanel hosting. A plugin update, a botched manual edit, or a stray character in .htaccess can bring down the whole site instantly.

Rename it and reload the site:

mv public_html/.htaccess public_html/.htaccess_broken

If the site comes back, the file was the problem. Regenerate a clean default one: in WordPress, go to Settings → Permalinks and click Save without changing anything — WordPress rewrites .htaccess from scratch. For non-WordPress sites, restore from your last cPanel backup or rebuild the rewrite rules your app needs.

2. PHP hit a memory or execution-time limit

Look for lines like Allowed memory size of 268435456 bytes exhausted or Maximum execution time of 30 seconds exceeded in the error log. This shows up during large imports, heavy plugins, or PHP loops that never terminate.

Raise the limits in cPanel → MultiPHP INI Editor (pick your domain, then edit values directly):

memory_limit = 256M
max_execution_time = 120

If you're on WordPress, you can also set memory in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Treat this as a temporary patch, not a fix. If a single page keeps needing more memory every month, something — usually an unoptimized plugin or a runaway loop — is the real problem.

3. A plugin or theme conflict

If the error started right after an update, this is your prime suspect. Rename the plugins folder over SSH or File Manager to deactivate everything at once:

mv wp-content/plugins wp-content/plugins_disabled
mkdir wp-content/plugins

Site back up? Recreate the original folder name, then move plugins back in small batches, reloading after each one, until it breaks again — that last one is the culprit. Update it, replace it, or leave it off.

4. Wrong file or folder permissions

Apache and PHP expect specific permission numbers. Too loose is a security risk; too tight and the server can't read its own files, which throws a 500. The safe defaults:

In cPanel File Manager, select the folder, click Permissions, and apply 755 recursively to directories and 644 to files — don't blanket-apply one number to both, or you'll create the opposite problem.

5. mod_security blocking the request

If your error log shows entries mentioning ModSecurity and a rule ID, the server's security module flagged a request as malicious — sometimes a false positive triggered by a plugin, a form submission, or an aggressive firewall rule. In cPanel, check ModSecurity Tools (if your host exposes it) to see which rule fired, then ask support to whitelist that specific rule ID for your domain rather than disabling mod_security entirely.

Quick diagnosis table

Prevention checklist

• Keep a recent full cPanel backup before any plugin, theme, or core update.
• Edit .htaccess through your app's admin panel (permalinks, redirects module) instead of by hand when you can.
• Update plugins one at a time on a staging copy first if your site is business-critical.
• Set PHP memory and execution limits realistically for your workload, not just the platform minimum.
• Review Metrics → Errors in cPanel occasionally, even when nothing looks broken — early warnings show up there first.

500 errors feel scary because the page gives you nothing to work with. But the fix is almost always in the log, not in guesswork — check it first, and you'll usually know exactly what broke within a few minutes.