Ошибка на сайте WordPress: как понять причину и починить за 20 минут

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

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

Первое правило: не чинить наугад

Перед тем как открыть хоть один файл, сделайте две вещи.

Первое — резервную копию файлов и базы данных прямо в текущем, сломанном состоянии. Звучит странно: зачем сохранять сломанное? Затем, что сломанное всё ещё содержит ваши тексты, заказы и настройки, а следующие полчаса вы будете что-то менять, и любая из правок может сделать хуже. Копия — это точка, в которую можно вернуться. Как её делать и где хранить, разобрано в материале про резервные копии WordPress и восстановление.

Второе — запишите, что именно изменилось перед поломкой. Обновили плагин? Тему? Ядро? Хостинг переключил версию PHP? Кто-то вставил код в файл функций? Сайт не ломается сам по себе, и в 95 % случаев ответ на вопрос «что вы делали последним» и есть ответ на вопрос «что чинить».

Три симптома, которые различаются за минуту

Все аварии WordPress для владельца сайта сводятся к трём картинкам на экране. Разница между ними принципиальная: они лечатся в разных местах.

Критическая ошибка. На экране текст про то, что на сайте произошла критическая ошибка, и предложение почитать про устранение неполадок. Это фатальная ошибка PHP: какой-то код попросил то, чего нет, и выполнение остановилось. Виноват почти всегда плагин, тема или вставленный в файл функций фрагмент.

Белый экран. Страница пустая, без единого символа, код ответа при этом может быть и 200, и 500. Технически это та же фатальная ошибка, только вывод ошибок выключен и WordPress не успел показать своё сообщение. Причины те же плюс исчерпание лимита памяти.

Ошибка соединения с базой данных. Текст прямо говорит, что установить соединение не удалось. Здесь код сайта в порядке, а вот доступ к базе — нет: неверные данные в конфигурации, сервер базы не отвечает, таблицы повреждены или закончилось место на диске.

Отдельная категория — ошибка 500. Она может прийти и от PHP, и от веб-сервера, и отличить одно от другого важнее всего остального: у этих случаев разные исполнители. Разбор именно этого случая есть в отдельном материале про ошибку 500 и то, как отличить проблему хостинга от плагина.

Что на экране	Вероятная причина	С чего начинать
«На сайте произошла критическая ошибка»	Фатальная ошибка в плагине, теме или коде в файле функций	Письмо от WordPress на почту администратора, режим восстановления
Пустой белый экран	То же плюс нехватка памяти PHP; вывод ошибок отключён	Включить журнал ошибок, посмотреть последние строки
Ошибка соединения с базой данных	Неверные доступы, сервер базы не отвечает, повреждены таблицы, кончилось место	Проверить место на диске и доступы, затем писать хостингу
Ошибка 500 без пояснений	PHP или сам веб-сервер, вплоть до синтаксиса в .htaccess	Журнал ошибок сервера в панели хостинга
Сайт открывается, админка — нет	Плагин, работающий только в админке, или повреждённые файлы ядра	Отключить плагины через файловый менеджер
«Кратковременно недоступен для планового обслуживания»	Обновление прервалось и оставило служебный файл	Удалить файл .maintenance в корне сайта
Всё работает, но видно старую версию страницы	Кэш, а не ошибка	Сбросить кэш и проверить ещё раз

Письмо от WordPress и режим восстановления

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

Что происходит дальше. Вы переходите по ссылке из письма, входите в админку — и WordPress приостанавливает сбойный плагин или тему только для вашей сессии. Посетители продолжают видеть страницу с ошибкой, а вы получаете рабочую панель управления с уведомлениями, в которых прямо названо, какой компонент упал. Дальше вы его отключаете или чините и нажимаете «Выйти из режима восстановления». Ни файловый менеджер, ни правка кода для этого не нужны — так этот механизм описан в документации WordPress.

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

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

Журнал ошибок: как включить и что в нём искать

Если письмо не пришло и режим восстановления недоступен, следующий шаг — увидеть текст ошибки. У WordPress для этого есть две настройки в конфигурационном файле, и они описаны в справочнике по отладке на developer.wordpress.org.

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

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

Что искать в журнале. Открываете файл, мотаете в самый конец — последние строки и есть ваша авария. В строке будет слово Fatal error, текст ошибки и, главное, путь к файлу. По пути сразу видно виновника: если там wp-content/plugins/имя-плагина — дело в плагине, если wp-content/themes/имя-темы — в теме, если functions.php вашей темы — во вставленном коде.

Отключить плагины и тему, когда в админку не попасть

Классический способ, который работает всегда. В файловом менеджере панели хостинга или по FTP заходите в папку wp-content и переименовываете папку plugins во что-нибудь другое — например, plugins-off. Все плагины разом перестают подключаться. Пробуете открыть сайт.

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

Если сайт не ожил — очередь темы. Переименовываете папку активной темы в wp-content/themes: WordPress не найдёт её и переключится на стандартную тему из поставки, если она установлена. Оформление слетит, зато вы увидите, в теме дело или нет. Ради этого стандартную тему и стоит держать установленной.

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

