Last Update July 28, 2026
To fix a 500 internal server error in WordPress, read your server’s error log first to find the real cause, then apply the matching fix: reset a corrupted .htaccess file, deactivate a conflicting plugin, raise the PHP memory limit, or correct file permissions. The log turns a guessing game into a two-minute diagnosis, and most sites are back within ten minutes.
I fix this error regularly, and here is what I tell everyone staring at that message: your content is safe, and this is almost always minutes away from fixed, not hours.
The 500 is a server-side failure; your posts, pages, and orders sit untouched in the database. The other thing worth saying up front: most guides make you try six fixes blindly, one after another. There is a faster way, and it starts with reading the note the server already left you.
What does the 500 internal server error actually mean?
A 500 internal server error is the server’s way of saying “something broke, and I cannot tell you what.” It is a catch-all HTTP status code: the server tried to run your site, hit an error it could not recover from, and gave up.
The vagueness is the point; the server hides the technical detail from visitors for security, the same reason WordPress hides PHP errors behind the white screen of death.
In WordPress, the usual suspects are a corrupted .htaccess file, a plugin conflict (often right after an update), an exhausted PHP memory limit, a broken theme, wrong file permissions, a PHP version incompatibility, or corrupted core files. Notice what is not on that list: your content. A 500 is a code or configuration failure, not data loss.
One useful distinction before fixing: the 500 is not the same as the white screen of death. A white screen is a completely blank page (a PHP fatal error inside WordPress), while a 500 shows an actual error message or error page (a server-level failure).
They share causes and some fixes, but if you are seeing a blank page with no message at all, follow the white screen of death guide instead.
Is it really a 500? (500 vs 502, 503, and 504)
People mix up the whole 5xx error family, and each number points somewhere different. Thirty seconds here can save you from fixing the wrong problem.
| Code | What it means | Where to look |
|---|---|---|
| 500 | The server itself hit an error running your site | Your site: .htaccess, plugins, memory, permissions |
| 502 | A gateway got an invalid response from the server behind it | Usually hosting or a proxy/CDN like Cloudflare |
| 503 | Server temporarily unavailable or overloaded | Maintenance mode, traffic spikes, resource limits |
| 504 | A gateway waited too long for a response | Slow server or a timeout, often hosting-side |
The short version: a 500 is usually something in your WordPress setup that you can fix. A 502, 503, or 504 more often involves your hosting, a CDN, or server load, and frequently resolves from the host’s side. This guide is for the true 500.
Step 0: Read the error log first (skip the guessing game)
Before renaming files or deactivating anything, open your error log. The server writes down the exact cause of every 500 it throws, and reading that note replaces an hour of trial and error with a two-minute diagnosis. Even hosting support teams start here; it is often how they fix in minutes what an owner has fought for days.
Where to find it: most hosting panels have an “Error Logs” or “Logs” section (cPanel, hPanel, and similar all include one), or look for a file named error_log or error.log in your site’s root or public_html folder via FTP. Open it and read the newest entries at the bottom.
You do not need to understand every line. Look for two things: a file path (if it includes /wp-content/plugins/some-plugin/, that plugin is your culprit; if it names your theme folder, the theme is) and the error type (“Allowed memory size exhausted” means the memory fix below; a line pointing at .htaccess means the .htaccess fix). Copy the first line of the newest error into Google if it is unclear, and you will almost always land on the exact solution.
If WordPress debug logging is easier for you, add these lines to wp-config.php above “That’s all, stop editing”, then check wp-content/debug.log:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
The log named your cause, jump straight to that fix below. If you cannot access any logs, work through the steps in order; they are arranged from most to least likely.
Step 1: Notice WHERE the 500 appears (it narrows everything)
Which parts of your site throw the 500 is itself a diagnosis, and most guides never mention it.
- Whole site, front and admin: classic .htaccess corruption, memory exhaustion, or a site-wide plugin failure. Start with Step 2.
- Only wp-admin (front end works): an admin-side plugin (backup and security tools are common culprits), a memory limit that only trips under heavy admin scripts, or corrupted wp-admin files. Deactivate plugins first; if nothing changes, upload a fresh wp-admin folder from a clean WordPress download.
- Only one page or action (say, checkout, or saving a post): whatever runs on that specific page: a shortcode, a page builder element, or one plugin’s feature. The error log will name it directly.
- Comes and goes randomly: this is the intermittent 500, and it has its own section below, because it is the version generic guides skip entirely.
Step 2: Reset your .htaccess file
A corrupted .htaccess file is the single most common cause of a site-wide 500, and the fix takes two minutes. This file controls how the server handles requests, and one invalid line breaks every page.
Connect via FTP or your host’s file manager, find .htaccess in your site’s root folder (where wp-config.php lives; enable “show hidden files” if you do not see it), and rename it to .htaccess_old. Reload your site. If it comes back, the file was the problem: go to Settings, then Permalinks in wp-admin, and click Save Changes to generate a fresh, clean .htaccess. Done.
One related cause worth knowing from real cases: a corrupted wp-config.php can also throw a 500, especially after a migration or a manual edit. If .htaccess was not the issue and you recently edited wp-config.php, re-check that file for stray characters or a syntax slip.
Step 3: Deactivate all plugins
If .htaccess is clean, plugins are next, because a plugin conflict (an update that shipped a bug, or two plugins fighting over the same hook) causes a large share of 500 errors. Deactivating everything at once confirms or rules out the whole category in one move.
The wp-admin works: Plugins, select all, bulk Deactivate. If wp-admin is also down: via FTP, rename wp-content/plugins to plugins_old, reload, then rename it back (plugins stay deactivated). If the site returns, reactivate plugins one at a time, reloading after each, until the 500 reappears; the last one activated is your culprit. Update it, replace it, or report the bug to its developer. The plugin updated most recently before the crash is the usual suspect.
Step 4: Raise the PHP memory limit
When WordPress runs out of allocated PHP memory mid-execution, the server can respond with a 500. Sites running WooCommerce, page builders, or many plugins hit this ceiling more often than owners expect.
Check your current limit first: in wp-admin go to Tools, Site Health, then the Info tab, and scroll to the server section. To raise it, add this line to wp-config.php above “That’s all, stop editing”:
define( 'WP_MEMORY_LIMIT', '256M' );
Reload the site. Two honest caveats. First, some hosts cap memory at the account level, so the line changes nothing until you ask the host to raise the cap. Second, if raising memory fixes it, your job is half done: something was eating that memory, usually a heavy or inefficient plugin, and the error log will show which one. Fix the eater, not just the ceiling, or the 500 returns as the site grows.
Step 5: Check your theme and PHP version
If plugins and memory are ruled out, test the theme and the PHP version, because a theme with a syntax error, or code written for an older PHP version, can fail at the server level.
Switch to a default theme (Appearance, Themes, activate Twenty Twenty-Four or Twenty Twenty-Five; or via the database/FTP if wp-admin is down). If the 500 disappears, the theme is the problem: restore a fresh copy from its official source or contact its developer.
On PHP versions: hosts are rolling servers onto PHP 8.3 and 8.4, and older themes and plugins written for PHP 7.x can throw fatal errors on them.
Most hosting panels let you switch PHP versions yourself; temporarily dropping one version (say 8.4 to 8.2) and watching the 500 vanish confirms the diagnosis. The lasting fix is updating or replacing the outdated code, since old PHP versions lose security support.
Step 6: Permissions and core files (the less common causes)
If everything above checks out, two quieter causes remain. Wrong file permissions can make the server refuse to execute your site: folders should be 755 and files 644, and your host’s support can reset these in one command if you are unsure.
Corrupted core files, from an interrupted update, a failed restore, or malware, can also produce 500s. The fix is replacing the WordPress engine with a fresh copy without touching your content: download WordPress from wordpress.org, delete the wp-content folder from the download, and upload the rest over your site via FTP.
Your wp-config.php and wp-content (themes, plugins, uploads) stay yours. If the log hinted at malware, run a security scan afterward as well.
The intermittent 500: when the error comes and goes
A 500 that appears randomly, especially during busy hours, and then vanishes is the hardest version, and the one most guides skip. The pattern means your code works when the server has capacity and fails when it does not.
The usual mechanics: the PHP memory limit is only exceeded on heavy pages or heavy traffic, the database connection pool is exhausted under load, or your shared hosting plan’s resource limits (CPU seconds, concurrent processes) throttle the site when it gets busy. That is why the error will not reproduce when you test at midnight.
How to pin it down: check the error log for the timestamps when the 500s happened (not when you tested), look for “memory exhausted” or “resource limit reached” entries, and ask your host directly whether your account is hitting its limits and when.
If the answer is yes, the honest fixes are reducing the load (lighter plugins, caching so fewer requests hit PHP) or a hosting plan with more resources. A recurring intermittent 500 during traffic peaks is nearly always a resource ceiling, not a broken file, and no amount of .htaccess resetting fixes a ceiling.
“But I didn’t change anything”: why sites break on their own
A 500 on a site nobody touched feels impossible, but something did change; it just was not you. This is one of the most common and least explained situations.
The usual invisible changes: your host upgraded the server’s PHP version overnight and older plugin code stopped working; a plugin or theme auto-updated and shipped a bug; your site’s traffic or data quietly grew past a memory or resource limit that used to be enough; or a scheduled task (a backup job, a cron task) started colliding with busy traffic.
The error log, again, is where the answer lives: its timestamps and file paths tell you what actually changed and when. When the log points outside your site entirely, ask your host what changed on the server that day; “did you upgrade PHP recently?” solves more mystery 500s than any file edit.
How to prevent 500 errors
Most 500s trace to a handful of preventable patterns. Update plugins one at a time rather than in bulk, so a broken update identifies itself. Keep themes and plugins current, because outdated code is exactly what breaks when hosts move to newer PHP.
Remove plugins you do not use; every extra one is a potential conflict. Know your memory limit and your hosting plan’s resource limits before growth hits them. Keep automated backups so the worst case is a restore. And set up a free uptime monitor (UptimeRobot or similar) so you learn about a 500 from an alert, not from a customer.
Conclusion
The 500 internal server error is a server-side failure with your content safely untouched, and the fastest path to fixing it is reading the error log first, because the server has already written down the cause. Match the log to the fix: reset .htaccess for site-wide corruption, deactivate plugins for conflicts, raise the memory limit when it is exhausted, check the theme and PHP version, then permissions and core files.
Where the error appears (whole site, only wp-admin, one page, or randomly) is itself a diagnosis, and the intermittent 500 that comes and goes under traffic is almost always a resource ceiling that needs lighter load or better hosting, not another file edit. Most fixes take two to ten minutes; the log is what keeps it from taking all day.
Frequently Asked Questions
What causes a 500 internal server error in WordPress?
The most common causes are a corrupted .htaccess file, a plugin conflict (often after an update), an exhausted PHP memory limit, a broken theme, wrong file permissions, a PHP version incompatibility, or corrupted core files. The server’s error log records the exact cause, which is why checking it first beats guessing.
How do I find what caused my 500 error?
Open your hosting panel’s error log (or the error_log file in your site root via FTP) and read the newest entries. A file path containing a plugin or theme folder names your culprit, and the error type (memory exhausted, .htaccess syntax) names the fix. Alternatively, enable WP_DEBUG_LOG and read wp-content/debug.log.
Does a 500 error mean my site was hacked?
Usually not. The overwhelming majority of 500s come from plugin conflicts, .htaccess corruption, or memory limits. That said, malware can corrupt files and trigger 500s, so if the error log points at modified core files or unfamiliar code, run a security scan after fixing the error.
Why do I get a 500 error only in wp-admin?
Because something that runs only in the admin is failing: typically a backup or security plugin, a memory limit that trips under heavy admin scripts, or corrupted wp-admin files. Deactivate plugins first, raise the memory limit next, and if needed upload a fresh wp-admin folder from a clean WordPress download.
Why does my 500 error come and go randomly?
An intermittent 500 almost always means a resource ceiling: memory or hosting limits that are only exceeded during heavy pages or busy traffic. Check the error log at the failure timestamps and ask your host whether your account hits its limits. The fix is lighter load, caching, or a plan with more resources.
Will fixing a 500 error delete my content?
No. Every standard fix (resetting .htaccess, deactivating plugins, raising memory, replacing core files while keeping wp-content) leaves your posts, pages, media, and settings untouched in the database. Back up before making changes anyway, so even a mistake during fixing is reversible.
