Fix "500 Internal Server Error" on Your Website

A 500 error is the server's way of saying "something broke and I can't be more specific." The real message is in the error log — here's how to find it and fix the common causes.

Cause 1: a broken .htaccess

An invalid directive in .htaccess (often from a plugin) throws an instant 500. Rename it to test:

mv .htaccess .htaccess.bak
# reload the site — if it works, the .htaccess was the problem

If that fixes it, regenerate a clean .htaccess (in WordPress: Settings → Permalinks → Save).

Cause 2: wrong file permissions

Web files should generally be 644 and folders 755. A script set to 777 can actually be refused by the server under suEXEC. Reset them:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

Cause 3: a PHP error or wrong PHP version

A fatal PHP error returns a 500. The error log names the file and line. Common fixes: switch the PHP version (in DirectAdmin → PHP Selector) to one your app supports, or fix the offending code/plugin.

Cause 4: exhausted PHP memory

"Allowed memory size exhausted" in the log means PHP ran out of memory. Raise the limit in php.ini or a custom config:

memory_limit = 256M

The clean checklist

1. Open the error log — it names the real cause.
2. Rename .htaccess to test it.
3. Reset permissions to 644 files / 755 folders.
4. Check the PHP version and error log for fatals.
5. Raise memory_limit if the log says it's exhausted.

A 500 is never random. The error log always names the file and line — read it before changing anything.

Cause 5: a 500 Internal Server Error from a broken database connection

Some apps throw a raw 500 Internal Server Error instead of a friendlier database-error screen when the database is unreachable and the failure isn't handled gracefully. Check the database credentials in your app's config (for WordPress, wp-config.php) and confirm the database service is actually running before assuming it's a code problem.

Cause 6: a bad server-level config change

If the 500 Internal Server Error started right after a config change — php.ini, an nginx/Apache .conf, or a PHP-FPM pool — the config itself may be invalid. Test the config syntax before reloading the service, and check the web server's own error log, not just the site's, since a config-level failure often doesn't reach the application log at all.

How to prevent 500 Internal Server Errors

• Test .htaccess and config changes on a staging copy before production.
• Keep plugins/themes and your PHP version compatible — update them together, not separately.
• Set a sane memory_limit (256M+) proactively rather than raising it only after a crash.
• Watch the error log after every deploy, not just when a user reports a blank page.
• Keep a recent backup so you can roll back a bad update fast instead of debugging live.

Related web hosting errors

If WordPress shows a blank page instead of a 500 page, see WordPress white screen of death. If the error explicitly mentions the database, read "Error establishing a database connection". Behind a reverse proxy, a similar failure shows as nginx 502 Bad Gateway, and a permissions-only issue may instead show as 403 Forbidden.