How to Fix a WordPress 500 Internal Server Error (2026)

A wordpress 500 error usually traces back to a corrupted .htaccess file, an exhausted PHP memory limit, or a plugin or theme conflict. Start with the safest checks (reload the page, clear cache, regenerate .htaccess) before touching plugins, themes, or core files, and back up your site before any step that changes files.

Most sites recover within minutes once the cause is isolated. Work through the checks below in order: the first group is completely reversible and needs no backup, while the second group changes files or configuration and should only be attempted after you have a current backup. If you see WordPress’s own on-screen message reading “There has been a critical error on this website,” you’re dealing with a different, PHP-level issue, covered in a separate guide linked below rather than here.

What is a WordPress 500 error?

A 500 internal server error is a generic, server-side failure code. It means the web server tried to process your request and something went wrong, but the server couldn’t identify the specific problem well enough to return a more precise error. Unlike WordPress’s branded error screens, an http error 500 wordpress case often shows a bare, unstyled page (sometimes just the words “500 Internal Server Error”) because WordPress itself never finished loading far enough to render its own error handling.

The MDN HTTP 500 status code reference describes it as a catch-all response for unexpected server conditions, which is exactly why a wordpress site can return the same http 500 status code for a dozen unrelated problems, from a bad rewrite rule to a maxed-out memory limit. Some hosts return a bare http 500 response with no page content at all.

Because the message is so generic, the fix depends entirely on isolating the cause first. That’s the difference between this guide and a simple restart: the safe-first-checks and step-by-step fix path below are ordered specifically to surface the cause with the least risk to your site.

500 error vs. WordPress critical error: which one do you have?

These two errors look similar but come from different layers of your stack, and mixing up the fix wastes time. A plain 500 internal server error wordpress case, the kind this guide covers, is typically a server or configuration-level failure: a bad .htaccess rule, a memory ceiling, or the web server itself rejecting the request. It rarely shows any WordPress-branded messaging at all.

If your screen instead shows WordPress’s own message, “There has been a critical error on this website,” that’s a PHP-level fatal error inside WordPress code itself (usually a fatal error in a theme or plugin file), and it needs a different diagnostic path. GEENXT covers that scenario in a dedicated guide: WordPress critical error. This page owns the server-side 500/5xx case specifically; use the critical-error guide when you see WordPress’s own error banner.

Common causes of a wordpress 500 error

• Corrupted .htaccess file: a broken rewrite rule or malformed directive in the root .htaccess file is one of the most frequent triggers.
• PHP memory limit exhausted: a plugin, theme, or import process asks for more memory than your hosting’s php memory limit allows.
• Plugin or theme conflict: a recently updated or incompatible plugin/theme throws an error the server can’t recover from.
• Corrupted WordPress core file: an interrupted update or a failed file transfer can leave a corrupted wordpress core file behind.
• Incompatible PHP version: a plugin built for a newer or older PHP release than your server runs.
• Server-level issue: a hosting outage, resource limit, or misconfiguration outside WordPress itself.

Safe first checks (start here, no backup needed)

These checks change nothing on your server and can’t make things worse. Work through them before touching any files.

1. Reload after a minute. A temporary server overload or a brief hosting hiccup often clears itself.
2. Clear your browser cache and cookies, then reload in a private/incognito window to rule out a stale local cache.
3. Check your host’s status page for an active outage before assuming the fault is in your wordpress installation.
4. Regenerate your .htaccess file. Log in to your wordpress dashboard, go to Settings > Permalinks, and click Save Changes with no other edits. This rewrites a clean .htaccess and resolves a large share of 500 errors on its own.

Step-by-step fix path (increasing risk, back up first)

If the safe checks above didn’t resolve it, back up your site (files and database) before continuing. Each step below changes something on your server; work through them in order and re-test after each one.

1. Deactivate all plugins. If you can reach wp-admin, deactivate every plugin at once from the Plugins screen, then reload the site. If the 500 error is gone, reactivate plugins one at a time until it returns, isolating the culprit. If your wordpress admin is locked out, connect via FTP/SFTP and rename the /wp-content/plugins folder (e.g. to plugins-disabled) to deactivate everything, then rename it back once you’ve identified the conflict.
2. Switch to a default WordPress theme. Activate Twenty Twenty-Four or another default theme via FTP by renaming your active theme’s folder if the admin is inaccessible. If the error clears, the problem is in your theme’s code.
3. Increase your PHP memory limit. Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php just above the line that reads /* That's all, stop editing! */. This raises the php memory limit available to WordPress without touching server-wide PHP settings, and clears a common memory limit error caused by memory-hungry plugins or large imports.
4. Check your PHP version. In your hosting control panel, confirm you’re running a PHP version your plugins and theme actually support; an outdated or too-new version of wordpress’ PHP runtime is a common, overlooked cause.
5. Re-upload WordPress core files. Download a fresh copy of WordPress from wordpress.org matching your current version, then re-upload the wp-admin and wp-includes folders via FTP (never overwrite wp-content or wp-config.php). This replaces any corrupted wordpress core file without touching your content, plugins, or settings.

