Новый глюк WordPress

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

Почему сбой WordPress — это в первую очередь SEO-проблема

Пока сайт лежит, его посещают не только люди. Робот приходит по расписанию, и от того, что он получит в ответ, зависит, останутся ли страницы в индексе.

Код ответа	Что означает	Как реагирует поиск	Что делать
200 с пустой страницей	Сервер отвечает «всё хорошо», но контента нет	Худший вариант: страница может быть переиндексирована как пустая и выпасть	Срочно чинить или переводить сайт на 503
500	Внутренняя ошибка сервера	Робот повторит попытку, при затяжной ошибке начнёт исключать страницы	Смотреть лог ошибок, чинить
503 с указанием времени повтора	Временно недоступен, техработы	Правильная реакция: робот подождёт и вернётся	Ставить осознанно на время работ
404 на живых страницах	Слетели постоянные ссылки	Массовое выпадение из индекса за несколько недель	Пересохранить настройки ссылок, проверить .htaccess
Таймаут, нет ответа	Сервер перегружен или упал	Обход резко замедляется	Проверить хостинг, ресурсы, атаку

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

Насколько всё критично, зависит от длительности. Час-два простоя обычно проходят бесследно. Сутки — заметное замедление обхода. Несколько дней подряд — реальные потери позиций, и восстановление занимает недели. Поэтому первое, что нужно завести, — внешний мониторинг доступности, который пришлёт уведомление раньше, чем позвонит клиент.

Белый экран и «на сайте возникла критическая ошибка»

Самый пугающий сбой: вместо сайта пустая страница либо короткая надпись про критическую ошибку. Причина почти всегда одна — фатальная ошибка PHP в плагине, теме или ядре, после которой выполнение скрипта прерывается.

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

Если письма нет, включается ручная диагностика. В файле wp-config.php временно включается отладка: константа WP_DEBUG в значение true, WP_DEBUG_LOG в true, а WP_DEBUG_DISPLAY обязательно в false, чтобы ошибки писались в файл wp-content/debug.log, а не показывались посетителям. Открываете лог — там имя файла и номер строки. Дальше два типовых сценария: если виноват плагин, папка этого плагина переименовывается через файловый менеджер хостинга или FTP, и сайт оживает; если виновата тема, в базе в таблице опций меняется активная тема на стандартную.

Третья по частоте причина — нехватка памяти. В логе это выглядит как сообщение об исчерпании допустимого объёма. Лечится увеличением лимита в wp-config.php до 256M и разговором с хостингом, если лимит не поднимается.

Чего делать нельзя: удалять папку плагина вместо переименования (потеряете настройки), править файлы ядра и «чинить» ошибку установкой ещё одного плагина.

Ошибка установления соединения с базой данных

Вторая классика. Сообщение говорит буквально то, что написано: PHP не смог подключиться к базе. Причин три.

Первая — сменились доступы. Такое бывает после переезда, смены пароля в панели хостинга или восстановления из бэкапа. Проверяются четыре значения в wp-config.php: имя базы, пользователь, пароль и хост. Последний чаще всего localhost, но у ряда хостеров это отдельный адрес сервера базы.

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

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

Важно: пока висит эта ошибка, сайт отдаёт 500-й код, и робот это видит. Если починка займёт больше часа, имеет смысл вручную поставить заглушку с 503.

Конфликты плагинов: как найти виновника за двадцать минут

Средний сайт живёт с двадцатью-тридцатью плагинами от разных авторов. Рано или поздно два из них начинают спорить: ломается вёрстка, перестаёт отправляться форма, пропадает кнопка в редакторе, сайт замедляется вдвое.

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

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

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

Сайт сломался после обновления

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

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

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

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

Взлом: как понять и что делать

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

Признаки, по которым это обнаруживается:

• В Вебмастере или Search Console появилось сообщение о вредоносном коде или о резком росте числа страниц.
• В поиске по вашему домену находятся страницы, которых вы не создавали, часто на другую тематику.
• Сайт нормально открывается с компьютера, но перенаправляет на посторонний ресурс с телефона или при переходе из поиска.
• В админке появился пользователь с правами администратора, которого вы не заводили.
• Резко выросла нагрузка на хостинг, письма с сайта уходят в спам.
• В файлах есть свежие даты изменения там, где вы ничего не правили.

