500 Internal Server Error — Causes and How to Fix It

Updated 2026-08-29~9 min read

A 500 Internal Server Error is a catch-all. The server ran your application, the application failed, and rather than leak details to a stranger the server returned a generic page. That is deliberate — error messages are a security risk — but it does mean the page you are looking at contains no useful information whatsoever.

The information does exist, though. Almost every 500 writes a specific reason to an error log, usually including the exact file and line number. This guide covers the common causes in order of likelihood, shows you where to find that log on each type of hosting, and gives you a checking order that avoids the usual trap of changing five things at once.

What a 500 Actually Means

The 5xx family means the fault is on the server side rather than in your request. Within that family, 500 specifically means the application was reached and executed, and then something in it went wrong — an uncaught exception, a fatal error, a syntax error, or a resource limit being hit mid-execution.

That is genuinely different from its neighbours. A 502 means the application never gave a usable answer. A 503 means the server chose not to serve. A 504 means the answer took too long. A 500 means the code ran and broke.

💡 The single most useful consequence: because the application actually ran, it almost certainly logged something. Finding that log entry turns a vague 500 into a specific, fixable bug.

The Same Error Under Many Names

A 500 appears with different wording depending on the software involved, which makes people think they have different problems. They do not.

"500 Internal Server Error" — the plain HTTP status text
"HTTP Error 500" — commonly shown by IIS and some browsers
"Internal Server Error" — the default Apache page
"The server encountered an internal error or misconfiguration" — a longer Apache variant
"There has been a critical error on this website" — what WordPress shows once its own error handler catches the failure
"Error 500" in an API response — the same thing returned as JSON rather than HTML

The Usual Causes, Most Likely First

The ordering here matters. Working down this list in sequence will find the cause faster than picking whichever one sounds most interesting.

Cause	How common	Telltale sign
PHP fatal error in code, plugin or theme	Very common	Started right after an update or a code change
Broken .htaccess rule	Very common	Every URL breaks at once, including static files
PHP memory limit exhausted	Common	Only heavy pages break; the log says "Allowed memory size exhausted"
Wrong file permissions	Common	Appeared after a migration, restore or an upload as root
Corrupt or incompatible PHP version	Occasional	Followed a PHP version change on the host
Database unreachable or over its connection limit	Occasional	Intermittent, worse at peak traffic
Disk full	Occasional	Everything breaks at once, including writes and logging

The Fastest Order to Check

This sequence is designed to identify the cause with the fewest changes, and to avoid making things worse while you look.

Read the error log first. Everything below is guesswork until you have done this, and the log usually names the file and line outright.
Ask what changed. A 500 that began immediately after a plugin update, a deployment or a PHP version change has already told you where to look.
Rename .htaccess to .htaccess.bak and reload. If the site returns, a rule in that file is responsible. On WordPress you can regenerate a clean one by re-saving the permalink settings.
Raise the PHP memory limit temporarily — to 256M — and see whether the error disappears. If it does, the real fix is usually the code that is consuming that much, not a permanently higher limit.
On WordPress, turn on WP_DEBUG and WP_DEBUG_LOG in wp-config.php. The white screen becomes an actual message naming the plugin.
Disable all plugins, confirm the site loads, then re-enable them one at a time. Tedious, but it is definitive and it takes less time than guessing.
Check permissions: 644 for files, 755 for directories. Never 777.
Check free disk space. A full disk produces failures that look like everything else and waste hours because nobody thinks to check.

💡 Change one thing at a time and reload after each. If you change several at once and it starts working you will never know which one mattered — and one of the others may have introduced a security problem.

Where to Find the Error Log

This is the step people skip, and it is the one that actually solves the problem. The location depends on your hosting.

Environment	Where the log lives
DirectAdmin	File Manager, then the domain's logs folder, or "Site Errors" in the panel
cPanel	Metrics, then Errors — or public_html/error_log
Nginx on a VPS	/var/log/nginx/error.log
Apache on a VPS	/var/log/apache2/error.log or /var/log/httpd/error_log
PHP-FPM	/var/log/php-fpm/www-error.log, or the path set in the pool config
WordPress with debug logging on	wp-content/debug.log

💡 Read the log from the bottom, not the top. The newest entries are last, and the line you want is the one timestamped when you triggered the error.

Shared Hosting vs VPS

The same 500 is a different job depending on where the site lives, and it is worth being realistic about that.

On shared hosting you can reach the error log through the control panel, change file permissions, edit .htaccess and adjust some PHP settings. What you cannot do is restart PHP-FPM, read the system log, install an extension or change a server-wide limit. If the cause turns out to be one of those, your only option is a support ticket.

On a VPS you have all of it: full logs, service control, configuration and the ability to reproduce the failure under load. The trade-off is that you are also responsible for keeping it patched and configured. For a site that earns money and cannot afford to sit broken while a ticket queue moves, that trade is usually worth it — the difference between diagnosing a 500 in ten minutes and waiting overnight for someone else to look.

Reducing How Often You See One

Run updates on a staging copy before production. Most 500s arrive attached to an update.
Keep backups you have actually tested restoring. An untested backup is a guess.
Set up uptime monitoring so you find out before your visitors do.
Keep PHP's memory limit realistic for what the site does, and fix the code that needs an unreasonable amount rather than raising the ceiling forever.
Leave error logging on permanently, and display_errors off. You want the detail recorded, not shown to visitors.
Watch disk space. Log files and backups fill disks quietly until everything breaks at once.

Want to read your own logs instead of waiting on a support ticket?

Cloud VPS with full root access, complete error logs and no shared-hosting limits — from ฿150/month.

See VPS plans Order now

Frequently Asked Questions

Why does the page show nothing at all instead of an error message?

Because display_errors is off, which is the correct setting for a live site — error details can expose file paths and credentials. The message still exists in the error log. Turn on WP_DEBUG_LOG, or read the server error log directly, and the detail is there.

It broke right after I updated a plugin. What now?

Roll that plugin back. If the admin area is also broken, rename the plugin's folder in wp-content/plugins over FTP or File Manager — WordPress deactivates anything it cannot find and the site will come back. Then update it again on a staging copy to see what actually breaks.

Is a 500 bad for SEO?

Briefly, no — Google retries. Over days, yes: crawling slows and pages can drop out of the index. Google treats a 500 as temporary at first, so the risk is proportional to how long it lasts, not to the fact that it happened.

Can raising the PHP memory limit fix it permanently?

It can, if the site legitimately needs more memory than it has. More often it just moves the ceiling while the real problem — an inefficient query, a plugin loading everything into memory — keeps growing. Raise it to get the site back, then find out what consumed it.

How do I tell a 500 from a 502 when both show a blank error page?

Check the actual status code rather than the wording, using the browser Network tab or by running "curl -I" against the URL. The distinction is worth the ten seconds: a 500 sends you to your application code, a 502 sends you to the backend process. They are different investigations.

GUIDES

Keep reading on similar topics

View all articles

Server

502 Bad Gateway — What It Means and How to Fix It

A 502 means one server asked another server for the page and got back something it could not use. This guide explains which two machines are involved, how 502 differs from 500 and 504, and the order to work through the causes so you find the real one first.

Hosting

Error Establishing a Database Connection — The Four Causes

WordPress shows one message for four completely different problems. Working out which one you have takes about a minute and saves you from trying fixes that were never going to help. Here is how to tell them apart and what to do about each.