Если при открытии сайта вы видите белую страницу с надписью «500 Internal Server Error», это значит, что сервер принял запрос, но при его выполнении столкнулся с непредвиденной ошибкой. Ошибка очень общая: её может вызвать синтаксическая ошибка в PHP-коде, сломанная строка в .htaccess, нехватка памяти или неправильные права на файлы. Браузер показывает только последствие, а причина записана в логах сервера. Поэтому при ошибке 500 первым делом нужно не гадать, а найти конкретную запись.
Шаг первый: вспомните, когда всё началось
Чаще всего ошибка 500 появляется сразу после какого-то изменения. Вы установили новый плагин, обновили тему, сменили версию PHP или отредактировали .htaccess? Если ошибка возникла именно после такого действия, искать причину внутри этого изменения — самый быстрый путь. Например, владелец небольшого магазина одежды в Ташкенте установил новый платёжный плагин для WooCommerce, и сразу после активации весь сайт начал отдавать 500. В такой ситуации временное переименование папки плагина обычно моментально возвращает сайт.
Если вы ничего не меняли, учитывайте и серверные факторы: заполненную дисковую квоту, достижение лимита ресурсов тарифа или автоматическое обновление. И в этих случаях логи укажут правильное направление.
Error log — главный источник ответа
Для каждого сайта на хостинге ведётся журнал ошибок. В панели ISPmanager логи обычно открываются из настроек сайта или из папки logs в файловом менеджере. PHP также может писать ошибки в файл error_log в корне сайта. Смотрите последние строки журнала: там указаны имя файла, номер строки и тип ошибки. Если есть доступ по SSH, удобно смотреть последние записи так:
tail -n 50 ~/logs/example.uz.error.log
tail -n 50 ~/www/example.uz/error_logПути к файлам зависят от настроек хостинга, поэтому точное расположение уточните в панели. Если в логе «PHP Fatal error: Allowed memory size exhausted», проблема в лимите памяти; «Parse error: syntax error» — ошибка в коде в указанном файле и строке; записи вроде «Invalid command» или «RewriteRule: bad flag» связаны с .htaccess.
Сломанные строки в .htaccess
На сервере Apache одна неверная директива в .htaccess приводит к ошибке 500 на всём сайте. Обычно это случается после ручной правки, когда плагин дописывает в файл свои правила, или когда диск переполнился и файл записался наполовину. Самый простой способ проверки — временно переименовать файл и снова открыть сайт.
mv .htaccess .htaccess.bakЕсли сайт открылся, причина точно в .htaccess. Стандартные правила WordPress очень короткие: создайте их заново и возвращайте дополнительные правила по одному, пока не найдёте сломанную строку.
# 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 WordPressПомните также, что директивы php_value и php_flag вызывают ошибку 500, если PHP работает не как модуль Apache, а, например, через PHP-FPM или CGI. Такие настройки правильнее задавать через панель или в файле .user.ini.
Версия PHP и совместимость кода
Старый код сайта может не работать на новой версии PHP. Функции, удалённые в PHP 8, или изменившееся поведение языка вызывают фатальные ошибки в устаревших темах и плагинах. И наоборот: если новый плагин требует версию PHP выше установленной, результат будет тем же. В ISPmanager версию PHP можно выбрать отдельно для каждого сайта. Если в логе встречаются «Call to undefined function» или «Uncaught Error», сначала верните прежнюю версию PHP и проверьте, восстановился ли сайт, а затем запланируйте адаптацию кода.
Лимит памяти и времени выполнения
Тяжёлые страницы, большие импорты или сайты с множеством плагинов могут превышать выделенную PHP память. Лог в этом случае прямо показывает, сколько байт разрешено и сколько было запрошено. Повышение лимита — временное решение: настоящей причиной часто оказывается один слишком тяжёлый плагин или код, ушедший в бесконечный цикл. Лимит можно задать через .user.ini:
memory_limit = 256M
max_execution_time = 60Если после увеличения лимита ошибка повторяется, проблему нужно искать в коде, а не в настройках.
Права на файлы и папки
В некоторых конфигурациях, особенно когда PHP выполняется от имени владельца сайта, слишком широкие права отклоняются из соображений безопасности и приводят к ошибке 500. Обычные правильные значения: 755 для папок и 644 для файлов. При загрузке файлов от имени другого пользователя может оказаться неверным и владелец. По SSH права можно восстановить массово:
find ~/www/example.uz -type d -exec chmod 755 {} \;
find ~/www/example.uz -type f -exec chmod 644 {} \;Никогда не пытайтесь решить проблему, выставив всем файлам 777: так сайт становится открытым для других пользователей и вредоносных скриптов.
Временный вывод ошибки
Если доступа к логам нет, ошибку можно временно зафиксировать средствами самого сайта. Для WordPress безопаснее включить режим отладки в wp-config.php и писать ошибки в отдельный файл, а не на экран:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Тогда ошибки попадут в wp-content/debug.log, а посетители их не увидят. После решения проблемы обязательно отключите отладку: тексты ошибок могут раскрыть пути к файлам и структуру сайта.
Когда пора обратиться в поддержку
Если логи пусты, ошибка появилась сразу на всех ваших сайтах или вы подозреваете проблему на стороне сервера, не нужно тратить часы на самостоятельный поиск. Клиенты sayt.uz могут открыть тикет в разделе поддержки личного кабинета и указать адрес страницы с ошибкой, примерное время её появления и последние внесённые изменения. Такая конкретика заметно ускоряет диагностику, потому что серверные логи легко сопоставить по времени.