WordPress
How to fix the WordPress 500 Internal Server Error (step by step)

Short answer
The WordPress 500 Internal Server Error is a generic HTTP status code that means the server couldn’t complete your request, without saying why; unlike a blank white screen, your browser shows this message directly. The most common cause is a corrupted .htaccess file,
followed by a tight PHP memory limit and plugin or theme conflicts.. Instead of panicking, start with the easiest, most reversible step: back up first, regenerate .htaccess, then eliminate the PHP memory limit and plugins one at a time until you find the source.
What the WordPress 500 Internal Server Error actually is
A 500 Internal Server Error isn’t specific to WordPress, it’s the standard way a server says “something went wrong, and I won’t give you details.” That’s why, every time this error shows up, the root cause can differ, but in practice the list of usual suspects is short:
- A corrupted
.htaccessfile, or one with rules that no longer parse - A PHP memory limit lower than what the site actually needs
- A plugin or theme that was just updated and doesn’t get along with your PHP version
- Core WordPress files that are missing or corrupted
- A server-side resource quota being exceeded, or a timeout limit being hit
What these all have in common is that they almost always follow an update, a new plugin install, or a hosting change. Which is why the first question is always “what changed most recently?” Framing the problem this way gets you to the answer far faster than trying fixes at random.
How to fix WordPress 500 Internal Server Error, step by step
There’s no single fix, because the error can come from several layers of your stack. Work through the steps below in order, starting with the easiest and most reversible one.
Back up before you touch anything
The first instinct when you hit the WordPress 500 Internal Server Error is often to delete or change files quickly, which can make things worse instead of better. Before changing anything, use your file manager or FTP client to copy .htaccess, wp-config.php and, if you can, the database. This step means that if you make the wrong call while fixing it, you can always undo it. Even if your host runs automatic backups, taking your own copy of the current state costs a few minutes and removes the risk entirely.
Regenerate your .htaccess file
This is, in practice, the single most frequently resolved case: a corrupted .htaccess file stops the server from processing the request at all. Back up the existing file and delete it, then open Settings → Permalinks in the WordPress dashboard and click “Save Changes” without changing anything. WordPress regenerates a standard .htaccess file for you. If you can’t reach the dashboard, delete the file via FTP and write the standard block by hand instead:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
If the site comes back, that was the whole problem. If it doesn’t, move to the next step.
Check your PHP memory limit
Sometimes the WordPress 500 Internal Server Error happens with no corrupted file at all: PHP simply can’t allocate as much memory as the site needs. You can raise the limit by adding this line to wp-config.php:
Define( 'WP_MEMORY_LIMIT', '256M' );
On shared hosting this can run into a server-wide PHP limit that overrides it; if that happens, raise the PHP memory value from your host’s control panel, or ask their support team to do it for you.
Turn on debug mode and read the logs
The frustrating part of a 500 error is that it often happens earlier than WordPress’s own debug layer, which is why WP_DEBUG doesn’t always help. Still worth trying:
Define( 'WP_DEBUG', true );
Define( 'WP_DEBUG_LOG', true );
Define( 'WP_DEBUG_DISPLAY', false );
If wp-content/debug.log shows a line starting with “Fatal error,” the responsible file is now obvious. If there’s nothing there, check your hosting panel’s server error log instead (often just called error_log). Most of the time, the real cause of the 500 error shows up there, because the problem occurred before PHP itself, at the web server layer.
Which plugin is causing the problem?
If the steps above didn’t resolve it, the reliable, low-tech method is to test plugins individually. Using FTP or a file manager, go to wp-content/plugins and temporarily rename the folder (to something like plugins-old). WordPress can’t find the folder, treats every plugin as deactivated, and the site usually comes back.
Rename the folder back, then reactivate plugins one by one from the dashboard, checking the site after each one. Once the error reappears, you’ve found the plugin responsible: update it, look for an alternative, or contact the developer.
Switch to a default theme and test
If plugins check out clean, the theme is next. If you don’t already have a current WordPress default theme (something like Twenty Twenty-Four) in wp-content/themes, download and install one. Then temporarily add this line to wp-config.php:
Define( 'WP_DEFAULT_THEME', 'twentytwentyfour' );
If the site comes back, the problem sits in your active theme: most likely a functions.php file broken by an update, or an incompatible add-on.
Check your PHP version and core files
An older plugin or theme can fall out of step with a newer PHP version your host has rolled out, and the reverse also happens. Check the PHP version in your hosting panel and confirm it falls within the range the current WordPress version supports. If none of the steps above worked, core files may be corrupted: download a fresh copy of WordPress from wordpress.org and re-upload only the wp-admin and wp-includes folders via FTP, without touching your content or configuration files.
When should you contact your host?
If nothing above resolves it, the issue is probably server-side: a resource quota being exceeded, a timeout limit, or a server configuration problem. Contact your hosting provider’s support team and clearly describe what you’ve tried and what the server error log showed; that gets it resolved faster. If you want to learn to read server logs yourself, our guide to essential SSH and Linux commands walks through accessing and reading log files step by step.
Avoiding it next time
The WordPress 500 Internal Server Error is largely preventable. Test plugin and theme updates on a staging environment first. Keep a regular backup routine, remove plugins you no longer use, and stay within a supported PHP version range; together, these meaningfully cut your odds of hitting it again. Our guide to the WordPress white screen of death covers a closely related failure mode: the two errors often come from the same update or plugin conflict.
For an up-to-date, official reference on the WP_DEBUG constants, WordPress’s own Advanced Administration Handbook, Debugging in WordPress is worth bookmarking.
Next step
Worked through in the right order, the WordPress 500 Internal Server Error is usually something you can fix yourself with careful file changes. But when the cause keeps recurring or sits on the server side, bringing in professional help is the safer choice for both your time and your data. If you’re weighing up ongoing technical maintenance for a WordPress site, or moving it to sturdier architecture, our group company Web Tasarım Ofisi supports WordPress builds and technical troubleshooting.
To talk through your site’s technical setup or a custom software need, take a look at our custom software service or get in touch with Argo Ajans.
Frequently asked questions
Does the WordPress 500 Internal Server Error cause data loss?
No, the error usually means the server failed to complete the request; no file or database is deleted by it. Still, backing up before touching .htaccess or wp-config.php means a wrong move is always reversible.
What is the most common cause of the WordPress 500 Internal Server Error?
A corrupted or misconfigured .htaccess file is the single most common trigger in practice. Regenerating it from Settings → Permalinks is usually the first thing worth trying.
Why does a 500 error still show up with WP_DEBUG turned on?
The WordPress 500 Internal Server Error often happens before WordPress code even starts running, at the server or .htaccess layer, so WP_DEBUG catches nothing. If debug.log stays empty, assume the problem sits below PHP, at the server level.
How do I find out which plugin is causing the problem?
Temporarily rename the wp-content/plugins folder via FTP or a file manager to deactivate every plugin at once, then reactivate them one by one from the dashboard, checking the site after each one.
What should I do if I can't fix it myself?
Share the exact line from debug.log and the server error log, along with the steps you've already tried, with your hosting provider's technical support team — if the cause is a resource quota or server configuration, that information speeds up the fix.