How to check your error logs

Your error log will usually name the exact file and line causing the wordpress 500 internal server error, saving you from guessing through the steps above blind. WordPress’s own Debugging in WordPress documentation covers the full set of debug constants if you need more than the two below. Two places to look:

• WordPress’s own debug log: add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php, reproduce the error, then check wp-content/debug.log for the most recent entries.
• Your host’s server-level error log: most hosting control panels (cPanel, Plesk, or a managed-host dashboard) expose a raw PHP or Apache error log separate from WordPress, usually under a section labeled “Error Log” or “Metrics.” This log can show server error logs that never reach wp-content/debug.log, including PHP fatal errors and server-level failures.

Turn debug logging off again once you’ve found the cause; leaving it on exposes error message detail to anyone who can reach your site’s files.

When to contact your host or developer

If the wordpress 500 error persists after working through every step above, the cause is likely outside WordPress entirely: a server resource limit, a misconfigured server module, or a hosting-side issue that needs someone with server access. Contact your host or a WordPress support team, and send them the exact timestamp of the error, the relevant excerpt from your error log, and a note on the last change you made (a plugin update, a theme switch, a migration) before it started.

Prevention checklist

• Test plugin and theme updates on a staging site before applying them live.
• Keep at least one recent, verified backup of your wordpress website on a rolling schedule.
• Monitor your php memory limit headroom, especially before large imports or migrations.
• Keep WordPress core, plugins, and your theme updated on a regular cadence rather than in large batches.
• Review your .htaccess file after any manual server or permalink changes.

For the full emergency checklist covering other WordPress failure modes, see GEENXT’s WordPress emergency fixes hub.

GEENXT data point

GEENXT’s July 2026 keyword research found the wordpress 500 error cluster (five closely related queries, including error 500 wordpress and 500 internal server error wordpress) carries 1,000 combined monthly searches, all rated at keyword difficulty 0 to 1, meaning genuinely low competition for a high-intent, in-the-moment troubleshooting query.

Frequently asked questions

How do I fix a 500 internal server error on WordPress?

Start with the safe checks: reload the page, clear your cache, and regenerate .htaccess via Settings > Permalinks. If those don’t work, back up your site, then deactivate plugins, switch to a default theme, raise your PHP memory limit, or re-upload core files, testing after each change.

What causes a 500 internal server error in WordPress?

The most common causes are a corrupted .htaccess file, an exhausted PHP memory limit, and plugin or theme conflicts. Less commonly, a corrupted wordpress core file, an incompatible PHP version, or a server-level issue on your host’s end is responsible.

Is a 500 internal server error my fault, or is it a server issue?

It can be either. A recent plugin update, theme change, or file edit on your end is the more common trigger, but a hosting-side resource limit or misconfiguration can cause the exact same error with no changes on your part. Checking your error logs is the fastest way to tell which applies to your case.

Can plugins or themes cause a WordPress 500 error?

Yes. A plugin or theme that throws a fatal error, requests more memory than your server allows, or writes a bad rule into .htaccess during activation is one of the most frequent causes, which is why deactivating plugins one at a time is an early step in the fix path above.

How do I check error logs to diagnose a WordPress 500 error?

There are two logs worth checking, and they usually point straight at the cause. First, enable WordPress’s own debug logging by adding define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php, reproduce the error, then open wp-content/debug.log and look at the most recent entries for a named file, function, and line number, which pinpoints the exact php error causing the failure. Second, check your host’s server-level error log, usually found in your hosting control panel (cPanel, Plesk, or a managed-host dashboard) under a section labeled “Error Log” or “Metrics.” This second log can catch server-level and PHP fatal errors that never make it into WordPress’s own debug log, which matters because a plain 500 error, unlike a WordPress critical-error banner, often happens before WordPress loads far enough to log anything itself. Once you’ve identified and fixed the cause, turn debug logging back off, since leaving it enabled exposes internal file paths and error detail to anyone who can view your site’s raw output.

How can I prevent 500 internal server errors on my site?

Test updates on staging before pushing them live, keep a current backup on a rolling schedule, watch your PHP memory limit headroom before large imports, and update core, plugins, and your theme on a steady cadence instead of in large, infrequent batches. Reviewing .htaccess after any manual server change also catches a common trigger before it causes downtime.