Table of contents22
A WordPress 500 Internal Server Error means the server could not complete the request, so the page never loads. It is a server-side problem, not a problem with your browser, and the fix is to find the cause in the error log first, then work through the usual suspects in order: a broken .htaccess file, a plugin or theme conflict, the PHP memory limit, wrong file permissions, or corrupted core files.
Key takeaway: A 500 error means the server could not finish the request. Check the error log first — it usually names the file or plugin behind the failure — then fix one thing at a time, starting with .htaccess, and test the site after each change.
Contents
- What a 500 error means — and what it is not
- Match the symptom to the cause
- Before you change anything: back up first
- Fix it in order: 7 steps
- Post-fix checklist
- FAQs
What a 500 error means — and what it is not
The number 500 is an HTTP status code. When a server sends it, it is saying that something went wrong on its side while handling the request, and it cannot be more specific. The page you asked for never reaches the browser, so you see a plain message instead: “500 Internal Server Error”, or in some browsers “The page isn’t working” or “HTTP ERROR 500”.
That vagueness is the hard part. A 500 error does not name the cause, and the same message can come from a bad line in .htaccess, a plugin that crashed, a memory limit, wrong file permissions, or a damaged core file. The only way to stop guessing is to read the error log, which is Step 1 below.
It also helps to know what a 500 error is not. It is not a 404: the page exists, the server simply could not build it. It is not a 403: nothing is forbidding access. It is not the database connection error, which shows its own message, and it is not the white screen of death, which is a blank page with no error code. And it is not your browser: clearing your cache will not fix a 500 error, because the failure happens before the page is sent.
A 500 error can cover the whole site, including wp-admin, or it can appear on one page or one action only, such as saving a post or opening the checkout. Which pages fail is itself a clue, and the table below turns that clue into a starting point.
Match the symptom to the cause
Use this table to pick the step to start with. If two rows fit, start with the one that matches what changed most recently.
| What you see | Likely cause | Check first |
|---|---|---|
| The error is on every page, including wp-admin | Corrupt .htaccess or damaged core files | Step 2, then Step 6 |
| It started right after installing or updating a plugin | Plugin conflict | Step 3 |
| It started right after changing or updating the theme | Theme conflict | Step 3 |
| The log says “Allowed memory size exhausted” | PHP memory limit reached | Step 4 |
| It started after moving hosts or changing permissions | Wrong file or folder permissions | Step 5 |
| Only one page or one action fails | The plugin or code behind that page, or a timeout | Step 1, then Step 3 |
| The error comes and goes, often at busy times | Server resource limits | Step 7 |
Before you change anything: back up first
Before you change any file or database setting, make a full backup — your files and your database. Every fix below is reversible, but only if you can put things back. A backup turns a wrong guess into a five-minute restore instead of a rebuild.
If wp-admin still opens, use your backup plugin or your host’s backup tool. If the whole site is down, you can still back up: download the site’s files through your host’s File Manager or FTP, and export the database through phpMyAdmin in your hosting panel. Store the backup somewhere other than the server itself, so a server problem cannot take the backup with it.
If you cannot make a backup right now, do the read-only steps first — reading the error log (Step 1) changes nothing — and make the backup before you rename or edit any file.
Fix it in order: 7 steps
Work in this order. The steps are arranged from the quickest check to the deepest fix, and the error log in Step 1 may let you jump straight to the step that fits.
Step 1: Check the error log and find the cause
The error log is the one place that names the cause. Many hosts show it in the hosting panel under “Errors”, “Error Log” or “Logs”, and many servers also write an error_log file in the site’s root folder or in wp-admin. Open the newest entries and look for lines marked “Fatal error” — the line usually names the file that failed, such as a plugin file, and the reason, such as running out of memory or calling a function that does not exist.
If the log is empty or you cannot find it, turn on WordPress debug logging. In wp-config.php, above the line that says “That’s all, stop editing!”, add these three lines:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Then load the broken page once and open wp-content/debug.log. The newest fatal error at the end of the file is the cause. When you have the answer, turn debugging off again by setting WP_DEBUG and WP_DEBUG_LOG to false — a live debug log can grow large and can expose file paths, so do not leave it on.
Common log lines and what they mean: “Allowed memory size exhausted” points to Step 4. A fatal error naming a file inside wp-content/plugins points to Step 3. A line about .htaccess or a rewrite rule points to Step 2. A “Permission denied” line points to Step 5.
Step 2: Fix a broken .htaccess file
A single bad rule in .htaccess can break every page on the site, and .htaccess is the first file to suspect when the error covers the whole site. Using your host’s File Manager or FTP, find .htaccess in the site’s root folder — the same folder that holds wp-config.php — and rename it to .htaccess_old. Then reload the site.
If the site loads, .htaccess was the problem. Go to Settings > Permalinks in the dashboard and click Save Changes without changing anything. WordPress writes a fresh, default .htaccess for you. If the site still shows the error, rename the file back to .htaccess and move on to Step 3 — the file was not the cause.
The WordPress default looks like this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressIf your old .htaccess had extra rules from a security or redirect plugin, add them back one at a time and test after each one, so you can see which rule breaks the site.
Step 3: Find the plugin or theme causing it
A plugin or theme can trigger a 500 error when it crashes during loading — often right after an install or an update. If you can still open the dashboard, go to Plugins, deactivate all of them, and reload the site. If the error is gone, reactivate the plugins one by one, reloading the site after each one, until the error comes back. The last plugin you reactivated is the cause: leave it off, check for an update, or replace it.
If you are locked out of wp-admin, use FTP or File Manager instead. Rename the wp-content/plugins folder to plugins_old. That deactivates every plugin at once. If the site loads, rename the folder back to plugins, then rename each plugin’s folder inside it one at a time, reloading the site after each rename, until the error returns. The folder you just renamed holds the faulty plugin.
If the error started after a theme change, switch to a default WordPress theme such as Twenty Twenty-Five. In the dashboard, go to Appearance > Themes and activate the default theme. If you cannot reach the dashboard, rename the active theme’s folder inside wp-content/themes — WordPress then falls back to a default theme automatically.
Step 4: Raise the PHP memory limit
WordPress runs on PHP, and PHP is given a fixed amount of memory. When a plugin, a large page or an import asks for more, PHP stops with a fatal error, and the browser shows a 500. The log line to look for is “Allowed memory size of … bytes exhausted”.
To raise the limit, add this line to wp-config.php, above the line that says “That’s all, stop editing!”:
define( 'WP_MEMORY_LIMIT', '256M' );Save the file and reload the site. If the error stays, your host may cap the limit below 256M — check the PHP settings in your hosting panel, or ask your host to raise the limit. Raising the limit only helps when memory is the cause; if the log shows a different fatal error, the limit is not the problem.
While you are in the hosting panel, also check the PHP version. A plugin that needs a newer PHP version can crash on an old one, so keep PHP reasonably up to date — your host’s panel usually shows the version and lets you change it. Change it on a staging copy first if you have one, and back up before you change it.
Step 5: Correct file and folder permissions
WordPress needs to read its own files. If permissions are too strict, PHP cannot read a file it needs and the request fails with a 500. The standard permissions are 755 for folders and 644 for files, and wp-config.php is usually 640 or 644. Permissions of 777 — full access for everyone — are never needed and are a security risk, so do not use them as a fix.
To correct permissions, use FTP or your host’s File Manager: set folders to 755 and files to 644, starting with the site’s root folder, wp-admin and wp-includes. Most FTP programs let you set permissions for a whole folder and its contents in one step — right-click the folder, choose file permissions, and apply the value to all files and folders inside it. Then reload the site.
Wrong permissions often appear after a migration, a restore, or a file edit on the server, so if the error started after one of those, this step is a likely fix.
Step 6: Replace corrupted core files
If the error log points at a file inside wp-admin or wp-includes, or the error survives Steps 2 to 5, a core WordPress file may be damaged — for example by a failed update or a bad edit. Replacing the core files is safe, because your content, themes, plugins and uploads live elsewhere.
Download a fresh copy of WordPress from wordpress.org and unzip it. Using FTP or File Manager, replace the wp-admin and wp-includes folders on the server with the fresh copies, and replace the files in the site’s root folder — except wp-config.php, which holds your database details and must stay. Do not touch the wp-content folder: it holds your themes, plugins and uploads.
Reload the site after the replacement. If the error is gone, the damaged file is fixed; if it stays, the cause is in wp-content or on the server, and Step 7 is next.
Step 7: Check hosting and server limits
If the error comes and goes, appears only at busy times, or survives every step above, the cause is on the server rather than in WordPress. Check your host’s status page for an ongoing incident, and look in the hosting panel for resource usage — a site that has hit its CPU or memory limit will fail some requests and serve others, which matches an error that appears and disappears.
When you contact your host’s support, give them three things: the exact time the error appeared, the address of a page that fails, and the newest lines from the error log. With those, support can see whether the failure is a server limit, a server-side rule blocking the request, or a misconfigured service on their side. If the host confirms a limit on your plan, the fix is to raise the plan’s limits or move to hosting that fits the site’s traffic.
Post-fix checklist
Do not stop at the first page that loads. Run through this list before you call the error fixed:
- The homepage loads in a private browser window with no error.
- The page that failed now loads, and so does wp-admin — log in to confirm.
- The site loads on a second device or browser.
- The error log shows no new fatal errors after you reload the pages.
- Debug mode is turned off again (WP_DEBUG and WP_DEBUG_LOG set to false).
- .htaccess is the WordPress default, or contains only rules you can explain.
- All plugins are reactivated except the one that caused the error, if you found one.
- File permissions are 755 for folders and 644 for files.
- A fresh backup was taken after the fix, so the working state is saved.
FAQs
What causes a 500 internal server error in WordPress?
A 500 error means the server could not complete the request. In WordPress the usual causes are a corrupt .htaccess file, a plugin or theme that crashes while loading, the PHP memory limit being reached, wrong file permissions, damaged core files, or a server-side limit. The error log names the actual cause for your site.
How do I get rid of a 500 internal server error fast?
The two quickest reversible checks are renaming .htaccess and deactivating all plugins. Either takes a minute, and either can bring the site back at once. Then read the error log to find the real cause, so the error does not come back the next time the same code runs.
Will a 500 error fix itself?
Sometimes. If the cause was a temporary overload on the server or a short incident at your host, the error can clear on its own. But if the cause is a plugin, a bad .htaccess rule or wrong permissions, the error stays until you fix it. If it clears and returns, treat it as a real problem and check the error log while it is happening.
Does a 500 error mean the site is down?
For visitors, yes: the pages cannot load, so the site is effectively down. The domain and the server may still be up — the failure is in building the page, not in reaching the server. That is why the fix happens on the site and the server, not in the visitor’s browser.
Can a 500 error delete my content?
No. The error stops pages from loading; it does not delete posts, pages or media. Your content stays in the database and your uploads stay in the wp-content folder. The fixes in this guide change files and settings, not content — and a backup before you start covers the unlikely case that a step goes wrong.
How do I find the exact cause of a 500 error?
Read the error log. The newest “Fatal error” line names the file that failed and the reason it failed. If the log is empty, enable WordPress debug logging with WP_DEBUG_LOG and read wp-content/debug.log after loading the broken page once. Guessing without the log usually costs more time than reading it.
What if the error is only on one page?
Then the cause is usually tied to that page: a shortcode, a block or a plugin that only runs there, or a request that times out, such as a large import or a slow external call. Load the page once with debug logging on, then read the newest fatal error in wp-content/debug.log — it will point at the plugin or file behind that page.
Keep learning
If this fixed your 500 error, these guides cover the errors that usually come next: WordPress Too Many Redirects: How to Fix It walks through redirect loops step by step; Error Establishing a Database Connection in WordPress: How to Diagnose It and Fix It covers the database error; What to Do When WordPress Gets Stuck in Maintenance Mode covers the maintenance-mode lock; Can’t Log In to WordPress Admin? How to Fix It Step by Step covers login failures; and WordPress Not Sending Emails: How to Diagnose It and Fix It Step by Step covers email problems. For the skills behind this fix, see How to Fix Block Validation Failed Errors in WordPress, Troubleshoot WordPress Plugin Conflicts, Secure wp-config.php: The Complete Guide, WordPress File Permissions Security Guide, and WordPress Backup Failed: Causes and Fixes That Work.
If the 500 error left you staring at a blank page instead of an error message, the cause is often the same kind of crash — start with WordPress White Screen of Death: How to Diagnose It and Fix It Step by Step, which uses the same error-log-first method to bring a blank site back.
