A 500 internal server error is not a WordPress error message. It is the server declining to tell you what went wrong. Every guide hands you the same five steps — rename .htaccess, raise the memory limit, disable the plugins, switch the theme, re-upload core — because with a bare 500 there is genuinely nothing else to go on.
There is, though, one thing to read before you touch a file, and almost nobody mentions it: what renders inside the 500. WordPress serves its own critical-error screen with a 500 status too, so the same three digits cover two opposite situations. Which page you are looking at decides whether this takes two minutes or an afternoon.
A 500 is a catch-all, not a diagnosis
The definition is unusually blunt for a specification. A 500 means the server “encountered an unexpected condition that prevented it from fulfilling the request”, and it is “a generic ‘catch-all’ response to server issues, indicating that the server cannot find a more appropriate 5XX error to respond with” (MDN, verified August 2026).
Read that again as a diagnostic statement. The server is not describing your problem. It is telling you that it could not classify your problem. Treating a 500 as a cause — the way “500 error fix” articles do when they open with a list of solutions — is treating a shrug as a sentence.
Which is why the useful work is not fixing, it is narrowing. Two minutes of narrowing removes four of the five standard steps.
Which 500 you have: the page decides
Since WordPress 5.2, a PHP fatal error does not produce a blank page. WordPress catches it and prints “There has been a critical error on this website” — and it sends that page with an HTTP 500. In core, the fatal error handler passes 'response' => 500 to wp_die(). So WordPress’s own error screen is a 500 internal server error. So is your host’s generic error page. So is the empty response that makes Chrome print “HTTP ERROR 500” in plain text.
Same status code, three very different situations. The body is the diagnosis; the number never was.
| What you actually see | Who produced that page | Where the failure is | First move |
|---|---|---|---|
| “There has been a critical error on this website.” | WordPress itself (wp_die() with a 500 response) | PHP ran, WordPress loaded, one plugin or theme threw a fatal error | Check the admin inbox for the recovery email — it usually names the file. Full walkthrough in the WordPress critical error fix |
| Your host’s branded error page, or Apache’s plain “Internal Server Error” | The web server, before PHP was involved | Server configuration: .htaccess, file permissions, a directive the server will not accept | Rename .htaccess and reload. Then read the server error log |
| Nothing — a white page with “HTTP ERROR 500” written by the browser | PHP, with error display switched off | A fatal error somewhere WordPress’s handler cannot reach: wp-config.php, an mu-plugin, a drop-in, or memory exhausted mid-render | Turn on the debug log before anything else — see below |
| A completely blank page, no error text at all, no 500 in the response | Nobody — the request returned 200 with an empty body | Not a 500 at all. Different family of causes | Follow the white screen of death instead |
| “Error establishing a database connection” | WordPress, and it is not a 500 | The database, not PHP | Different diagnosis entirely: the database connection error |
To tell rows two and three apart with certainty, open your browser’s developer tools, go to the Network tab, reload, and click the first request. If the status is 500 and the response body is empty, you are in row three. If the body contains HTML that is not yours, you are in row two.
Why the page is blank is a security setting, not a severity
An empty 500 feels worse than an error message. It is not. It is the result of a deliberate, correct configuration choice, and understanding it is the difference between guessing and reading.
PHP has a setting called display_errors. The PHP manual is explicit about it: “This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet)”, and “You’re strongly advised to use error logging in place of error displaying on production web sites” (verified August 2026). Every decent host follows that advice. So when your site fatals, the error text is not printed — and the response body ends up empty.
There is a detail here that catches people out, and it inverts the usual intuition. With error display turned on, a fatal error still prints something, so the server sends a response body — and can return 200 OK on a page that is completely broken. Turning error display off empties the body, “which in turn causes nginx to correctly throw an HTTP 500 Internal Server Error”. In other words, the 500 you are looking at may be the first honest status code your server has sent all day. The setting that stopped the leak also removed the evidence from the page.
So the first action on an empty 500 is not to rename a file. It is to get the evidence back, privately. Edit wp-config.php and add this just above the line that reads /* That’s all, stop editing! */:
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. The last Fatal error line names a file, and the file names the plugin or theme. WP_DEBUG_DISPLAY stays false on purpose: the log is for you, not for visitors and crawlers. Remove all three lines once you are done — a debug log left on a live site grows, and it is readable by anyone who guesses the URL.
If debug.log is never created, WordPress is not running at all. That points at the server, and at the next section.
The three causes of a bare 500, in the order to check
WordPress’s own documentation is unambiguous about where to start: “The most likely issue is a corrupted .htaccess file” (verified August 2026). Its recommended order is .htaccess, then plugins, then the default theme, then the PHP memory limit, then re-uploading wp-admin and wp-includes. That order is correct, and it is worth understanding why rather than working through it blind.
1. .htaccess, because it fails before anything else runs
On Apache, .htaccess is read on every request, before PHP is asked to do anything. A single unrecognised line takes the whole site down. Apache’s own documentation uses exactly this as a test: put a nonsense word in the file and reload, and “if a server error (HTTP 500) is not generated, then you almost certainly have AllowOverride None in effect”. It also tells you where the answer is: “check your httpd error log. It will likely tell you that the directive used in your .htaccess file is not permitted.”
The fix is isolation, not editing. Rename the file to .htaccess_off and reload the site. If the 500 goes away, you have found it. Log in, go to Settings → Permalinks and press Save: WordPress writes a clean file. The default block is short, and anything else in your old file came from a plugin or from you:
# 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 WordPressThis is where the plugin nobody meant to install does its most memorable work. Caching, security and redirect plugins all write into .htaccess, and when one of them is removed by deleting its folder over FTP rather than deactivating it properly, its rules stay behind — referring to a module that is no longer there. The plugin is gone from the plugins screen and still taking the site down.
2. PHP memory, when the 500 is intermittent
A 500 that appears on one heavy page, during an import, or under load, and disappears afterwards, is usually memory. WordPress asks PHP for 40MB on a single site and 64MB on multisite (WordPress.org, verified August 2026) — figures set for a much smaller WordPress than the one most people run. Raise it in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );If nothing changes, do not keep raising the number. WordPress.org notes plainly that “some hosts do not allow for increasing the PHP memory limit automatically” — the server ceiling wins over your constant, and the next step is a support ticket to the host, not another edit.
One caveat worth stating: a memory limit is a symptom the first time and a diagnosis the third. If a site needs 512MB to render a category page, something is loading far more than it should, and raising the limit is buying silence rather than fixing anything.
3. File permissions and ownership, the one nobody checks
If .htaccess is not the cause and the debug log is empty, permissions are the usual remaining candidate — commonly after a migration, a restored backup, or files uploaded as the wrong user. Standard values are 644 for files and 755 for directories, with wp-config.php often tightened to 600. A file the web server cannot read, or one that is world-writable on a server configured to refuse those, produces a 500 with no PHP error at all, because PHP never got to run the file.
At this point the server error log — not debug.log — is the only thing that will tell you. Most hosting panels expose it in one click. If yours does not, ask support for the last fifty lines. It is a faster question than any of the guesses that follow it.
500, 502, 503, 504: not the same call
People paste all four into a search box as “server error”. They point at different parts of the stack, and telling them apart saves you from debugging WordPress when WordPress is not involved. Definitions below are MDN’s, verified August 2026.
| Status | What it means | Who to look at | Typical WordPress version of it |
|---|---|---|---|
| 500 Internal Server Error | “The server has encountered a situation it does not know how to handle” | Your site: PHP code, .htaccess, permissions | A plugin fatal, a broken .htaccess, exhausted memory |
| 502 Bad Gateway | The server, “working as a gateway…, got an invalid response” | The layer in front: PHP-FPM, or a proxy such as a CDN | PHP-FPM crashed or ran out of workers; the CDN cannot reach the origin |
| 503 Service Unavailable | “The server is not ready to handle the request” | Deliberate unavailability, or a server at capacity | An update that left the site stuck in maintenance mode; a host throttling a traffic spike |
| 504 Gateway Timeout | The gateway “cannot get a response in time” | Something slow, not something broken | A long import, a heavy cron job, a database query that never returns |
The practical read: a 500 is yours to fix and a 502 usually is not. And a 504 is a speed problem wearing an error page — if it shows up regularly under normal traffic, the site is slow enough that the server gives up before it finishes, which is a performance job, not a repair.
One thing all four share is how search engines treat them. Google states that “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling”, that already indexed URLs “are preserved in the index, but eventually dropped”, and that the indexing pipeline “removes from the index URLs that persistently return a server error” (verified August 2026). An hour of 500s costs nothing. A fortnight of them costs pages.
When it is not worth fixing it yourself
Two of the steps above are yours, and you should not pay anyone for them. Renaming .htaccess is a thirty-second test with an obvious result. Reversing a plugin update you made ten minutes ago is not an engineering project. Do both before you call anybody.
Stop at the point where you would start guessing. Concretely: when the debug log names WordPress core or the database rather than one plugin; when the error is intermittent and you cannot reproduce it; when the site returns a 500 to some visitors and 200 to you, which usually means caching or a load-dependent cause and cannot be diagnosed by clicking reload. Re-uploading core over a live site is the last step in WordPress’s own list for a reason, and it is the one that turns a broken site into a broken site with missing customisations.
And if it is a shop, the arithmetic changes before the technical picture does. A checkout returning 500s is losing orders while you read log lines, and the honest move is to stop investigating and restore the last known-good backup, then diagnose on a copy. That is what our WordPress error-fixing service does: back up first, read the log rather than guess, fix the broken part, leave the rest alone.
Frequently asked questions
Is a 500 internal server error the same as the WordPress critical error?
It is the same HTTP status code, and that is the confusing part. WordPress serves its own "There has been a critical error on this website" page with a 500 response — the fatal error handler passes response => 500 to wp_die(). So both are 500s, but they mean opposite things. If you can read WordPress's message, WordPress loaded and one plugin or theme died: the easy case, and a recovery email has usually already been sent. If the page is blank or shows your host's generic error page, WordPress never got far enough to say anything.
Why is my 500 page completely blank?
Because PHP is configured not to print errors, which is the correct setting for a live site. The PHP manual calls display_errors "a feature to support your development" that "should never be used on production systems". With it off, the error text goes nowhere visible and the response body is empty, so the browser shows its own "HTTP ERROR 500". The information still exists — it is in the PHP error log and, once you enable it, in wp-content/debug.log.
How long can a 500 error stay up before it damages my rankings?
Short outages are handled gracefully: Google states that "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling", and that already indexed URLs "are preserved in the index, but eventually dropped". The damage is not instant, it is cumulative — persistent server errors get URLs removed. An hour is a non-event. A week of 500s on your main pages is a real problem, and crawl rate only recovers gradually once the site returns 200s again.
The 500 shows only in wp-admin, or only on the public site. What does that tell me?
That the failing code runs in only one place, which narrows the search considerably. A broken admin screen with a working front end points at a plugin's settings or dashboard code; the reverse points at a front-end feature or the theme. A 500 in both places, including on /wp-login.php, points at something loaded on every request: .htaccess, wp-config.php, an mu-plugin, or the server itself.
Can I fix a 500 error without FTP?
Sometimes. Most hosting panels include a file manager, which is enough to rename .htaccess and edit wp-config.php — that covers the two most common causes. What you cannot do without file access of some kind is deactivate a plugin when wp-admin is also returning a 500. If your host offers neither, the fastest route is their support chat: ask them to send you the last lines of the PHP error log for your site, and to rename .htaccess.
Does a 500 error mean I have lost data?
No. A 500 means a request could not be completed, not that anything was deleted. Posts, pages, media, users and WooCommerce orders sit in the database, untouched by whatever stopped the page from rendering. The exception is not the error itself but the panic that follows it — re-uploading a WordPress install over a live site, or restoring an old backup over a shop that has taken orders since, does lose data. Take a backup before you change anything.
Sources (all verified August 2026): MDN — 500 Internal Server Error; MDN — HTTP response status codes; WordPress Developer — WP_Fatal_Error_Handler::display_default_error_template(); WordPress — Common WordPress errors; WordPress — Editing wp-config.php (memory defaults); Apache HTTP Server — .htaccess files; PHP Manual — display_errors and log_errors; Google Search Central — HTTP status codes and network errors; Mattias Geniar — nginx sets HTTP 200 OK on PHP-FPM parse errors.