A 500 error is the server shrugging
A 500 Internal Server Error is the vaguest message the web can give you. It means the server tried to handle the request, something went wrong on its side, and it has no more specific code to offer. Depending on the server and browser you may see a plain page reading “Internal Server Error” with a note that the server “encountered an internal error or misconfiguration”, a branded page from your host, or Chrome’s “This page isn’t working” with HTTP ERROR 500 underneath.
Unlike most WordPress messages, this one usually comes from the web server before WordPress has had a chance to say anything. That changes where you look. The useful detail sits in the server’s error log, not on the screen. If you are not sure which error you have, our guide to the common WordPress errors lays out how they differ, and if your page says “There has been a critical error on this website” instead, the critical error repair page is the one to read.
Where the 500 shows up tells you a lot
Before changing anything, spend two minutes noting the pattern. It narrows the field quickly.
- Every URL, including images and
/wp-admin/. Points to server configuration, often the.htaccessfile or a setting the host changed. - Only the dashboard, or only when saving. Often a plugin’s admin code, a timeout during a heavy task, or memory running out during an import or backup.
- Only one page or one product. A shortcode, block or template on that page is failing.
- Random, at busy times. The account is hitting a resource limit on shared hosting.
- Straight after an edit or install. Whatever was just changed is the first suspect.
The causes we find most often
A broken .htaccess file
On Apache and LiteSpeed servers, .htaccess in the site root holds the rewrite rules that make WordPress permalinks work, plus anything security, caching and redirect plugins add. One malformed line in that file and the server refuses every request with a 500. It is a classic result of a caching or security plugin writing rules the server does not support, or of someone pasting a redirect snippet by hand. Nginx servers do not read .htaccess at all, so on those this cause is ruled out.
PHP running out of memory or time
Each PHP request gets a memory ceiling and a time limit. A large import, a backup plugin or a bloated page builder page can go over either, and depending on how the server is set up, the result is a 500 rather than a WordPress message. The post on the “allowed memory size exhausted” error explains how memory limits are set and why raising them is not always the right fix.
A PHP fatal error the WordPress handler did not catch
WordPress normally catches fatal errors and shows its critical error screen. Errors that happen very early in loading, before that handler is ready, or on servers where it has been switched off, can surface as a bare 500 instead.
File and folder permissions
On some server setups, PHP refuses to run a file whose permissions are too open, and returns a 500. This tends to appear after files are uploaded with the wrong settings or after a migration. Typical WordPress values are 644 for files and 755 for folders, with tighter settings on wp-config.php; our article on WordPress file permissions covers what each one controls.
A change on the host’s side
A PHP version switch, a new security module, or a server move can each produce 500s across a site that nobody touched. If the error appeared overnight with no changes from you, ask the host what changed.
Safe first checks for a site owner
Whatever you try, start by keeping a copy of the current state: download the site files, and especially any file you are about to rename or edit. With a 500 error the database is rarely the problem, but export it too if the hosting panel allows, so you have a complete restore point.
- Find the server error log. Most hosting control panels have an “Errors” or “Logs” section. Open it straight after loading the failing page. Look for lines with the current time; they often name the file and the reason, such as an invalid command in
.htaccessor a PHP memory error. The walkthrough on finding and reading WordPress error logs explains what the common lines mean. - Test the .htaccess file. In the file manager, rename
.htaccessto something like.htaccess-old. If the home page loads again, the file was the culprit. Log in, open Settings > Permalinks and click Save Changes, which makes WordPress write a fresh basic file. Inner pages that now show a 404 are a sign the rules have not been rewritten yet; the post about permalink 404s helps there. Any custom redirects in the old file will need adding back carefully. - Rule out plugins. Rename the
wp-content/pluginsfolder over FTP or the file manager. If the site returns, rename it back and then disable plugins one at a time by renaming their individual folders until the error reappears. - Check with the host. Ask whether they changed PHP, security rules or limits on your account, and whether your account is hitting its resource caps.
One more quick test: open the direct address of an image from your media library, something under /wp-content/uploads/. If static files load but WordPress pages do not, the server itself is running and the fault sits in PHP or WordPress. If even static files return a 500, the problem is server configuration or the .htaccess file, and plugins can be left alone for now.
Avoid editing php.ini values or server settings you do not understand, and do not set every file to 777 in the hope it helps. That can create a security hole without fixing anything.
500 compared with its neighbours
Several server responses look alike to a visitor but mean different things, and the fix depends on which you have:
| Code | What it usually means |
|---|---|
| 500 | The server failed while handling the request; the log says why. |
| 403 | The server understood but refused, often permissions or a security rule. See the 403 Forbidden explainer. |
| 502, 503, 504 | A gateway, proxy or overloaded service in front of PHP did not get a usable answer in time. Covered in our post on gateway and timeout errors. |
A database outage normally produces WordPress’s own connection message rather than a 500; if that is what you see, go to the database connection repair page.
How we take a 500 error apart
Send us a screenshot or the exact error text, the address of a page that fails, and anything you remember changing. We look at it, tell you plainly what we see and when we can start. If your shop or lead forms are down, we treat it as urgent.
The first thing we do with access is save a complete copy of the site. Then we go to the server and PHP logs, because a 500 without a log line is guesswork. The log usually tells us whether we are dealing with a rewrite rule, a memory or time limit, a permissions problem, or a fatal error in a specific file.
From there the fix is targeted. A bad rewrite rule gets corrected, not just deleted, so the redirects and security rules you depend on keep working. A memory problem gets traced to the plugin or page causing it before any limit is raised. A permissions fault gets set right across the install, not only on the one file the log mentioned. Where a change carries risk, we test it on a staging copy first.
When the host has to act, we write to them with the log lines and the request that fails, which tends to get a faster, more useful reply than “my site is down”. After the fix we load the pages, forms and checkout that matter, then send you a note on the cause and on anything that should change, such as a plugin to replace or a hosting plan that is too tight.
A 500 error that leads back to faulty theme or plugin code becomes part of our wider WordPress bug repair work, handled the same careful way.