WordPress Showing a 500 Internal Server Error? Here's What's Actually Wrong.

What is the problem?

A “500 Internal Server Error” is not a WordPress error — it's a server error. It's the generic response your web server (Apache, Nginx or LiteSpeed) sends when something goes wrong badly enough that it can't even hand the request off to PHP and WordPress properly, or PHP itself crashes before WordPress's own code has loaded far enough to produce a friendlier message. That's the key difference from WordPress's own “There has been a critical error on this website” screen: that message is WordPress talking to you. A bare 500 page is your server refusing the request outright, often before WordPress gets a say in how it looks.

Quick answer: a 500 error almost always traces back to one of four things — a broken .htaccess file, a PHP fatal error too low-level for WordPress's own handler to catch, wrong file permissions, or the server running out of resources. Your host's raw error log will tell you which within a minute or two of looking.

Because the failure happens below WordPress, it can behave more broadly than a typical WordPress error. It's common for a 500 to take out wp-admin and even wp-login.php along with your public pages, which understandably makes it feel worse than a plugin conflict or a page-builder glitch. In practice it's usually no harder to fix — it just needs FTP or your hosting file manager instead of the WordPress dashboard, since the dashboard is one of the things affected.

Common symptoms

• A plain, unstyled “500 Internal Server Error” page, sometimes carrying your host's own branding (an Apache, Nginx, LiteSpeed or cPanel default error page) instead of anything from WordPress
• It's intermittent — a reload sometimes works, then the error comes back a few requests later
• wp-admin and wp-login.php are down along with the public site, not just the front end
• It started right after installing or updating a plugin, changing your PHP version, or editing a file directly over FTP
• Your host's own status or uptime page shows everything as “operational,” which is technically true — the server is up, it's just refusing this specific request
• Different visitors, or the same visitor on different devices, see the error at different times, suggesting it's load- or resource-related rather than constant

Why does this happen?

Every request to your WordPress site passes through several layers before a page appears: the web server software, then PHP, then WordPress itself, then your theme and plugins. A 500 error means something failed in one of the first two layers — the web server or PHP — rather than inside WordPress's own code. That's why it looks so different from a typical WordPress problem: WordPress never got far enough to display its usual message, log a nice error, or trigger its recovery-mode email.

This also explains why the error can seem to come and go. A resource limit on shared hosting, for instance, isn't a fixed wall — it's a ceiling that gets hit under certain conditions (a traffic spike, a heavy background process, several visitors hitting a slow page at once) and clears once those conditions pass. The underlying cause doesn't go away just because the symptom does.

Common technical causes

• A corrupted or misconfigured .htaccess file — bad rewrite rules, often introduced after a permalink resave, a migration, or a security plugin editing the file automatically
• A raw PHP fatal or parse error low-level enough that WordPress's own error-catching (added in WordPress 5.2) never gets the chance to run — a common cause is a typo introduced editing a file directly over FTP
• Wrong file or folder permissions after a migration, restore, or a host-side change — directories generally need 755, files 644, and anything more permissive or restrictive can trigger a 500
• PHP memory exhausted hard enough to kill the PHP process itself, rather than triggering WordPress's friendlier critical-error screen
• A PHP version your site or a specific plugin isn't compatible with, often surfacing right after a host auto-upgrades the default PHP version
• Shared hosting resource limits — CPU or process-count ceilings, not just memory, which many hosts enforce silently and only mention if you ask
• A completely full disk quota, which can stop PHP from writing temporary files, session data, or even a fatal-error log entry
• A corrupted WordPress core file left behind by an interrupted or failed automatic update

How to diagnose it

1. Read the raw server error log first. This is the single fastest way in, because a 500 page itself almost never shows the real cause. Your host's control panel usually has an “Errors” or “Error Log” tool; if you have SSH access, tail -f error_log in your site's root shows it live as you reproduce the issue.
2. Rename .htaccess to test it. Via FTP or File Manager, rename .htaccess to .htaccess-disabled and reload the site. If it loads now, the rewrite rules were the cause.
3. Check your current PHP version against plugin requirements. Your hosting panel's PHP selector shows the active version; compare it against the “Requires PHP” line on your plugins' and theme's info pages.
4. Check disk quota and file permissions via FTP or your host's File Manager — a quota at 100% or folders sitting on unusual permissions are both easy to confirm visually.
5. If PHP was recently changed, try reverting it in your hosting panel's PHP version selector, then reload to see if that alone resolves it.
6. Isolate plugins by renaming the plugins folder. Via FTP, rename wp-content/plugins to something like plugins-disabled. This deactivates every plugin at once without touching your database. If the error clears, rename it back and disable plugins one at a time to find the exact one at fault.

How to fix it, step by step

1. Pull the exact error line from the raw server log before doing anything else. Guessing at a 500 error wastes time; the log almost always names the file and reason directly.
2. If .htaccess is the cause, delete the broken file and go to Settings → Permalinks in wp-admin, then click Save Changes with no other edits — WordPress regenerates a clean, working .htaccess from your existing permalink settings.
3. Fix file and folder permissions via FTP if a migration or restore is the likely trigger — 755 for directories, 644 for files is the standard, safe baseline.
4. Revert to the previous PHP version in your hosting panel if a version change is the suspect, giving yourself room to update the incompatible plugin or theme properly before moving PHP forward again.
5. Raise the PHP memory limit via php.ini or .user.ini if you have file-level access, or ask your host directly to raise it server-side if you don't — a value in wp-config.php can't exceed what your hosting account allows.
6. Isolate a plugin-caused fatal by renaming wp-content/plugins, confirming the site loads, then renaming plugin subfolders back one at a time until the error returns — that's the plugin to update, replace, or leave off.
7. Restore the affected file from your last backup if a core or theme file was left corrupted by an interrupted update.
8. Clear disk quota if it's full — old backups, log files, and unused media in the uploads folder are usually the fastest space to reclaim.
9. Reproduce the original steps once you believe it's fixed, and check the raw log again to confirm it's genuinely silent, not just visually cleared by a cache.

When this needs professional help

Plenty of 500 errors — a bad .htaccess, an obvious plugin conflict — are realistic to resolve yourself with the steps above. It's worth bringing in a developer when:

• You don't have access to your host's raw error log, or can't make sense of what it's showing
• The cause turns out to be a genuine hosting resource limit, which needs either a plan upgrade or a conversation with your host that's easier coming from someone who knows what to ask for
• The error keeps coming back after every plugin or theme update, which usually means the real conflict was patched over rather than actually resolved
• You're not comfortable with FTP, file permissions, or reading a PHP fatal-error trace, and the site needs to be back up quickly
• wp-admin is one of the things down, so you can't use the normal dashboard tools to investigate at all

How I can help

A 500 error is one of the more stressful WordPress problems to land on, mostly because it can look total — front end and admin both down, no WordPress message to point anywhere. Over eleven years of WordPress and web development work, this is a failure I've traced through raw server logs more times than almost any other. I read the actual log first, isolate the exact file and line at fault, and apply the smallest fix that resolves it — not a fresh install or a full restore when the real cause is one corrupted file or one bad permission set.