Владелец интернет-магазина видит «Internal Server Error» сразу после включения кэша или переноса с другого хостинга — заказы стоят, реклама крутится. Если непонятно, 500 это или другой код — начните с карты симптомов. В практике 500 на WordPress чаще всего даёт битый .htaccess или fatal в плагине, а не «сломавшийся сервер». Ниже — пошаговый разбор от логов до mod_security.
Что вообще значит «ошибка 500»
HTTP 500 (Internal Server Error) — общий ответ веб-сервера, который означает: «внутри что-то сломалось, я не понимаю что именно». В отличие от 404 (страница не найдена) или 403 (доступ запрещён), причина 500 всегда находится на стороне сервера или приложения. Браузер тут ни при чём, сетевая часть отработала корректно.
На WordPress 500 обычно вызывают четыре источника: ошибки в .htaccess, fatal PHP-ошибки, неправильные права на файлы и проблемы конфигурации (PHP-extension, mod_security, лимиты CGI). Разбираем в порядке частоты.
Шаг 1. Включите WP_DEBUG и читайте логи
Сначала — то же, что и при белом экране. В wp-config.php над строкой «That's all, stop editing!»:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Перезагрузите страницу. После этого wp-content/debug.log покажет fatal-ошибку. Если файл пуст — значит проблема не в PHP, а в веб-сервере. Откройте error_log Apache / nginx — он лежит в корне сайта или в личном кабинете хостинга.
Шаг 2. Проверьте .htaccess
Это самая частая причина 500 на shared-хостинге. После миграции, активации SEO-плагина или плагина безопасности в .htaccess могли добавиться директивы, которые сервер не поддерживает.
Откройте .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Всё, что между этими маркерами или после них и выглядит странно (Header set ... с непонятными значениями, php_value ... с большими лимитами, перенаправления на чужие домены) — кандидаты на удаление.
Быстрый тест: переименуйте .htaccess в .htaccess.bak. Если сайт ожил — проблема была здесь. Зайдите в админку → Настройки → Постоянные ссылки → Сохранить. WordPress сгенерирует чистый .htaccess.
Шаг 3. Проверьте права доступа
500 может возникать, если права на файлы выставлены слишком жёстко (например, 600) или, наоборот, слишком слабо (777). Правильные права для WordPress:
- Папки —
755 - Файлы —
644 wp-config.php—600(или 640, если хостер требует доступ группы)wp-content/uploads— рекурсивно755для папок и644для файлов
В терминале через SSH:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.phpШаг 4. PHP-память и таймаут
Если в error_log видите Premature end of script headers или Internal Server Error без подробностей — попробуйте увеличить лимиты PHP. В .htaccess:
php_value memory_limit 256M
php_value max_execution_time 120
php_value max_input_vars 5000Если хостер не разрешает php_value в .htaccess (выдаёт 500 на этой же директиве) — те же значения нужно прописать через панель управления хостингом или в php.ini на VDS.
Шаг 5. Откат последнего обновления
Если 500 появилась после обновления плагина, темы или ядра — нужен откат. Алгоритм такой же, как для белого экрана: переименовать папку плагина / темы по FTP, проверить, появится ли сайт.
Шаг 6. mod_security и хостинг-лимиты
На некоторых хостингах включён mod_security — модуль безопасности Apache, который блокирует «подозрительные» запросы. Иногда он реагирует на безобидные действия: загрузку файла, POST с большим телом, обращение к admin-ajax.php с определёнными параметрами.
Это решается только обращением в техподдержку хостера: попросите проверить лог mod_security по вашему сайту за последние 24 часа. Они увидят, какое правило срабатывает, и либо отключат его для вас, либо подскажут, как обойти.
Шаг 7. Что-то экзотическое
Если ни один из шагов не помог, остаются редкие причины:
- Не хватает PHP-расширения (например,
php-mbstring,php-curl,php-zip) — решается установкой через хостинг. - OPcache закэшировал битую версию файла — решается перезапуском PHP-FPM или сбросом OPcache.
- Закончилось место на диске — проверьте через панель хостинга, может быть забит логами или uploads.
- База данных «повисла» — обычно сопровождается ошибкой подключения к базе вместо 500.
Когда лучше позвать спеца
Если белый экран можно починить за 15–30 минут самостоятельно, то 500 часто требует доступа к логам и хостингу. Частая скрытая причина обеих проблем — накопленные лишние плагины и конфликт после Update All. Если шаги 1–4 не помогли — пишите. Сделаем разбор бесплатно, по итогу скажем точную причину и сроки.
