Сайт лёг посреди рабочего дня, админка выдаёт белый экран, а клиенты пишут, что форма заказа не отправляется - знакомая ситуация для любого, кто держит проект на WordPress дольше года. За практику на десятках проектов я собрал последовательность действий, которая помогает быстро исправить ошибки на сайте wordpress без хаотичного гугления и правок наугад. Ниже - чеклист, которым пользуюсь сам, от простых блогов до магазинов на WooCommerce с оплатой через T‑Bank и доставкой СДЭК.
С чего начать диагностику сайта на WordPress
Первым делом отвечаю себе на один вопрос: что изменилось перед тем, как всё сломалось. В 80% случаев причина - недавнее обновление плагина, темы или ядра, либо ручная правка кода. Хостинги вроде Timeweb, Beget и REG.RU хранят историю бэкапов и логи в панели управления, и это первое место, куда я смотрю.
Дальше включаю отладку в wp-config.php, чтобы вместо белого экрана видеть текст ошибки:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );После такой правки все ошибки PHP пишутся в файл wp-content/debug.log вместо того, чтобы выводиться на экран посетителям. Это критично: держать WP_DEBUG_DISPLAY включённым на боевом сайте нельзя, ошибки палят структуру сервера и путь до файлов.
Параллельно проверяю три вещи: доступна ли админка по адресу /wp-admin, отвечает ли сайт по FTP или SSH, и не упал ли весь хостинг целиком (проверяю через сторонний сервис вроде down for everyone or just me). Если сайт недоступен у всех и хостинг подтверждает сбой на своей стороне - это не ваша задача, ждите восстановления.
Белый экран смерти: как найти причину без паники
Белый экран (White Screen of Death) - самая частая жалоба, с которой ко мне приходят. Причины обычно три: исчерпан лимит памяти PHP, синтаксическая ошибка после правки functions.php или конфликт двух плагинов, которые одновременно перехватывают один и тот же хук.
Если админка недоступна вообще, подключаюсь по FTP или через файловый менеджер хостинга и переименовываю папку wp-content/plugins в plugins-off. Сайт сразу оживает - значит, дело в одном из плагинов. Возвращаю папке имя, а затем переименовываю уже подпапки внутри неё по одной, пока не найду виновника.
Если дело в лимите памяти, поднимаю его через wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );Но это временная затычка. Если сайту стабильно не хватает 256 МБ на обычной странице - где-то плагин жрёт память циклом или неоптимизированным запросом, и рано или поздно проблема вернётся уже на более крупном масштабе.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Ошибки 500, 403 и 404 - что каждая означает и как убрать
Коды ответа сервера дают конкретную подсказку, где искать проблему. Свёл частые случаи в таблицу - именно с ними сталкиваюсь на практике чаще всего.
| Код | Типичная причина | Что проверяю первым |
|---|---|---|
| 500 Internal Server Error | Синтаксическая ошибка в коде, повреждённый .htaccess, конфликт плагина | debug.log, содержимое .htaccess, откат последнего изменения |
| 403 Forbidden | Неверные права на файлы/папки, блокировка в .htaccess или файрволе хостинга | права 644 на файлы и 755 на папки, правила Deny в .htaccess |
| 404 на всех страницах кроме главной | Слетели правила ЧПУ (permalinks) | Настройки → Постоянные ссылки → Сохранить |
| 502/504 Bad Gateway | PHP-процесс не успевает ответить, перегруз сервера | время выполнения тяжёлых запросов, лимиты хостинга |
Ошибку 404 на всех страницах, кроме главной, чинит один клик - захожу в Настройки → Постоянные ссылки и просто нажимаю «Сохранить изменения» без правок. WordPress перегенерирует правила в .htaccess, и адреса снова начинают работать. Если это не помогло, значит .htaccess не пишется - тогда правлю права на файл вручную или добавляю блок правил самостоятельно.
Конфликты плагинов и тем: как вычислить виновника
Когда сайт открывается, но что-то работает криво - например, форма не отправляется, слайдер не крутится, а в консоли браузера красным горит ошибка JavaScript - почти всегда это конфликт скриптов от двух разных плагинов. Проверяю по стандартной схеме: отключаю все плагины, переключаюсь на стандартную тему вроде Twenty Twenty-Four, и смотрю, воспроизводится ли баг. Если нет - включаю плагины по одному, пока проблема не вернётся.
Отдельно держу в голове три частых источника конфликтов на моих проектах:
- Два SEO-плагина одновременно (например, Yoast и All in One SEO), которые дублируют мета-теги и schema-разметку
- Кэширующий плагин, который кэширует страницу вместе с ошибкой и мешает увидеть, что фикс уже применился
- Плагин с собственным jQuery-подключением, который ломает скрипты темы из-за несовпадения версий библиотеки
После каждого отключения обязательно чищу кэш - и плагина кэширования, и хостинга (у многих провайдеров есть отдельный серверный кэш поверх WordPress), иначе будете тестировать старую версию страницы и делать неверные выводы.
Ошибки базы данных и подключения к MySQL
«Error establishing a database connection» - вторая по частоте паника после белого экрана. Причины: неверные данные доступа в wp-config.php после переезда на другой хостинг, упавший MySQL-сервис, повреждённые таблицы или превышен лимит подключений к БД на тарифе.
Первым делом сверяю в wp-config.php четыре константы - DB_NAME, DB_USER, DB_PASSWORD, DB_HOST - с тем, что реально выдала панель хостинга. После миграции сайта эти данные почти всегда нужно менять руками, и забытый шаг - топовая причина обращений ко мне после самостоятельного переезда.
Если данные верные, а ошибка осталась, включаю встроенный инструмент восстановления:
define( 'WP_ALLOW_REPAIR', true );После добавления строки открываю ваш-сайт.ru/wp-admin/maint/repair.php и запускаю восстановление таблиц. Важно убрать эту константу из wp-config.php сразу после починки - с ней страница репарации доступна любому, кто узнает адрес.
Сбои WooCommerce и платёжных интеграций: T‑Bank и СДЭК
На магазинах отдельная категория проблем - не сайт целиком лежит, а ломается конкретный узкий процесс: оплата или расчёт доставки. С T‑Bank (бывший Тинькофф) на WooCommerce чаще всего сталкиваюсь с двумя вещами: истёкший или отозванный терминальный ключ после смены тарифа в личном кабинете эквайринга, и расхождение суммы заказа из-за скидочных купонов, которые модуль оплаты пересчитывает иначе, чем корзина.
С интеграцией СДЭК проблема почти всегда одна - не отвечает или отвечает с задержкой API расчёта стоимости доставки, и покупатель просто не может оформить заказ, потому что виджет висит в статусе загрузки. Проверяю в первую очередь статус страницы WooCommerce → Статус → Логи, там пишутся все ошибки внешних API-запросов с таймстампами, и по ним видно, падает ли конкретный вызов по таймауту или возвращает код ошибки.
Если своими силами разобраться сложно - код эквайринга и доставки завязан на внешние API, где документация часто устаревшая, а тестовый режим ведёт себя не так, как боевой - на этом этапе обычно и подключают разработчика, который уже настраивал такие модули. Я делаю это как отдельную услугу интеграции CRM и платёжных систем на разработке и поддержке сайтов на WordPress.
Когда чинить самому, а когда звать разработчика
Часть проблем безопасно чинится своими руками за 10-15 минут по инструкции выше. Часть требует доступа к коду, понимания хуков WordPress и опыта отладки чужих плагинов - и тут самостоятельная правка рискует превратить мелкую поломку в потерю данных.
| Ситуация | Можно самому | Лучше звать разработчика |
|---|---|---|
| 404 на всех страницах | Да, пересохранить постоянные ссылки | - |
| Белый экран после обновления плагина | Да, откатить или отключить плагин | - |
| Ошибка подключения к БД после переезда | Да, если знаете новые реквизиты | Если реквизиты неизвестны или таблицы повреждены |
| Сбой оплаты в WooCommerce | Частично, проверить логи | Да, если дело в коде интеграции или API |
| Сайт взломан, вставлен вредоносный код | Нет | Да, всегда |
Если поломка разовая и понятная - займёт максимум час своими силами. Если проблема повторяется раз в пару недель или требует правки кода плагина/темы, я оформляю это как техподдержку от 15 000 ₽/мес - туда входит регулярный мониторинг, бэкапы и разбор подобных инцидентов без отдельного счёта за каждый случай. Разовая диагностика и консультация по конкретной ошибке - от 3 000 ₽.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Как понять, что сайт на WordPress взломали, а не просто произошёл сбой?
Признаки взлома отличаются от обычного технического сбоя: в коде появляются незнакомые файлы с бессмысленными именами вроде wp-cache-xyz.php, в трафике Google Search Console вылезают чужие страницы про казино или реплики часов, а хостинг присылает письмо о рассылке спама с вашего аккаунта. Обычный сбой обычно локализован - упал один модуль или страница, взлом чаще затрагивает сразу несколько мест: файлы, базу данных и иногда .htaccess с редиректами на сторонние сайты.
Сколько стоит исправить ошибки на сайте WordPress у специалиста?
Разовая диагностика и точечное исправление у меня укладывается в консультацию от 3 000 ₽, если проблема локализована и не требует глубокого копания в коде интеграций. Для магазинов с сбоями оплаты или доставки, где нужно разбираться в API T‑Bank или СДЭК, оценка идёт по объёму работы. Если ошибки повторяются регулярно, выгоднее взять техподдержку от 15 000 ₽/мес вместо разовых обращений.
Можно ли восстановить сайт без бэкапа?
Частично можно. Файлы темы и плагинов почти всегда получится переустановить заново из официальных источников, а вот пользовательский контент - тексты, заказы, настройки - без бэкапа базы данных восстановить нельзя, если только не осталась кэшированная версия в Google или у сервиса вроде Wayback Machine, откуда можно вручную вытащить тексты. Именно поэтому автоматический бэкап - первое, что я настраиваю на любом проекте, который беру на поддержку.
Как часто нужно проверять сайт на WordPress, чтобы не искать ошибки в панике?
Достаточно раз в неделю открывать админку и смотреть, не висят ли уведомления об ошибках плагинов, и раз в месяц - проверять debug.log и логи хостинга даже если внешне всё работает. Многие сбои сначала проявляются как разовые ошибки в логах и только потом превращаются в белый экран или падение оплаты, так что регулярная проверка логов экономит часы аварийного ремонта.