Версия PHP и лимиты сервера

Два сценария дают ту же картинку, но лечатся в панели хостинга.

Версия PHP. Если хостинг переключил версию или вы сделали это сами, старый плагин или тема могут перестать работать. Симптом характерный: сайт лёг без единой вашей правки. Лечится возвратом прежней версии на время — и обновлением того, что отвалилось. Требования актуальной версии WordPress — PHP 8.3 или новее и база MariaDB 10.11 или MySQL 8.0 и новее. Подробности перехода на свежий PHP — в отдельном материале про версию PHP для WordPress.

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

Посмотреть текущие значения, не залезая в файлы, проще всего через «Инструменты → Здоровье сайта → Информация»: там собраны версия PHP, параметры сервера, размеры каталогов, права на запись и состояние базы.

Откат из резервной копии

Откат — не признак поражения, а нормальный ход. Разворачивать копию стоит в трёх случаях: каждый час простоя стоит денег; вы полчаса ищете причину и не приблизились; поломка случилась сразу после обновления.

Три вещи, о которых забывают. Копия должна быть свежей: месячной давности откатит вместе с сайтом и месяц заказов. Разворачивать нужно и файлы, и базу, иначе получите несовпадение версий. И причина после отката никуда не делась — разбирайтесь с ней на тестовой копии.

Когда звать хостинг и что ему написать

Писать в поддержку хостинга нужно сразу, без самодеятельности, если: сайт выдаёт ошибку соединения с базой данных, а доступы вы не меняли; на диске кончилось место; ошибка 500 приходит даже на статических файлах; сайт недоступен целиком, включая страницы, которые не обрабатываются WordPress; в панели видно, что сервер перезапускает процессы.

Чтобы разбор не растянулся на сутки, в первом же сообщении дайте: адрес страницы с ошибкой, время начала проблемы, что менялось перед этим, текст ошибки из журнала целиком и свой IP. Формулировка «сайт не работает, помогите» добавляет к диагностике несколько часов переписки.

Минуты	Что делаем	Что это даёт
0–2	Копия файлов и базы в текущем состоянии	Точка возврата, если дальше станет хуже
2–4	Вспомнить и записать последнее изменение	В большинстве случаев это и есть причина
4–6	Проверить почту администратора: письмо и ссылка восстановления	Имя сбойного компонента без единой правки файлов
6–9	Включить запись ошибок в журнал, открыть последние строки	Путь к файлу и тип ошибки
9–13	Переименовать папку плагинов, проверить сайт	Ответ на вопрос «плагин или не плагин»
13–16	Если не помогло — переименовать папку активной темы	Ответ на вопрос «тема или не тема»
16–18	Посмотреть версию PHP, память и место на диске	Отсекает случаи, которые чинит хостинг
18–20	Не нашли — разворачиваем копию и пишем в поддержку	Сайт работает, поиск причины продолжается спокойно

Частые вопросы

Сайт лежит второй час. Позиции в поиске упадут?

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

Можно ли просто переустановить WordPress поверх?

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

Ошибка появилась после обновления. Откатывать сам плагин?

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

Что делать, если админка открывается, а сайт — нет?

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

Стоит ли ставить плагин, который «чинит ошибки»?

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

Когда порядок не сработает и нужен специалист

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

Звать специалиста разумно, когда простой стоит дороже часа работы, когда у вас магазин с живыми заказами или когда после починки нужно ещё убедиться, что робот не успел наловить ошибок. Последнее — отдельная работа: после длительной аварии проверяют коды ответа, карту сайта и отчёты вебмастера. Если хочется, чтобы кто-то посмотрел на ситуацию со стороны, напишите через форму обратной связи — разберём, что за авария и чем она грозит.

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

Коротко

Перед любыми правками — копия файлов и базы в текущем состоянии, даже если состояние сломанное. И вспомните, что менялось последним: в подавляющем большинстве случаев это и есть ответ.

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

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

Журнал ошибок даёт точный путь к виновнику. Включать отладку на рабочем сайте можно только с выключенным показом ошибок посетителям и с обязательным отключением сразу после диагностики.

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

Авария на пару часов позициям не вредит — вредит регулярность. Сайт, который падает каждую неделю, теряет не только посетителей: поисковый робот обходит нестабильные сайты реже, и восстановление трафика после этого занимает месяцы. Поэтому техническая надёжность — это не про красоту, а про деньги: реклама работает ровно пока оплачен счёт, а поток из поиска — накопленный актив, и падения сайта бьют именно по нему. Разумно держать оба канала и постепенно наращивать поисковый, но фундамент у него — работающий сайт. SEO на сайте, который падает раз в неделю, превращается в бесконечное восстановление вместо роста.

Если сайт уже подняли, но непонятно, что потеряно и как быстро вернётся трафик, приходите на консультацию по продвижению — посмотрим коды ответа, индекс и отчёты вебмастера и решим, что делать в первую очередь. Разбор трёх конкретных аварий — критической ошибки, ошибки 500 и ошибки базы — лежит в отдельных статьях: как вернуть сайт после критической ошибки и что делать при ошибке соединения с базой данных.