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.
Quick answer
A 500 Internal Server Error hides the real problem, so read the site's error log first (in your panel or the domain's logs folder). The usual causes are a broken .htaccess rule, a PHP fatal error or exhausted memory limit, wrong file permissions, or a plugin that does not support your PHP version.
In DirectAdmin/cPanel open the Error Log, or check ~/domains/yourdomain/logs/ on the server. The 500 page hides the detail; the log shows the exact line and file that failed.
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 problemIf 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 = 256MThe clean checklist
- Open the error log — it names the real cause.
- Rename
.htaccessto test it. - Reset permissions to 644 files / 755 folders.
- Check the PHP version and error log for fatals.
- Raise
memory_limitif 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
.htaccessand 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.