A WordPress 500 error means the server hit a fatal PHP script error and stopped rendering the page. It isn’t a generic failure; it’s usually a specific file or plugin crashing the code execution. Fix it by forcing maintenance mode via FTP or your host’s file manager to edit the problematic code directly.
Seeing “Internal Server Error” freezes your traffic. Visitors bounce. Revenue stops. In support tickets I’ve handled for the last decade, the root cause is rarely vague. It is concrete. A runaway loop. A memory limit breach. A corrupted theme file. This guide skips the generic “check your hosting” advice and goes straight into the technical workflows I use to resolve these incidents in under five minutes.
The 500 code is a catch-all. The HTTP protocol says the server encountered an unexpected condition. For WordPress, that condition is almost always PHP. The interpreter hits a `fatal error` it can’t recover from, so it kills the request process.
In 2026, the landscape has shifted slightly. Modern PHP versions (8.3 and 8.4) are stricter about type declarations and deprecated functions. Many plugins released in 2023–2024 relied on loose typing. When you update PHP to the latest stable release, those old hooks break silently until they crash.
Also, AI-integrated plugins are heavier. They consume more RAM. If your hosting plan is shared, a spike in AI processing can push your site over the `memory_limit` threshold. Once that happens, PHP dies. The web server returns a 500.
You can’t log in. The dashboard is behind the same code that’s crashing. So, you bypass it.
Step 1: Enable Display Errors
You need to see the actual error message. The generic 500 page hides the truth. Connect via FTP or SFTP. Open `wp-config.php`. Add this line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
This sends errors to `wp-content/debug.log` instead of the screen. Visit your site again. Then, open `debug.log`. Read the last few lines. It will say exactly which file and line number failed.
Step 2: Check Permissions
Broken file permissions are a classic. Your web server (Apache or Nginx) reads files as user `www-data` or `apache`. If a recent upload set permissions to `777` or owned files by your FTP user, the server can’t read them.
Run this in your terminal if you have SSH access:
find /path/to/wordpress -type f -exec chmod 644 {} \;
find /path/to/wordpress -type d -exec chmod 755 {} \;
This resets standard permissions. Files read-write for owner, read-only for others. Directories execute permission for owner, read-execute for others.
PHP 8.4 is now the default on most managed WordPress hosts in 2026. It’s faster, but it breaks legacy code.
I see this daily. A user updates their PHP version to get a speed boost. Suddenly, the homepage disappears. Why? A plugin uses `var_dump()` in a production environment during a bootstrap phase. In PHP 8.4, output buffering changes cause this to trigger a header-sent error or a fatal parse issue if mixed with HTML.
Check your error log for “Deprecated” warnings that turned into “Fatal” errors.
Here is a real example from a ticket last month:
Fatal error: Uncaught Error: Undefined array key “cache_key” in /var/www/html/wp-content/plugins/ai-booster/inc/core.php on line 42
The plugin expected a variable that was no longer set by the core due to a minor API change. The fix? Deactivate the plugin via FTP (rename the folder) or patch the code.
Shared hosts cap your PHP memory. Often at 128MB or 256MB. Big themes with heavy JavaScript or AI widget integrations need 512MB.
When you exceed the limit, PHP throws a `Fatal error: Allowed memory size of … bytes exhausted`.
You have three options:
1. **PHP.ini file:** Create `php.ini` in your root directory. Add `memory_limit = 512M`.
2. **.htaccess file:** Add `php_value memory_limit 512M`.
3. **wp-config.php:** Add `define(‘WP_MEMORY_LIMIT’, ‘512M’);` inside the opening/closing comments.
Method 3 is WordPress-specific and works even if the host disables `.htaccess` writes. However, if your host’s global `php.ini` sets a hard cap lower than 512M, this won’t work. You need to ask your host to raise the limit.
According to WordPress.org Server Requirements, 64MB is the minimum, but real-world performance in 2026 demands at least 256MB for sites with >5 active plugins. Sites serving high-traffic e-commerce or using AI chatbots should target 512MB or 1GB.
Themes are half your site. If the `functions.php` file in your active theme gets corrupted, everything dies.
Common culprits:
Fix it by renaming your theme folder. If you’re using a custom theme, go to `/wp-content/themes/your-theme/`. Rename the folder to `your-theme_backup`.
If WordPress loads now, the theme was the issue. Re-upload a clean copy. If you don’t have one, restore from backup.
Manual deactivation is slow. You have 15 plugins? That’s 15 file renames. Instead, use a plugin whitelist approach.
Create a file named `mu-plugins` if it doesn’t exist. Inside, create `disable-plugins.php`. Add:
add_action( 'plugins_loaded', function() {
global $wp_filter;
$wp_filter['init']->remove( 'some_plugin_slug' );
});
Wait, that’s for hooks. For hard disabling, rename the folder. It’s faster.
Or, use your hosting cPanel’s “Error Log” or “PHP Selector”. Toggle plugins off in batches. If the site loads, you found the culprit group. Narrow it down.
The `debug.log` file is your best friend. Don’t guess. Read it.
Look for patterns:
In one case, the log showed `mkdir(): Permission denied`. The `/wp-content/cache` folder was owned by `root` instead of `www-data`. A quick `chown -R www-data:www-data /var/www/html/wp-content/` fixed it in seconds.
Only if you have SSH access via your host’s terminal. If not, you must contact your hosting provider. Explain that your site shows a 500 error and you need them to enable `WP_DEBUG` or check the error logs on their end. Most managed hosts do this within 15 minutes.
No. The cache is a symptom or a secondary issue. The 500 error is a server-side PHP crash. Clearing the cache won’t fix a syntax error in a plugin. However, if a corrupted cache file is causing the crash, deleting the cache folder via FTP might help. But always check the logs first.
Because that plugin’s code is incompatible with your current PHP version or core WordPress version. The plugin likely throws a fatal error during the `plugins_loaded` hook. Disable the new plugin immediately via FTP by renaming its folder.
Not necessarily. However, if you see errors related to file inclusion or unauthorized file writes, check your security scanner. A 500 error often masks malware attempts where malicious code tries to execute and fails. Run a security scan after fixing the error.
Use a staging environment for updates. Test PHP version changes there. Monitor your `debug.log` file regularly during updates. Keep backups of your `wp-config.php` and critical theme files. And, as suggested in our guide on checking server permissions, enforce strict file ownership rules.
One final note: If you’re using cloud hosting like AWS or DigitalOcean, check your CPU credits. In 2026, many budget VPS instances use burstable performance. If your CPU credits run out, throttling happens. It doesn’t usually cause a 500, but it causes timeouts that look like server unresponsiveness. Check your CloudWatch or DigitalOcean metrics for “Credit Usage.”
If you’ve checked permissions, debug logs, and disabled plugins, and it’s still broken, look at the database.
Corrupted `wp_options` table entries can cause fatal errors. Specifically, the `active_plugins` option. If it contains a plugin slug that no longer exists, WordPress tries to load it and fails.
Connect to MySQL. Run:
SELECT * FROM wp_options WHERE option_name = 'active_plugins';
Decode the serialized array. Look for missing plugins. Remove them from the string. Update the row. Clear your object cache (if using Redis or Memcached). Reload the site.
This is rare, but it happens after failed deletions.
The 500 error is scary because it’s silent. It doesn’t tell you what’s wrong. It just says “no.”
But you have the tools. You have FTP. You have `wp-config.php`. You have the error log. Use them. Don’t panic. Don’t restart the server (that does nothing). Dig into the files. Find the line number. Fix the code. Or remove the bad plugin.
Speed matters. Every minute your site is down, you lose money and trust. Act fast. Act precise. And always keep a recent backup.
If you’re struggling with server-level issues beyond WordPress, consider reading our detailed guide on VPS vs Shared Hosting to ensure your infrastructure can handle the load 2026 traffic demands.