A white page saying "500 Internal Server Error" means the server accepted the request but hit an unexpected failure while processing it. The message is deliberately generic: a PHP syntax error, a broken .htaccess line, exhausted memory or wrong file permissions can all produce it. The browser only shows you the symptom, while the actual cause is written to the server logs. So the first job is not to guess but to find the exact log entry.
Start with what changed
Most 500 errors appear right after a change. Did you install a plugin, update a theme, switch the PHP version or edit .htaccess? If so, the cause is almost certainly inside that change. For example, a small clothing shop in Tashkent activated a new WooCommerce payment plugin and the whole site immediately started returning 500. Temporarily renaming the plugin folder brought the site back within seconds. If nothing changed, consider server-side factors such as a full disk quota, hitting the plan's resource limits, or an automatic update.
The error log is your main source
Every site on the hosting has an error log. In ISPmanager the logs are usually reachable from the site settings or the logs folder in the file manager, and PHP may also write to an error_log file in the site root. Look at the last lines: they contain the file name, line number and error type. With SSH access:
tail -n 50 ~/logs/example.uz.error.log
tail -n 50 ~/www/example.uz/error_logPaths depend on the hosting setup, so confirm them in the panel. "Allowed memory size exhausted" points to the memory limit, "Parse error: syntax error" to broken code at the given line, and "Invalid command" or "RewriteRule: bad flag" to .htaccess.
Broken .htaccess rules
On Apache, a single invalid directive in .htaccess takes down the entire site. This happens after manual edits, when plugins append rules, or when a full disk leaves the file half-written. Rename it and reload the site:
mv .htaccess .htaccess.bakIf the site opens, recreate the default WordPress rules and add your extra rules back one at a time until the faulty line shows up:
# 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 WordPressNote that php_value and php_flag cause a 500 when PHP runs as PHP-FPM or CGI rather than an Apache module. Set those values in the panel or a .user.ini file instead.
PHP version and compatibility
Old code may break on a newer PHP version, since functions removed in PHP 8 trigger fatal errors in outdated themes and plugins. The reverse is also true when a plugin requires a newer PHP than the server runs. ISPmanager lets you choose the PHP version per site. If the log shows "Call to undefined function" or "Uncaught Error", roll back to the previous version first, confirm the site recovers, and then plan to update the code.
Memory and execution limits
Heavy pages, large imports and plugin-heavy sites can exceed PHP's memory allowance, and the log states exactly how much was allowed and requested. Raising the limit in .user.ini is a stopgap:
memory_limit = 256M
max_execution_time = 60If the error returns after raising it, the real problem is usually a single heavy plugin or code stuck in a loop.
File and folder permissions
When PHP runs as the site owner, overly permissive modes can be rejected for security reasons and produce a 500. Use 755 for directories and 644 for files:
find ~/www/example.uz -type d -exec chmod 755 {} \;
find ~/www/example.uz -type f -exec chmod 644 {} \;Never "fix" it with 777, which exposes the site to other users and malicious scripts.
Logging errors from WordPress itself
Without log access, enable debug logging in wp-config.php so errors go to wp-content/debug.log instead of the screen:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Turn it off once fixed, because error messages can reveal file paths and site structure.
When to contact support
If the logs are empty, every one of your sites fails at once, or you suspect a server-side issue, there is no need to dig for hours. sayt.uz customers can open a ticket from the support section of the cabinet with the failing URL, the approximate time and recent changes, which makes it much faster to match the problem against server logs.