Диагностика WordPress: как найти причину ошибки

Сайт на WordPress сломался. Иногда понятно почему — обновили плагин, и всё поехало. Но чаще симптом размытый: «белый экран», «ошибка 500», «не отправляется форма». И первое желание — начать что-то менять: отключить плагин, переустановить тему, покрутить настройки. Именно так ошибка обрастает новыми, а причина так и остаётся ненайденной.

Диагностика — это не перебор вариантов, а сужение поиска. Разберём, как искать причину по симптому, а не наугад.

Почему в WordPress искать сложнее, чем кажется

WordPress — это слоёный пирог: ядро, тема, плагины, сервер, база данных, кэш. Ошибка проявляется на поверхности, а причина может сидеть в любом слое. Причём один и тот же симптом у разных сайтов имеет разные причины. «Белый экран» — это и нехватка памяти, и фатальная ошибка в плагине, и конфликт версий PHP.

Поэтому первый принцип диагностики простой: не менять ничего, пока не соберёте факты. Второй — менять по одному. Третий — записывать, что уже проверили.

Симптом → куда смотреть

Начните с того, что видно. Симптом подсказывает слой, в котором искать.

Белый экран без текста. Классика WordPress. Причина почти всегда в фатальной ошибке PHP, но включённый режим отладки её скрывает. Включите WP_DEBUG и WP_DEBUG_LOG в wp-config.php — в папке wp-content появится файл debug.log с текстом ошибки. Там будет имя файла и строка, где всё сломалось.

Ошибка 500. Это «внутренняя ошибка сервера», и сама по себе она ничего не говорит. Смотрите в два места: в лог ошибок PHP (обычно error_log в корне сайта или через панель хостинга) и в debug.log. Если в логах пусто — проблема на уровне сервера, и стоит написать в поддержку хостинга.

«Ошибка установки соединения с базой данных». Здесь почти всегда одно из трёх: неверные данные в wp-config.php, база переехала на другой сервер, или она повреждена. Проверьте доступы, а если они верны — зайдите через phpMyAdmin и посмотрите, открывается ли база.

Страница открывается, но что-то не нажимается. Это не PHP-ошибка, а JavaScript. Откройте консоль браузера (F12) и посмотрите на красные строки. Там будет имя скрипта и характер ошибки. Часто виноват конфликт двух плагинов, которые подключают разные версии одной библиотеки.

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

Метод половинного деления

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

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

Важно: это делается на копии сайта, а не на живом. Иначе половинное деление превратится в половинный простой магазина.

Где смотреть логи

Без логов диагностика — это гадание. И на WordPress их несколько.

• debug.log в wp-content — ошибки PHP от самого WordPress. Включается в конфиге.
• error_log на уровне хостинга — сюда пишет сервер, включая фатальные ошибки, которые WordPress не поймал.
• Логи веб-сервера (access и error) — видно, какие запросы приходили и с каким кодом ответа.
• Консоль браузера — ошибки JavaScript и сетевые сбои.
• Логи плагинов и интеграций — если ошибка связана с обменом данными или оплатой.

Полезная привычка — открывать логи при любой непонятной проблеме, а не после того, как перепробовали всё остальное. Часто ответ там уже есть.

Что проверить, прежде чем что-то менять

Есть несколько быстрых проверок, которые закрывают половину случаев.

• Что менялось в последние сутки: плагины, тема, ядро, код, настройки хостинга.
• Версия PHP — не обновил ли её хостинг автоматически.
• Закончилось ли место на диске.
• Не истёк ли SSL-сертификат или лимит тарифа.
• Воспроизводится ли ошибка в другом браузере и в режиме инкогнито.
• Воспроизводится ли она на другой странице или только на одной.

Последние два пункта особенно важны. Если ошибка только в вашем браузере — это кэш. Если только на одной странице — ищите в её контенте или шаблоне, а не во всём сайте.

Красные флаги в диагностике

• Меняют сразу несколько вещей, а потом не понимают, что помогло.
• Диагностируют на живом сайте, а не на копии.
• Не смотрят в логи, потому что «там ничего не будет».
• Отключают плагины, не записывая, какие уже проверили.
• Включают отладку на живом сайте и оставляют её включённой.
• Ищут ошибку в теме, когда она в базе данных.
• Переустанавливают WordPress, не выяснив причину.

Что в итоге

Диагностика WordPress — это не перебор, а сужение. Начните с симптома, включите логи и двигайтесь от внешнего слоя к внутреннему: браузер, тема, плагины, ядро, сервер, база. Меняйте по одному и записывайте шаги. Так даже незнакомая ошибка находится за час-два, а не за неделю переустановок.

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