WordPress надёжен, но сложен: ядро, тема, два-три десятка плагинов, сервер, база данных, кэш. Когда что-то из этого перестаёт стыковаться, сайт выдаёт ошибку, и часто — довольно лаконичную. Хорошая новость в том, что большинство сбоев повторяются из проекта в проект, и у каждого есть узнаваемый «почерк». Мы собрали ошибки, с которыми к нам обращаются чаще всего, и расписали, что за ними обычно стоит и в каком порядке искать причину.
Прежде чем чинить: три правила
- Не паникуйте и не переустанавливайте всё подряд. Хаотичные действия уничтожают следы, по которым можно найти причину, и иногда добавляют новых проблем.
- Сделайте резервную копию текущего состояния — даже сломанного. Файлы и база в момент сбоя могут понадобиться для разбора.
- Вспомните, что менялось. В подавляющем большинстве случаев ошибка появляется сразу после обновления, установки плагина, правки кода или работ на хостинге. Это главная подсказка.
Для диагностики пригодится доступ к файлам через FTP или файловый менеджер хостинга и к панели управления базой данных. Если таких доступов у вас нет, начните с того, чтобы их получить, — без них большая часть способов ниже недоступна.
«На сайте возникла критическая ошибка» и белый экран
Это самая частая ситуация. В старых версиях она выглядела как пустая белая страница, сейчас WordPress показывает сообщение о критической ошибке и, как правило, отправляет администратору письмо со ссылкой на режим восстановления. Причина почти всегда — фатальная ошибка PHP в плагине или теме.
Как найти виновника
- Проверьте почту администратора: в письме указано, в каком плагине или теме произошёл сбой, и есть ссылка для входа в режим восстановления, где проблемный компонент временно отключён.
- Включите журнал отладки в файле конфигурации, записывая ошибки в лог, а не на экран. В журнале будет точный файл и строка.
- Если доступа к админке нет, переименуйте папку подозрительного плагина через FTP — WordPress его деактивирует. Если виновник неизвестен, переименуйте всю папку плагинов, а затем возвращайте их по одному.
- Если сломалась тема, переименование её папки заставит WordPress переключиться на стандартную тему, если она установлена.
Частая причина — несовместимость с версией PHP. Хостинг обновил PHP, а устаревший плагин использует функции, которых больше нет. Временно можно вернуть прежнюю версию в панели хостинга, но правильное решение — обновить или заменить плагин.
«Ошибка установки соединения с базой данных»
Сайт целиком недоступен, и на всех страницах одна строка. Возможные причины в порядке вероятности:
| Причина | Как проверить |
|---|---|
| Неверные данные подключения после переноса или смены пароля | Сравнить имя базы, пользователя, пароль и хост в файле конфигурации с данными в панели хостинга |
| Сервер базы данных перегружен или недоступен | Посмотреть статус услуг у хостинга, проверить, работают ли другие сайты на том же аккаунте |
| Повреждённые таблицы | Запустить проверку и восстановление таблиц в панели управления базой |
| Исчерпан лимит соединений или места на диске | Проверить квоты тарифа и логи сервера |
Если ошибка появляется периодически, в часы пиковой посещаемости, это почти всегда признак того, что сайт перерос свой тариф или страдает от избыточных запросов — например, от ботов или неудачного плагина.
404 на всех страницах, кроме главной
Главная открывается, а любая внутренняя страница выдаёт «Не найдено». Обычно это слетевшие правила перезаписи адресов. Так бывает после переноса на другой сервер, смены конфигурации веб-сервера или удаления служебного файла с правилами.
Первое, что стоит сделать, — зайти в «Настройки» → «Постоянные ссылки» и просто нажать «Сохранить», ничего не меняя. WordPress перезапишет правила. Если не помогло, проверьте, есть ли в корне сайта файл с правилами для веб-сервера и разрешено ли их применение на хостинге. На серверах, где такие файлы не поддерживаются, правила прописывает администратор в конфигурации веб-сервера.
Сайт «завис» в режиме обслуживания
Сообщение «Сайт временно закрыт на техническое обслуживание. Зайдите через минуту» не исчезает и через час. На время обновления WordPress создаёт в корне скрытый служебный файл, а по завершении удаляет его. Если обновление прервалось — закрыли вкладку, оборвалось соединение, закончилось время выполнения скрипта, — файл остаётся.
Решение — удалить этот файл через FTP. Но на этом не останавливайтесь: прерванное обновление могло оставить плагин или ядро в полуобновлённом состоянии. Проверьте, что обновляемые компоненты работают, и при необходимости переустановите их.
Совет от студии: не обновляйте одновременно ядро, тему и два десятка плагинов одной кнопкой на рабочем сайте. Обновляйте партиями, начиная с самых важных, и проверяйте сайт после каждой. Если что-то сломается, вы сразу будете знать, что именно.
Ошибки памяти, загрузки и времени выполнения
«Допустимый объём памяти исчерпан»
Скрипту не хватило выделенной памяти. Лимит можно поднять в настройках PHP на хостинге или в конфигурации WordPress, но только до предела, разрешённого тарифом. Если память заканчивается на простых страницах, стоит искать прожорливый плагин, а не бесконечно поднимать лимит.
Не загружаются изображения и файлы
Сообщения об ошибке HTTP при загрузке или о превышении размера связаны с лимитами загрузки PHP, правами на папку загрузок или недостатком памяти для обработки больших изображений. Проверьте, что папка доступна для записи, и уменьшите фото до загрузки — это полезно в любом случае.
Превышено время выполнения
Тяжёлые операции — импорт товаров, регенерация миниатюр, резервное копирование — упираются в лимит времени выполнения скрипта. Такие задачи лучше запускать частями или через консольные утилиты на сервере.
Мелкие, но неприятные сбои
- Бесконечный редирект при входе в админку — часто после перехода на защищённый протокол: адреса сайта в настройках не совпадают с реальными, или конфликтуют настройки прокси и кэша.
- Сломанная вёрстка после обновления — устаревший кэш стилей или неудачная минификация в плагине оптимизации. Очистите кэш и отключите объединение файлов, чтобы проверить.
- Не публикуются запланированные записи — встроенный планировщик WordPress срабатывает только при посещении сайта; на малопосещаемых сайтах его лучше заменить серверным заданием по расписанию.
- Редактор блоков не загружается — конфликт скриптов, блокировка программного интерфейса сайта плагином безопасности или правилами сервера.
- Странные редиректы на чужие сайты, спам в выдаче — это уже не ошибка, а признак взлома, и действовать нужно иначе.
Последний пункт особенно важен. Если сайт ведёт себя необъяснимо — открывает рекламу, перенаправляет мобильных посетителей, в админке появились незнакомые пользователи, — не пытайтесь «починить» его обновлением плагинов. Нужна полноценная чистка, и этим занимается наша служба лечения сайтов от вирусов.
Как свести ошибки к минимуму
Большинство описанных сбоев предотвращаются простой дисциплиной сопровождения:
- автоматические резервные копии файлов и базы, хранящиеся отдельно от сервера;
- тестовая копия сайта для проверки крупных обновлений;
- минимальный набор плагинов, только из проверенных источников, с регулярными обновлениями;
- актуальная поддерживаемая версия PHP;
- мониторинг доступности, чтобы узнавать о падении раньше клиентов;
- журнал изменений: кто, что и когда менял на сайте.
Вывод
Ошибки WordPress выглядят пугающе, но обычно имеют понятные причины: несовместимый плагин, слетевшие правила адресов, прерванное обновление, неверные данные подключения к базе или нехватка ресурсов. Последовательная диагностика — журнал ошибок, отключение компонентов, проверка настроек — позволяет найти виновника без лишних потерь. Если сайт лёг, а разбираться самостоятельно некогда или страшно, напишите нам: специалисты технической поддержки восстановят работу и расскажут, что сделать, чтобы ситуация не повторилась.
