A 500 Internal Server Error is HTTP's way of saying "something went wrong on the server and I have nothing more specific to tell you." It's frustrating precisely because it's vague. On WordPress, the actual cause is almost always one of a handful of things. Here's how to work through them systematically, fastest fixes first.
Before doing anything else, check your server error logs. In cPanel, this is under Logs > Error Log. The log will show the actual PHP error that produced the 500 response, something like PHP Fatal error: syntax error, unexpected '}' in /wp-content/plugins/some-plugin/file.php on line 42. That tells you exactly what caused the error and where it is. Working without the error log means guessing; the log removes the guesswork.
If you have SSH access, you can tail the error log in real time with: tail -f ~/logs/error_log. Reload the page while watching the log and the error will appear immediately. You can also enable WordPress debug logging to capture PHP errors before WordPress can handle them:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Check /wp-content/debug.log after reloading the page.
The .htaccess file in your WordPress root controls URL rewriting, redirect rules, and various server directives. A corruption, an invalid rule added by a plugin, or a syntax error here produces a 500 error on every request because the web server rejects the malformed configuration before WordPress even loads.
Via FTP, rename .htaccess to .htaccess_old. If the site loads (even with broken permalinks and missing redirects), .htaccess was the cause. Go to Settings > Permalinks in wp-admin and click Save Changes to regenerate a clean, valid .htaccess. Then compare the old file against the new one to identify which rule was causing the problem.
Note: .htaccess is a hidden file. In cPanel File Manager, go to Settings and enable "Show Hidden Files" to see it. In FTP clients, look for a "Show hidden files" or "Show dotfiles" option in preferences.
Rename /wp-content/plugins/ to /wp-content/plugins_disabled/ via FTP to deactivate all plugins simultaneously. If the 500 clears, a plugin is the culprit. Rename the folder back and re-enable plugins one at a time from your wp-admin dashboard, testing after each activation. The most recently installed or updated plugin is the most likely cause, start there.
If the 500 only affects wp-admin but the front end loads, focus on plugins that add dashboard functionality: admin bar customisers, dashboard widgets, or plugins that hook into admin-specific actions. If only the front end errors, look at plugins that hook into front-end rendering: page builders, SEO plugins, and ad management plugins are common culprits.
If the error log points to a specific plugin file, you can deactivate that plugin by renaming its folder inside /wp-content/plugins/ rather than disabling everything at once.
A memory limit hit can present as either a White Screen of Death or a 500 Internal Server Error, depending on how and where PHP fails. Add this to wp-config.php above the "That's all, stop editing!" line:
define( 'WP_MEMORY_LIMIT', '256M' );If the error clears, memory was the cause. See our memory exhausted guide for a full walkthrough of increasing limits and finding the root cause.
If you recently updated your PHP version via your hosting control panel, a plugin or theme may not be compatible with the new version. PHP 8.x deprecated and removed several functions that existed in PHP 7.x, if a plugin calls any of those functions, it generates a fatal error that presents as a 500. Check the error log for function deprecation warnings or fatal errors pointing to specific files.
You can temporarily roll back the PHP version in your control panel to confirm this is the cause, then update or replace the incompatible plugin. The correct long-term fix is updating the plugin to a PHP 8-compatible version, not staying on an older PHP version permanently. Running outdated PHP has significant security implications.
WordPress files should be 644 and directories should be 755. If file permissions are set too restrictively (for example, 400 or 000), PHP may refuse to read those files, producing a 500 error. If permissions are set too permissively (777 on files), some server security configurations reject the request.
In your FTP client, right-click on the WordPress root directory and look for a "File Permissions" or "CHMOD" option. Set files recursively to 644 and directories to 755. If you have SSH access, these one-line commands handle it:
find /path/to/wordpress -type f -exec chmod 644 {} \;
find /path/to/wordpress -type d -exec chmod 755 {} \;Download a fresh WordPress zip from wordpress.org. Extract it and re-upload the wp-admin and wp-includes folders via FTP, overwriting the existing files. Do not overwrite wp-config.php or wp-content, these contain your site configuration and all your content. Corrupted core files are less common but can occur after a failed auto-update, a server crash during a file write, or malware that modifies core files.
Once you've re-uploaded core files, go to Dashboard > Updates in wp-admin and click "Re-install Now" on the current WordPress version. This performs the same operation through the interface and also verifies the checksums of all core files.
Once you've resolved the 500 error, set WP_DEBUG back to false in wp-config.php and delete any temporary test files you created. If a plugin caused the error, check whether an update is available that fixes the issue before re-activating it. If a plugin is abandoned and incompatible with your PHP version, replace it with a maintained alternative rather than staying on an older PHP version.
HostBible support can read your error logs and tell you what's causing the 500, rather than sending you a generic troubleshooting article.
View Hosting Plans