Порядок действий при подтверждённом взломе жёсткий. Закрываете сайт заглушкой с кодом 503. Меняете все пароли: админка WordPress, панель хостинга, FTP, база данных. Снимаете полную копию заражённого сайта отдельно — она понадобится, чтобы понять точку входа. Восстанавливаете из заведомо чистого бэкапа, сделанного до заражения; если такого нет — переустанавливаете ядро и все плагины заново, оставляя только базу и папку загрузок. Обязательно проверяете список пользователей, файл .htaccess, папку загрузок на наличие PHP-файлов (их там быть не должно) и запланированные задания.

После чистки — обязательный шаг, о котором забывают: сообщить поисковым системам о том, что проблема устранена, через соответствующий раздел Вебмастера и Search Console, и проследить за индексацией. Мусорные страницы, которые успели попасть в индекс, отдаются с кодом 410, чтобы их выкинули быстрее.

Лечение взлома у специалиста стоит в 2026 году от 5 000 до 30 000 рублей в зависимости от глубины заражения. Профилактика — заметно дешевле.

Медленная админка и медленный сайт

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

Админка тормозит, когда раздулись служебные таблицы: ревизии записей (по умолчанию их число не ограничено), автозагружаемые опции, логи плагинов, спам в комментариях, таблица метаданных. Лечится ограничением ревизий в wp-config.php, чисткой таблиц и удалением плагинов, которые пишут в базу свою статистику.

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

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

Диагностика по симптому

Симптом	Вероятная причина	Первое действие
Белый экран целиком	Фатальная ошибка PHP, нехватка памяти	Почта администратора, затем debug.log
Сайт работает, админка — белая	Плагин, активный только в админке	Переименовать папку plugins целиком
Ошибка соединения с базой	Доступы, перегрузка, битые таблицы	Проверить данные в wp-config.php
Все внутренние страницы отдают 404	Слетели постоянные ссылки или .htaccess	Пересохранить настройки постоянных ссылок
Редирект на чужой сайт с телефона	Взлом, вредоносный код	Закрыть сайт, менять пароли, чистить
Не отправляются формы	Конфликт плагинов, кэш, почтовые настройки	Отключить кэш, проверить отправку письма
Изображения не загружаются в медиатеку	Права на папку загрузок, лимит на размер файла	Проверить права 755 и лимиты PHP
Сайт лёг после обновления PHP	Устаревший плагин или тема	Вернуть прежнюю версию PHP, обновить код
Периодические падения в часы пик	Нехватка ресурсов тарифа	Смотреть статистику нагрузки у хостера
Резкий рост страниц в индексе	Дорвеи после взлома или дубли фильтров	Проверить выдачу по домену, затем файлы

Бэкапы, восстановление и профилактика

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

Способ	Стоимость в год, ₽	Глубина хранения	Слабое место
Бэкап хостинга по умолчанию	Входит в тариф	Обычно 7–14 дней	Лежит на том же сервере
Плагин резервного копирования	0–8 000	Настраивается	Не работает, если сайт не открывается
Выгрузка в облако по расписанию	1 500–6 000	Месяцы	Требует настройки
Копии на уровне сервера или VPS	6 000–30 000	Любая	Нужен администратор
Ручная выгрузка перед изменениями	Бесплатно	Разовая	Забывают сделать

Чеклист профилактики, который я оставляю клиентам:

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

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

Коротко

• При любых работах сайт закрывается кодом 503 с указанием времени повтора. Заглушка с кодом 200 — самый вредный для индексации вариант.
• Час простоя проходит бесследно, сутки замедляют обход, несколько дней стоят позиций и недель восстановления.
• Белый экран: сначала почта администратора с письмом о фатальной ошибке, затем debug.log с записью в файл, а не на экран.
• Плагин отключают переименованием папки, а не удалением: настройки сохранятся.
• Ошибка соединения с базой — это доступы в wp-config.php, перегрузка сервера или битые таблицы. Режим восстановления базы обязательно выключается после починки.
• Виновник конфликта ищется делением пополам и только на тестовой копии. Два плагина с одной задачей не ставятся никогда.
• Обновления: бэкап, тестовая копия, плагины по одному. Внезапный сбой без ваших действий — часто смена версии PHP хостером.
• Признаки взлома: чужие страницы в выдаче по домену, редирект только с мобильных, новый администратор, рост нагрузки.
• После чистки взлома обязательно уведомить поиск и отдать мусорные страницы с кодом 410. Лечение стоит 5 000–30 000 рублей.
• Агрессивное кэширование ломает формы и корзины. После включения проверяйте, что заявки доходят.
• Бэкап должен быть автоматическим, храниться вне сервера и хотя бы раз проверенным на восстановление.

Если нужно SEO-оптимизатор Анатолий Кузнецов — помогу вывести сайт в топ Яндекса и удержать позиции.