A 500 Internal Server Error is the web server equivalent of a car that will not start and displays no error code on the dashboard. Something failed. The server knows something failed. But it does not know specifically what — or it knows and cannot tell the browser.
That is by design. A 500 error is a catch-all response that fires when the server encounters an unexpected condition it cannot handle or classify more precisely. Unlike a 404 (page not found) or a 502 (bad gateway), a 500 gives the visitor no actionable information at all. The fix lives in a log file on your server, not in anything visible on the error page.
This guide covers every common cause with the exact diagnosis step, in the exact order that resolves most 500 errors in the shortest time. No guessing, no trying random fixes. Start with the error log, identify which scenario applies, and apply the specific fix for that scenario.
A 500 error is always server-side. The visitor did nothing wrong and cannot fix it. If only one specific URL shows a 500 while others work, the problem is in that page’s code or database query. If the entire site shows a 500, the problem is in .htaccess, PHP configuration, or a plugin that loads on every request.
What Actually Causes a 500 Error
Six distinct root causes produce the same identical 500 message in the browser. They require completely different fixes. The error log is the only way to distinguish between them.
Plugin and theme conflicts account for the largest share because WordPress plugins have full PHP execution access and run code on every page load. A single plugin with a fatal error crashes the entire site before WordPress can even generate an error page. This is why a 500 error often appears immediately after a plugin update.
The second most common cause, .htaccess corruption at 24%, is specific to Apache-based servers. Nginx does not use .htaccess at all. If your site runs on Nginx and you see a 500, skip every .htaccess diagnostic step and go directly to PHP error logs and process management.
The Six-Step Fix Process: Work Top to Bottom
Each step below resolves a different root cause. They are ordered from most common to least common. Stop the moment the error clears — you have found the cause. If a step does not change anything, move to the next.
Step 1: Read the Error Log Before Touching Anything
This is the step most troubleshooting guides skip because it requires server access. Do not skip it. The error log contains the exact file path, line number, and error message that caused the 500. Every other step is guesswork without it.
Three ways to access the PHP error log:
- cPanel: navigate to Metrics, then Errors. The last 300 PHP errors appear with timestamps.
- SSH access: run tail -50 /var/log/apache2/error.log (Apache) or tail -50 /var/log/nginx/error.log (Nginx).
- Enable WP_DEBUG: add define(‘WP_DEBUG’, true); and define(‘WP_DEBUG_LOG’, true); to wp-config.php above the require_once line. After enabling, reload your site to trigger the error. The log writes to wp-content/debug.log.
Always set WP_DEBUG_DISPLAY to false when enabling debug mode. Setting it to true displays raw PHP errors directly on the page, exposing file paths and server configuration details to every visitor.
Step 2: Disable All Plugins via FTP
If the log shows a fatal error in a file path containing /wp-content/plugins/, a plugin is the cause. The fastest isolation method does not require dashboard access because the dashboard itself may be showing the 500 error:
| // Connect to your server via FTP or cPanel File Manager
// Navigate to your WordPress root directory // Rename this folder: wp-content/plugins // To this: wp-content/plugins_OFF
// Reload the site. If it loads, a plugin was the cause. // Rename the folder back to ‘plugins’, then reactivate one plugin // at a time from the WordPress Plugins dashboard until the error returns. |
The same isolation method works for themes: rename your active theme folder inside wp-content/themes/ and WordPress falls back to the default Twenty-Twenty theme. If the site loads, your theme’s functions.php contains a fatal error.
Step 3: Fix or Regenerate the .htaccess File (Apache Only)
A corrupted .htaccess file crashes Apache sites instantly and often generates no PHP error — the server fails before reaching PHP. The diagnostic is simple: rename the file and test.
- Via FTP: rename .htaccess in your site root to .htaccess.bak
- Reload the site. If it loads, .htaccess was the cause.
- Regenerate a clean .htaccess: log into WordPress dashboard, go to Settings, then Permalinks, and click Save Changes. WordPress writes a fresh default file.
If you cannot access the WordPress dashboard because the 500 affects wp-admin too, manually create a new .htaccess file containing only the WordPress default content. See the configuration reference in Figure 4 for the exact content.
Step 4: Raise the PHP Memory Limit
If the log shows the text Allowed memory size of X bytes exhausted, PHP hit its memory allocation limit mid-execution. The fix is increasing the limit. Three methods work, apply whichever your hosting setup allows:
| // Method A: wp-config.php (add above the require_once line)
define(‘WP_MEMORY_LIMIT’, ‘512M’); define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);
// Method B: .htaccess (Apache only) php_value memory_limit 512M
// Method C: php.ini memory_limit = 512M |
512MB is the recommended minimum for WordPress sites running WooCommerce, Elementor, Divi, WPML, or any combination of resource-intensive plugins. Shared hosting plans often default to 64MB or 128MB. If your host does not allow raising the limit via configuration files, contact their support.
Step 5: Fix File Permissions
If the log shows Permission denied when trying to access a PHP file, the server user cannot read or execute the file. WordPress requires specific permission levels: 755 for directories and 644 for files. The exception is wp-config.php, which should be 600 to prevent other users on shared hosting from reading your database credentials.
Step 6: Reinstall WordPress Core Files
If steps 1 through 5 have not resolved the 500 and the log shows errors in files under /wp-includes/ or /wp-admin/, the WordPress core installation is damaged. Reinstalling core files overwrites only the WordPress system files and leaves your wp-content folder, wp-config.php, and database completely untouched:
| // Via WP-CLI (fastest):
wp core download –force
// Via FTP manually: // 1. Download fresh WordPress zip from wordpress.org // 2. Extract the zip on your computer // 3. Upload ALL files EXCEPT the wp-content folder // 4. Overwrite existing files when prompted // Your content, plugins, and themes are untouched. |
Reading the Error Log: Decoding Every Message Type
The PHP error log speaks a specific language. Once you can read it, diagnosing a 500 takes under two minutes. Here is every major log pattern and what it means for your fix path.
The Four Log Patterns That Identify 500 Causes
PHP Fatal error: Uncaught Error or Call to undefined function — always means a plugin or theme crash. The file path after the word in names the exact plugin. Disable that specific plugin first.
Allowed memory size of X bytes exhausted — memory limit reached. The current limit in bytes appears in the message. 134217728 bytes equals 128MB. Raise to 512MB.
AH00124: Request exceeded the limit of 10 internal redirects — .htaccess has a looping RewriteRule. Rename .htaccess and regenerate.
Permission denied: unable to access — file or directory has wrong permissions. The full path in the log tells you exactly which folder needs the fix.
.htaccess Corruption and File Permissions: The Two Silent Killers
These two causes are unique because they produce a 500 error without any PHP log entry. The server fails before PHP ever runs, so no PHP error is generated. If your error log is empty or shows only Apache-level errors, one of these two is the cause.
The Five Most Common .htaccess Errors
Duplicate RewriteRule directives writing conflicting redirect targets. Two plugins can both modify .htaccess and create contradicting rules for the same URL pattern.
An unclosed IfModule block. Apache reads .htaccess top to bottom and treats everything after an unclosed tag as part of that directive, breaking all rules below it.
Contradictory Options directives. Options +FollowSymLinks -FollowSymlinks on the same line or in overlapping sections creates an instant parse error.
A PHP value directive on a server that does not allow PHP configuration in .htaccess. Managed WordPress hosts like WP Engine and Kinsta block php_value directives and return a 500 for any .htaccess containing them.
An empty or zero-byte .htaccess file after a failed write. Some caching plugins write .htaccess during activation and can corrupt it if the write is interrupted.
500 vs Other Server Errors and the SEO Impact Timeline
A 500 error is the most generic of the 5xx family. Understanding how it differs from 501, 503, and 508 prevents misdiagnosis and wasted time applying fixes for the wrong error type.
How a 500 Differs from a 503 in Practice
A 503 Service Unavailable means the server is intentionally refusing requests, typically because it is in maintenance mode or explicitly overloaded. WordPress creates a .maintenance file in the site root during updates. If the update fails or the browser is closed mid-update, this file remains and produces 503 or 500 errors on every page load. Fix: connect via FTP and delete the .maintenance file from your WordPress root directory.
A 500 means the server tried to fulfill the request but crashed mid-execution. This is an unintentional failure, not a deliberate refusal.
SEO Recovery After a 500 Outage
A 500 error lasting under one hour has essentially no lasting SEO impact. Googlebot is patient and retries pages it cannot access. Problems begin at the six-hour mark, when Google starts flagging affected pages as temporarily unavailable in its crawl database.
After the 500 clears, two actions accelerate ranking recovery. Open Google Search Console and navigate to URL Inspection. Submit the main affected pages for re-indexing individually. Also check the Coverage report for any new crawl errors logged during the outage. Addressing these directly speeds up the recovery cycle compared to waiting for the natural crawl cadence.
WordPress-Specific Causes That Other Platforms Do Not Have
Three causes are exclusive to WordPress and do not appear in the standard server error documentation or general PHP troubleshooting guides.
wp-cron Overloading PHP Workers
WordPress’s built-in cron system triggers scheduled tasks by spawning a PHP request on every page load when tasks are due. On high-traffic sites, dozens of background cron processes can run simultaneously. Combined with a low PHP-FPM worker count on shared hosting, this exhausts available workers and produces 500 errors under normal traffic load, not just peaks.
The fix is disabling wp-cron and replacing it with a real server cron job:
| // In wp-config.php, add:
define(‘DISABLE_WP_CRON’, true);
// Then add to server crontab (crontab -e): */5 * * * * curl -s https://yourdomain.com/wp-cron.php > /dev/null 2>&1 |
Database Table Corruption
A WordPress database table can become corrupted after an interrupted write operation, a server crash during a database update, or certain plugin conflicts that write malformed data. Corrupted tables produce a 500 error that looks identical to a PHP crash but has nothing to do with PHP code.
WordPress has a built-in repair tool: add define(‘WP_ALLOW_REPAIR’, true); to wp-config.php, then visit yoursite.com/wp-admin/maint/repair.php in your browser. Remove the line after the repair completes.
wp-config.php Wrong Database Credentials
If the database username, password, host, or database name in wp-config.php is incorrect, WordPress cannot connect to MySQL. This usually shows the more specific error establishing a database connection page, but on some server configurations it falls back to a plain 500 error instead. Verify the credentials in wp-config.php match exactly what your hosting panel shows for your MySQL database.
Prevention: Stop 500 Errors Before They Happen
Most repeated 500 errors are preventable. These practices eliminate the conditions that cause the most common root causes.
The Single Most Effective Prevention Measure
Test all plugin and theme updates on a staging environment before applying them to the live site. Plugin conflicts and PHP fatal errors from bad updates cause 38% of all 500 errors. A staging test adds five minutes to the update process and eliminates the single largest category of 500 errors entirely.
Most managed WordPress hosts (WP Engine, Kinsta, Flywheel, SiteGround) include one-click staging environments. For shared hosting, plugins like WP Staging or Duplicator create a staging copy at a subdomain where you can apply and test updates before pushing them live.
PHP Version Compatibility
WordPress 6.4 and later require PHP 7.4 minimum and recommend PHP 8.1 or 8.2. Plugins built for modern PHP can produce fatal errors on PHP 7.0 or 7.2. After any WordPress or plugin major version update, check whether the minimum PHP version requirement changed. Your hosting panel shows your current PHP version and usually allows switching versions with a single dropdown selection.
Frequently Asked Questions
What is a 500 Internal Server Error and what causes it?
A 500 Internal Server Error is a generic HTTP response code meaning the server encountered an unexpected condition that prevented it from completing the request. The error message itself contains no diagnostic information — all the details are in the server’s PHP error log. Common causes on WordPress sites include plugin or theme conflicts (38%), corrupted .htaccess files (24%), PHP memory exhaustion (18%), wrong file permissions (10%), and damaged WordPress core files (6%).
My whole site shows a 500 error. Where do I start?
Start by reading the PHP error log before touching any files. In cPanel: Metrics, then Errors. Via SSH: tail -50 /var/log/apache2/error.log. If you cannot access logs, add define(‘WP_DEBUG’, true); and define(‘WP_DEBUG_LOG’, true); to wp-config.php, reload the site, then read wp-content/debug.log. The log tells you exactly which of the six causes applies. Without the log, every fix is a guess.
Only my WordPress admin area shows a 500 error. The front-end works fine.
A 500 error isolated to wp-admin usually means a plugin that runs only in the admin context is crashing, or the WordPress admin files specifically have a permissions problem. Connect via FTP and try renaming wp-content/plugins to plugins_OFF. If wp-admin loads, reactivate admin-only plugins one at a time. Also check that the wp-admin directory permissions are set to 755 and the files inside are 644.
I get a 500 error only when running certain actions (uploading images, importing data, running a bulk operation).
This is almost always a PHP memory limit or execution time limit being exceeded by a resource-intensive operation. The error fires when the specific operation runs because that is when PHP exceeds its cap. Raise the memory limit to 512MB in wp-config.php and also increase max_execution_time to 300 seconds in php.ini or .htaccess. If the operation still fails after raising limits, the operation itself needs optimization — perhaps chunking a large import into smaller batches.
Does a 500 error affect my search rankings?
A brief 500 error lasting under one hour has no lasting SEO impact — Google retries. An error persisting 6 to 24 hours causes crawl error logging in Search Console and weakening of ranking signals. After one week, affected pages may be deindexed. Recovery after resolving the error takes one to two weeks for minor outages and longer for extended ones. Always submit affected URLs for re-indexing via Google Search Console’s URL Inspection tool after fixing a prolonged 500 error.
I fixed the 500 error. How do I make sure it does not happen again?
The three highest-impact prevention measures: set up uptime monitoring with alerts (UptimeRobot free tier works) so you hear about the next 500 in five minutes instead of two hours after a customer complaint; enable staging environment testing for plugin and theme updates; and set your PHP memory limit to 512MB proactively rather than waiting for an exhaustion error. Additionally, enabling WP_DEBUG_LOG on a permanent low-level basis (with WP_DEBUG_DISPLAY false) lets you spot PHP warnings and notices before they escalate to fatal errors.
