Your site was working yesterday. Today every page shows the same blunt message: 500 Internal Server Error. No helpful detail, no clue about what broke — just a dead site. If you need to fix WordPress 500 internal server error problems, the good news is that the cause is almost always one of a small handful of things, and you can work through them in order without guessing.
In this guide you will learn what the error actually means, how to find the real cause in your error log, and how to fix it step by step — starting with the quickest checks first.
What a WordPress 500 Error Actually Means
A 500 error is a generic HTTP status code. It means your server hit an unexpected condition while running your site’s PHP code and could not complete the request. Unlike a 404, which tells you a page is missing, a 500 deliberately hides the detail. That vagueness is by design: servers do not expose internal errors to visitors.
On WordPress sites, the usual suspects are a corrupted .htaccess file, a plugin or theme conflict, an exhausted PHP memory limit, incorrect file permissions, an incompatible PHP version, or damaged core files. The error often appears right after a plugin update, a theme change, a migration, or a hosting-side PHP upgrade — that timing is your first clue.
Before You Touch Anything: Two Quick Safeguards
First, take a backup if you still can. If wp-admin is down too, use your hosting control panel’s backup tool or file manager to download wp-content and a database export before you edit files. Second, work on one change at a time and test the site after each step. If you change five things at once and the site comes back, you will never know which one fixed it — and the problem is likely to return.
Keep a note of every file you rename so you can undo it.
Step 1: Find the Real Cause in the Error Log
Guessing wastes time. The fastest route to a fix is the error log, which usually names the failing file and line.
- Check your hosting control panel for an Error Log section first — many hosts show the latest PHP errors there with no setup needed.
- If that shows nothing, enable WordPress debug logging. Open
wp-config.phpin your site root and add these lines above the “That’s all, stop editing!” comment:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
Reload the broken page once, then open wp-content/debug.log and look for the most recent “Fatal error” entry — it will typically name a plugin file, a theme file, or a memory exhaustion message, and tells you which step below to try first. When you are done, set WP_DEBUG back to false.
Step 2: Fix a Corrupted .htaccess File
When you fix WordPress 500 internal server error cases, start here: a corrupted .htaccess file is the most common single cause. Security and caching plugins write rules into it, and one bad rule can take down the whole site, including wp-admin.
- Connect via FTP or your host’s file manager and go to your site’s root folder (usually
public_html). - Enable “show hidden files” —
.htaccessstarts with a dot, so it is hidden by default. - Rename it to
.htaccess_oldand reload your site. - If the site loads, log in to wp-admin, go to Settings > Permalinks, and click Save Changes without changing anything. WordPress writes a fresh, clean
.htaccessfile for you.
The default WordPress rules look like this:
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
If the site still shows the error after renaming .htaccess, rename your backup back and move on — the cause is elsewhere.
Step 3: Rule Out a Plugin Conflict
If a plugin update triggered the error, that plugin is the prime suspect. If you cannot reach wp-admin at all, deactivate plugins from the file system instead.
- In
wp-content, rename thepluginsfolder toplugins_oldand reload the site. - If the site loads, a plugin is the cause. Rename the folder back to
plugins— WordPress will have deactivated every plugin in the process. - Reactivate plugins one at a time, reloading the site after each one, until the error returns. The last plugin you activated is the culprit.
- Leave that plugin deactivated, check whether an update or a replacement exists, and contact its developer with the fatal error line from your debug log if the problem persists.
If you know which plugin was just updated, start there: rename just that plugin’s folder inside wp-content/plugins and the site will often come straight back. Also check the admin inbox for a Recovery Mode email titled “Your Site is Experiencing a Technical Issue” — WordPress has sent one since version 5.2 when a plugin causes a fatal error.
Step 4: Test Your Theme
If plugins are not the cause, test the theme the same way. Rename your active theme’s folder inside wp-content/themes and reload the site; WordPress will fall back to a default theme if one is installed. If the error clears, the problem is in your theme — a recent update, a custom snippet in functions.php, or a PHP version incompatibility.
Step 5: Increase the PHP Memory Limit
When the debug log says “Allowed memory size exhausted”, your site is running out of PHP memory. Shared hosting plans often default to 64MB or 128MB, which is tight once you run a page builder, a caching plugin, and a few heavier plugins together.
Add this line to wp-config.php, above the “That’s all, stop editing!” comment:
define( 'WP_MEMORY_LIMIT', '256M' );
Reload the site. If it works, you have found your fix — but treat it as a clue too: if a site that ran fine on 128MB suddenly needs far more, a plugin may be consuming memory abnormally. If 256M is not enough, try 512M; beyond that, your hosting plan may simply be undersized. For a deeper walkthrough, see my guide on how to increase the WordPress memory limit.
Step 6: Check File Permissions, PHP Version, and Core Files
These matter most after a migration or a server move.
File permissions. Directories should be 755 and files 644, with wp-config.php tightened to 440 or 400. Permissions too tight for your host’s setup can block PHP from reading files it needs and produce a 500 error. Fix them from your FTP client or host file manager, applying recursively — but never use 777 on a live site.
PHP version. WordPress 6.x requires PHP 7.4 or higher, and most modern plugins now expect PHP 8.0 or above. If your host recently changed PHP versions, or a plugin update dropped support for yours, that mismatch can throw a fatal error. Check your version under Tools > Site Health > Info > Server once you can get in, or in your hosting panel.
Core files. If nothing above helped, download a fresh copy of WordPress and re-upload the wp-admin and wp-includes folders, overwriting the existing ones. Leave wp-content untouched — that is where your themes, plugins, and uploads live. For a second reference, see Loopia’s guide to the WordPress internal server error.
When to Contact Your Host
Contact hosting support when the error survives every step above, when the site fails intermittently under normal traffic, or when the log points to a server-level limit you cannot change — such as a ModSecurity rule blocking a legitimate request. Send them the exact fatal error line, what you already tried, and when the problem started. A host can check server logs that WordPress never sees.
How to Prevent the Next 500 Error
- Update one thing at a time, and check the site after each update — especially major plugin and PHP version updates.
- Test updates on a staging site first when your host offers one.
- Keep a current backup you have actually restored from at least once.
- Remove plugins you no longer use instead of leaving them deactivated.
- Keep Site Health and your PHP version from drifting years out of date.
A 500 error looks alarming because it says so little, but the fix is usually methodical rather than mysterious: read the log, test .htaccess, isolate plugins and theme, check memory and permissions, and only then look deeper. Work through the steps in order and change one thing at a time, and you can fix WordPress 500 internal server error issues in most cases without touching the database at all.
If your site is down and you would rather have a developer handle it, get in touch through my contact page — include the error message, when it started, and what changed last. You may also find my guides on fixing the WordPress white screen of death and fixing WordPress 404 errors useful if your site shows a different error next time.