Как исправить ошибки 500, 502 и 504 на сайте WordPress

Если сайт WordPress внезапно перестал открываться, а вместо страниц вы видите ошибку 500, 502 или 504, сначала нужно понять, где именно ломается цепочка: в самом WordPress, в плагинах и теме, на уровне PHP, веб-сервера или кэша. Эти ошибки часто выглядят похоже для посетителя, но причины у них разные, и лечатся они не одинаково.

Ниже — практический порядок проверки, который помогает быстро сузить источник проблемы и не усугубить ситуацию лишними действиями.

Что означают 500, 502 и 504

Ошибка 500 Internal Server Error обычно означает, что сервер не смог корректно обработать запрос. На WordPress это часто связано с PHP-ошибкой, битым .htaccess, конфликтом плагина или темы, нехваткой ресурсов.

Ошибка 502 Bad Gateway чаще появляется, когда один сервер не получил нормальный ответ от другого. На практике это бывает при сбое PHP-FPM, перегрузке хостинга, проблемах с прокси, nginx или внешним кэшем.

Ошибка 504 Gateway Timeout означает таймаут: сервер слишком долго ждал ответ от следующего звена цепочки. Причина может быть в медленном запросе к базе данных, зависшем плагине, тяжелом cron-задаче, медленном PHP или перегрузке сервера.

Для владельца сайта важен не только код ошибки, но и контекст: падает ли весь сайт, только админка, отдельные страницы или запросы после входа в панель. Это сразу подсказывает, где искать проблему.

С чего начать диагностику

Если сайт недоступен, не спешите сразу переустанавливать WordPress или менять тему. Сначала проверьте три вещи:

• падает ли сайт полностью или только часть страниц;
• менялись ли недавно плагины, тема, PHP-версия, настройки кэша или .htaccess;
• есть ли доступ к панели хостинга, FTP/SFTP и логам ошибок.

Если есть доступ только к хостингу, начните с логов веб-сервера и PHP. Если доступна админка WordPress, можно быстрее проверить плагины, тему и режим отладки.

Проверьте логи ошибок, прежде чем что-то отключать

Самый полезный источник — журнал ошибок. Он обычно показывает не сам код 500/502/504, а конкретную причину: fatal error, exhausted memory, allowed memory size, timeout, undefined function и так далее.

В WordPress можно временно включить логирование через wp-config.php. Это не чинит сайт само по себе, но помогает увидеть реальную причину сбоя. Перед изменением файла сделайте копию.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После этого ошибки будут писаться в файл wp-content/debug.log, если WordPress успевает загрузиться хотя бы частично. На некоторых хостингах логирование может быть ограничено, тогда смотрите журнал в панели хостинга.

Если в логе повторяется одна и та же строка с конкретным плагином или темой, это уже почти готовый ответ. Если видите сообщения о нехватке памяти или превышении времени выполнения, переходите к проверке ресурсов и тяжёлых запросов.

Отключите плагины как основной источник конфликтов

Очень часто ошибка 500 или 504 появляется после обновления или активации плагина. Особенно это касается плагинов кэша, безопасности, оптимизации изображений, резервного копирования, импорта и конструкторов страниц.

Если админка открывается, отключайте плагины по одному и проверяйте сайт после каждого шага. Если сайт не открывается вообще, проще временно отключить все плагины через FTP или файловый менеджер: переименуйте папку wp-content/plugins, например в plugins-off. WordPress перестанет видеть активные плагины и загрузится без них.

Если после этого сайт заработал, верните папке прежнее имя и включайте плагины по одному, пока ошибка не повторится. Так вы быстро найдете виновника.

Отдельно проверьте:

• плагины кэша и минификации;
• плагины безопасности с жесткими правилами;
• плагины, которые работают с внешними API;
• последние установленные или обновленные расширения.

Проверьте тему и дочернюю тему

Если после отключения плагинов сайт продолжает падать, проблема может быть в теме или дочерней теме. Это особенно вероятно, если ошибка появилась после обновления шаблона, правок в functions.php или установки кода вручную.

Для проверки временно переключитесь на стандартную тему WordPress, например одну из актуальных тем серии Twenty. Если админка недоступна, можно переименовать папку активной темы через FTP. WordPress попытается перейти на другую установленную тему, если она есть.

Если сайт ожил после смены темы, ищите ошибку в:

• functions.php;
• кастомных хуках и фильтрах;
• шаблонах, где добавлен собственный PHP-код;
• дочерней теме, если она наследует проблемный код.

Здесь особенно часто встречаются синтаксические ошибки, вызов несуществующей функции или несовместимость с новой версией PHP.

Проверьте PHP-версию и лимиты памяти

После обновления WordPress или плагинов сайт может начать падать из-за несовместимой версии PHP. С другой стороны, слишком старая версия PHP тоже вызывает ошибки и нестабильную работу. Смотрите требования конкретных плагинов и темы, но не ставьте новую версию вслепую, если хостинг и код сайта к ней не готовы.

Для WordPress важен и лимит памяти. Если он слишком низкий, вы увидите ошибки вида Allowed memory size exhausted или косвенные 500/504 при тяжелых запросах.

