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_loginsidepublic_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_logor check the web server log directly, e.g.tail -n 100 /var/log/apache2/error.logor/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_brokenIf 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 = 120If 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/pluginsSite 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:
| Item | Correct permission |
|---|---|
| Folders | 755 |
| Files | 644 |
| wp-config.php | 600 or 640 |
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
| Error log shows | Likely cause | Fastest fix |
|---|---|---|
| Nothing, log is empty | .htaccess syntax error | Rename .htaccess, reload |
| "memory exhausted" | PHP memory limit | Raise memory_limit in MultiPHP INI Editor |
| "execution time exceeded" | Script running too long | Raise max_execution_time, check for infinite loops |
| Fatal error in a plugin file path | Plugin/theme conflict | Deactivate plugins, re-test one by one |
| ModSecurity rule ID | Firewall false positive | Ask host to whitelist the rule |
When the framework has its own answer
A 500 from a framework is usually more specific than a 500 from a plain PHP file, because the framework knows what it was doing when it failed - and often wrote that down somewhere the web server's log does not reach.
- Laravel writes its own log to
storage/logs/laravel.log, and a 500 immediately after a deploy is nearly always permissions onstorage/andbootstrap/cache/, or a.envthat did not come across. Laravel 500 after deploy covers both. - WordPress hides the detail until you turn it on - see allowed memory size exhausted for the most common single cause.
- Django and Node apps in cPanel fail differently again, because Passenger swallows the traceback unless the app is in development mode.
If the browser shows a blank page rather than a 500, or the connection dies before any status code arrives, you are looking at a different failure - ERR_EMPTY_RESPONSE is what a crashed worker looks like from the visitor's side.
Prevention checklist
- Keep a recent full cPanel backup before any plugin, theme, or core update.
- Edit
.htaccessthrough 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.