How to Fix the 500 Internal Server Error in WordPress (Full Guide)

Your site was fine ten minutes ago. Now there's a blank page, a scary-looking message, and zero explanation. That's the 500 internal server error in WordPress in a nutshell — vague, sudden, and somehow always at the worst possible time.

Here's the good part: in most cases you can fix this in under fifteen minutes, without touching a line of PHP you don't understand. This guide walks through the causes in the order you should actually check them, not the order that looks impressive in a listicle.

What Exactly Is a 500 Error, and Why Does WordPress Get It So Often?

A 500 status code just means the server ran into a problem it couldn't identify. Not a missing page (that's a 404). Not a permissions block (that's a 403). Something broke on the server's side, and it's not telling you what.

WordPress is unusually prone to this because there's a lot happening under the hood every time a page loads — PHP scripts firing, a database query running, a theme and a stack of plugins all trying to execute their own code at once. One typo in a plugin file, or a script that asks for more memory than your host allows, and the whole request collapses.

Three days. That's roughly how long a poorly-coded plugin update sat live on a client site before anyone noticed the pattern — five 500 errors a day, always right after the WooCommerce cron job ran. Small detail, but it's the kind of thing that only shows up once you start reading logs instead of guessing.

Quick Diagnosis: What Your Specific Error Message Is Telling You

The wording changes depending on your browser, your server software, and whether a CDN sits in front of your site. You might see "HTTP ERROR 500," a plain "Internal Server Error," or a longer sentence about the server being unable to complete the request. Same underlying issue in all three cases.

Worth separating this from three lookalikes. The White Screen of Death is a blank page with literally nothing on it — often a PHP fatal error rather than a server-level failure. "There Has Been a Critical Error on This Website" is WordPress's own friendlier wrapper around a PHP error. And if the message specifically says something about establishing a database connection, that's a MySQL problem, not a 500 — different fix entirely.

Can you still reach /wp-admin? That matters. If yes, you have options — deactivate plugins from the dashboard, switch themes, check the health tool. If the admin area is also dead, you're working through FTP or your host's file manager instead. Either way is fixable.

Fix 1 — Reset a Corrupted .htaccess File

Start here. A damaged .htaccess file is the single most common trigger for this error, and resetting it takes about two minutes.

1. Connect via FTP or your host's file manager and find .htaccess in your site's root folder — same directory as wp-admin and wp-content.
2. Rename it to .htaccess_old and reload your site. Error gone? You found your culprit.
3. Log into WordPress, go to Settings → Permalinks, and click Save without changing anything. WordPress generates a fresh .htaccess automatically.

Only relevant if you're on Apache. Nginx doesn't use .htaccess at all, so skip straight to the next fix if that's your setup.

Fix 2 — Raise the PHP Memory Limit

Didn't work? Next likely suspect: memory. Scripts and plugins ask WordPress for a certain amount of PHP memory, and if your hosting plan won't give it to them, the request fails with — you guessed it — a 500.

Add this line to wp-config.php, just above the line that says "That's all, stop editing":

define('WP_MEMORY_LIMIT', '256M');

If you have server-level access, you can also add these to .htaccess: php_value memory_limit 256M alongside max_execution_time 300. Save, refresh, and see what happens. Some hosts cap memory at the account level regardless of what you set in WordPress — if that's the case here, this step alone won't fix it, and that's a conversation to have with your host, not your code.

Fix 3 — Deactivate Plugins and Switch Themes

Plugin conflicts cause a large share of these errors. Sometimes it's an update that shipped a bug. Sometimes it's two plugins fighting over the same hook.

If you can reach the dashboard, deactivate all plugins from Plugins → Installed Plugins, reload the site, then reactivate them one at a time until the error reappears. That last one is your problem plugin.

No dashboard access? FTP into wp-content and rename the plugins folder to something like plugins-disabled. Reload. If the site comes back, rename it back and then disable plugins individually by renaming their subfolders instead, one by one, until you isolate the offender.

Switching themes works the same way — activate a default theme like Twenty Twenty-Five temporarily and see whether the error clears.

Fix 4 — Reinstall WordPress Core Files

Corrupted core files aren't common, but they happen — a failed update, an interrupted upload, occasionally a hack. Reinstalling replaces the core files without touching your content or settings.

Go to Dashboard → Updates and click "Re-install Now" if the option is present, or download a fresh copy of WordPress from wordpress.org and upload the wp-admin and wp-includes folders over your existing ones via FTP. Leave wp-content alone; that's where your themes, plugins, and uploads live.

Fix 5 — Check File and Folder Permissions

Wrong permissions block the server from reading files it needs, and that surfaces as a 500 too. The safe defaults are 755 for folders and 644 for files. Avoid 777 entirely — it's a security risk, and some servers will actually reject a 777 request and throw the error themselves.

Most FTP clients let you right-click a file or folder, choose "File permissions," and set the numeric value directly. Check your root directory first, then wp-content and its subfolders if the problem persists.

Fix 6 — Turn On WP_DEBUG and Read the Log

Guessing gets old fast. This is the fix that actually tells you what broke, instead of you cycling through the list hoping one sticks.

Add these two lines to wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Reload the page that's erroring, then open /wp-content/debug.log. The last few lines usually name the exact file and line number where things went wrong. Turn debugging back off once you've found and fixed the issue — leaving it on in production isn't something you want visitors to see.

Fix 7 — Rule Out a PHP Version Conflict

Some plugins simply won't run on certain PHP versions. If the error started right after a hosting-side PHP update, or right after you changed it yourself, this is worth checking before anything more invasive.

Most hosting panels have a PHP version selector — hPanel, cPanel's MultiPHP Manager, or something similar depending on your host. PHP 8.1 or 8.2 is a safe, well-supported target for current WordPress. And if switching versions triggers the error, that tells you something useful on its own: drop back one version, confirm the site works, then track down which plugin needs updating before you try again.

When It's Not Even WordPress's Fault

Sometimes none of the above changes anything, because the problem isn't on your server at all. If you're behind Cloudflare or another CDN, the 500 can originate at the edge layer rather than your origin server.

A quick way to check: temporarily bypass the CDN (or check its status page) and see if the site loads directly. Loads fine without the CDN but breaks through it? The issue is upstream, not in your WordPress installation, and no amount of plugin-disabling will touch it. Large infrastructure incidents also happen — rare, but when a major CDN or cloud provider has an outage, a lot of unrelated sites throw the same error at the same time. Checking the provider's status page before you touch anything can save you an afternoon of pointless troubleshooting.

A Real-Looking Example: Tracing a 500 Error Start to Finish

Illustrative scenario — not an actual incident, but a realistic composite of how this usually plays out.

Picture a small online store — call it "Maren's Pottery Studio" — running WooCommerce on shared hosting. The owner updates a shipping-calculator plugin on a Tuesday morning. By 9:47 AM the checkout page starts throwing 500 errors, but the homepage still loads fine.

She tries reloading. Nothing. Clears her browser cache. Still nothing. Enables WP_DEBUG, checks debug.log, and finds a fatal error pointing to the shipping plugin's new file — it's calling a PHP function that only exists in 8.1+, and her hosting account is still on 7.4. Bumping the PHP version through her host's panel resolves it in about ninety seconds. Total downtime: 41 minutes, most of which was spent trying random fixes before she thought to check the log first.

That last part is the pattern worth remembering. Debug logs first. Guesswork second.

Keeping This From Happening Again

A few habits cut the odds of hitting this error dramatically:

• Keep automated backups running — daily, not "whenever I remember."
• Update plugins one at a time on a staging site before touching production.
• Stay on a supported PHP version (8.1 or newer).
• Check error logs periodically, not just when something's already broken.

None of this is glamorous. It's also the entire difference between a five-minute fix and a five-hour panic.

Questions People Keep Asking

Will I lose my content when I see a 500 error?
Almost never. Your posts, pages, and media live in the database, which this error rarely touches. The 500 is a block preventing WordPress from being reached — not data loss.

Does a 500 error hurt my SEO?
A brief one, probably not — Google is fairly forgiving of short blips. Left unresolved for hours, though, it can signal a real problem and affect crawling and rankings.

Is this the same as a 503 error?
No. A 503 is what WordPress uses for maintenance mode and tells search engines to check back later. A 500 has no such polite framing — it's just broken.

I fixed it once and it came back a week later. Why?
That usually means the underlying cause — a plugin, a resource limit, a recurring cron job — never actually got resolved, just temporarily patched. Worth digging into debug.log again rather than repeating the same quick fix.

Do I need a developer for this?
For most cases, no. The steps above use FTP and a text editor. If you've gone through all seven fixes and it's still broken, that's the point where bringing in your host's support team or a developer actually saves time.

Key Takeaways

• A 500 error is server-side and generic — it won't tell you the cause directly.
• Corrupted .htaccess and low PHP memory account for a large share of cases, and both take minutes to check.
• WP_DEBUG is the fastest way to stop guessing and start reading the actual error.
• Not every 500 originates on your server — CDN and hosting-side limits can cause the identical symptom.
• Prevention (staging, backups, PHP version hygiene) matters more than any single fix.

Got a 500 error open in another tab right now? Start with the .htaccess reset — it resolves more cases than any other single step on this list, and it costs you nothing if it turns out to be something else.