Поддержка сайта на WordPress: обновлять так, чтобы ничего не сломалось
В WordPress обновления одновременно главная защита и главная причина падений. Ставим их на копии, держим проверенные бэкапы, закрываем типовые дыры и делаем доработки по задачам.
Почему поддержка WordPress — отдельная работа
Сайт на WordPress состоит не из одной системы, а из ядра, темы и десятков плагинов, у каждого свой автор и свой график обновлений. Любое обновление может конфликтовать с остальными, а отказ от обновлений означает известную всему интернету уязвимость. Поэтому вопрос не «обновлять или нет», а «как обновлять, чтобы не ронять сайт».
Второе — WordPress самая массовая система в сети, и именно поэтому самая атакуемая. Перебор паролей к административной панели, поиск уязвимых версий популярных плагинов, загрузка файлов через незащищённые формы — всё это идёт автоматически, по всем сайтам подряд, без интереса к вашему бизнесу.
Третье — последствия взлома выходят за пределы сайта. Заражённый сайт получает пометку об опасности в поиске и теряет трафик быстрее, чем от любой потери позиций, а почта с домена начинает попадать в спам. Восстановление доверия занимает больше времени, чем лечение самого сайта.
Четвёртое — самописные правки. Если предыдущий разработчик менял файлы темы или ядра напрямую, обновление затирает эти правки молча: сайт не падает, просто перестаёт работать какая-то функция. Такие места выявляются на приёмке и выносятся туда, где обновление их не тронет.
Когда это нужно
Подходит любому работающему сайту на WordPress: от корпоративного до магазина на WooCommerce.
- Обновления не ставятся из страха что-то сломать
- Неизвестно, есть ли рабочие резервные копии
- Сайт уже взламывали или появлялись подозрительные страницы
- Разработчик недоступен, а мелкие правки копятся
- Сайт стал медленным, и непонятно, какой плагин виноват
Что входит
Берём технику на себя: от обновлений до реакции на инциденты.
- Приёмка: инвентаризация версий, плагинов, доступов и самописных правок
- Обновления ядра, темы и плагинов с проверкой на копии
- Резервное копирование и регулярная проверка восстановлением
- Базовая защита: права, учётные записи, формы, наблюдение за логами
- Скорость: кеш, изображения, выявление тяжёлых плагинов
- Доработки по задачам и ежемесячный отчёт
Разработка + GEO
Недоступность бьёт и по поиску, и по ИИ-ответам
Робот, который приходит и не получает ответ, возвращается реже; то же верно для ИИ-краулеров — страница, которая не отдалась, в ответ не попадёт. Поэтому мониторинг доступности и скорости в поддержке — не только про удобство клиентов.
GEO в нейросетях →Как работаем
Что на руках
- Обновления ставятся вовремя и не ломают работающее
- Есть резервная копия, из которой действительно можно восстановиться
- О сбоях вы узнаёте от нас, а не от клиентов
- 01Карта проекта: версии, плагины, слабые места
- 02Схема резервного копирования с проверкой восстановления
- 03Список закрытых уязвимостей и сделанных настроек
- 04Регламент работ со сроками реакции
- 05Ежемесячный отчёт по работам и инцидентам
Типовые дыры WordPress и что с ними делаем
Атаки на WordPress автоматические и однотипные, поэтому и защита от большинства из них однотипная. Базовый контур, который закрывается в первый месяц:
- Административная панель. Ограничение числа попыток входа, двухфакторная аутентификация, отказ от учётной записи с очевидным именем.
- Учётные записи. Инвентаризация администраторов, удаление забытых учёток прежних подрядчиков, понижение прав там, где администратор не нужен.
- Права на файлы. Самая частая находка — каталог загрузок с правом на исполнение: через него и заливают вредоносный код.
- Уязвимые плагины. Сверка версий с известными уязвимостями, обновление или замена. Заброшенные авторами расширения убираются, а не обновляются.
- Формы. Ограничение частоты отправки и проверка содержимого: иначе через них идёт и спам, и попытки загрузки файлов.
- Служебные файлы с версиями и настройками закрываются от доступа снаружи.
- Наблюдение за логами. Всплеск обращений к служебным адресам виден задолго до успешного взлома.
Чего мы не делаем: не ставим «плагин для безопасности» вместо настройки. Такой плагин создаёт ощущение защиты, добавляет нагрузку и сам становится ещё одной поверхностью для атаки.
Порядок обновления, при котором сайт не падает
Разница между «обновили и сломали» и «обновили и всё работает» — в порядке действий, а не в везении.
- Свежая копия непосредственно перед обновлением, а не вчерашняя.
- Тестовая площадка. Обновление сначала ставится на копию сайта, и там же проверяется работа ключевых сценариев.
- Чтение списка изменений. Что меняется, что объявлено устаревшим, какие расширения заявлены несовместимыми.
- По одному, а не всё сразу. Если обновить двадцать плагинов одновременно и сайт сломается, причину придётся искать перебором.
- Проверка после установки на рабочем сайте: формы, корзина, оплата, личный кабинет, вывод цен — то, что приносит деньги.
- Готовый откат. Решение об откате принимается быстро: вернуть работу важнее, чем немедленно понять причину.
Отдельный случай — мажорные обновления ядра и крупных плагинов для магазина. Они планируются как небольшой проект: с запасом времени, не в пятницу вечером и не в сезонный пик.
Резервные копии WordPress: что именно копировать
Копия, которую ни разу не разворачивали, — это предположение, а не копия. И копия не того, что нужно, ничем не лучше её отсутствия.
- База данных целиком: записи, страницы, настройки, заказы, пользователи. Для магазина потеря базы означает потерю заказов, а не только текстов.
- Каталог загрузок. Все изображения и файлы, которые добавляли через админку. Копия без него бесполезна для сайта с каталогом.
- Тема и плагины, включая самописные правки и платные расширения с лицензиями.
- Файл конфигурации — отдельно и в защищённом виде: в нём доступы к базе.
- Отдельное хранилище. Копия на том же сервере не спасает ни от отказа диска, ни от шифровальщика.
- Проверка восстановлением на тестовой площадке по расписанию. Это единственный способ узнать, что копия рабочая, до того, как она понадобится.
И цифра, которую стоит знать заранее: сколько времени занимает полное восстановление вашего сайта из копии. Выяснять её в день аварии — самый дорогой вариант.
Как разбираются инциденты на WordPress
Типовые аварии на этой системе повторяются, и порядок действий для них отработан.
- Белый экран после обновления. Отключение плагинов по одному через файловую систему, поиск виновного, откат его версии. При нехватке времени — возврат из копии и разбор на тестовой площадке.
- Сайт работает, функция нет. Чаще всего обновление затёрло правку в файлах темы или ядра. Правка восстанавливается и выносится туда, где обновление её не тронет.
- Сайт стал медленным без изменений. Смотрим разросшиеся служебные таблицы базы, автоматические обновления плагинов и сторонние скрипты, добавленные через админку.
- Подозрительные страницы в индексе. Признак заражения. Поиск вредоносного кода, закрытие точки входа, смена всех паролей и ключей, снятие пометки об опасности в панелях вебмастера.
- Перестали приходить письма с форм. Инцидент, который не видит мониторинг доступности: сайт работает, заявки теряются. Ловится регулярной проверкой ключевых сценариев, и она входит в сопровождение.
Каждый разобранный инцидент записывается в историю проекта: что случилось, что помогло, что сделали, чтобы не повторилось.
Вопросы
Обсудить: Поддержка WordPress
Оставьте контакты — перезвоним в течение рабочего дня, разберём задачу по «Поддержка WordPress» и как её связать с SEO и видимостью в ChatGPT и Perplexity. РФ и СНГ.