В wp-config.php можно задать лимит памяти, если хостинг это позволяет:

define( 'WP_MEMORY_LIMIT', '256M' );

Но это не магическое решение. Если хостинг жестко ограничивает память на уровне PHP, значение в WordPress не поможет выше этого потолка. Тогда нужно менять тариф или просить поддержку хостинга увеличить лимиты.

Если ошибка появляется только в админке, а фронтенд открывается, это часто указывает на нехватку памяти при загрузке тяжелых страниц панели, редактора или плагинов.

Сбросьте кэш, но не путайте его с причиной

Кэш сам по себе редко является первопричиной, но он может скрывать или усиливать проблему. После сбоя кэш-плагин иногда продолжает отдавать битые страницы, а серверный кэш или CDN — старую версию ответа, даже если вы уже исправили код.

Проверьте все уровни, которые есть в вашей схеме:

• кэш плагина WordPress;
• серверный кэш на хостинге;
• объектный кэш, если он подключен;
• CDN или прокси, если они используются.

Если ошибка 502 или 504 возникает только при включенном кэше, временно отключите его и проверьте сайт без него. Иногда проблема в правилах минификации, объединении файлов или слишком агрессивной настройке кэширования.

После очистки кэша обязательно проверьте не только главную страницу, но и внутренние страницы, админку и формы, если они есть.

Проверьте .htaccess, nginx и правила перенаправления

Для 500 ошибки на Apache частая причина — поврежденный или конфликтующий файл .htaccess. Это особенно заметно после изменения постоянных ссылок, установки редиректов или плагина безопасности.

Безопасный способ проверки — временно переименовать .htaccess и открыть сайт. Если ошибка исчезла, проблема в правилах. После этого можно заново сохранить настройки постоянных ссылок в админке WordPress, чтобы файл пересоздался с базовыми правилами.

На nginx ситуация другая: там правила обычно находятся в конфиге сервера, и WordPress сам их не пересоздает. Если сайт на nginx, а ошибка появилась после правок конфигурации, нужен доступ к настройкам сервера или помощь хостинга.

Если у вас одновременно настроены редиректы в WordPress, на уровне плагина, в .htaccess и на стороне CDN, конфликт правил тоже может приводить к 500 или бесконечным перенаправлениям, которые внешне выглядят как недоступность сайта.

Когда проблема на стороне сервера или хостинга

Если плагины отключены, тема заменена, кэш очищен, а ошибка 502 или 504 остается, вероятнее всего, дело не в WordPress. На стороне сервера это может быть:

• перегрузка CPU или памяти на общем хостинге;
• сбой PHP-FPM или FastCGI;
• слишком короткие таймауты;
• проблемы с MySQL/MariaDB;
• временная недоступность соседних сервисов у хостера.

В этом случае полезно проверить, повторяется ли ошибка в разное время суток и на разных страницах. Если сайт падает только под нагрузкой или в часы пик, это похоже на нехватку ресурсов, а не на ошибку в коде.

Для 504 особенно характерно, что одна и та же страница иногда открывается, а иногда нет. Это типичный признак таймаута, а не сломанной страницы.

Что делать, если сайт не открывается даже для проверки

Если вы не можете войти в админку и сайт не отвечает, действуйте в таком порядке:

1. Сделайте копию файлов и базы, если это возможно без риска усугубить ситуацию.
2. Посмотрите логи ошибок на хостинге.
3. Временно отключите плагины через переименование папки plugins.
4. Проверьте активную тему и при необходимости переключите ее на стандартную.
5. Очистите серверный кэш и кэш плагина, если доступ к ним есть.
6. Проверьте .htaccess или конфигурацию nginx.
7. Если проблема сохраняется, обращайтесь в поддержку хостинга с конкретными логами и временем ошибки.

Не стоит сразу удалять плагины, менять файлы ядра WordPress или восстанавливать сайт из старой резервной копии без понимания причины. Иначе можно потерять уже исправленную часть данных или вернуть старую проблему вместе с новой.

Как понять, что ошибка действительно исправлена

После каждого изменения проверяйте не только главную страницу, но и несколько разных сценариев:

• открытие внутренней страницы;
• вход в админку;
• редактирование записи;
• открытие страницы с формой или тяжелым блоком;
• повторная загрузка страницы после очистки кэша браузера.

Если ошибка исчезла, но сайт работает заметно медленнее обычного, это тоже сигнал. Иногда 500/502/504 уходят, а первопричина — перегрузка сервера или тяжелый плагин — остается и проявится снова при нагрузке.

Хорошая практика после восстановления — оставить включенным лог ошибок хотя бы на время наблюдения и проверить, не повторяются ли записи в журнале. Это помогает не пропустить скрытую проблему, которая пока не вылилась в новый сбой.

Если свести все к короткому порядку, то рабочий алгоритм такой: сначала логи, потом плагины, затем тема, PHP и память, после этого кэш и правила сервера. В большинстве случаев этого достаточно, чтобы найти источник ошибки 500, 502 или 504 без лишних экспериментов.