Как безопасно обновить WordPress: пошаговое руководство

Многие сайты на WordPress месяцами не обновляются, потому что владелец боится, что после нажатия «Обновить» всё перестанет работать. Этот страх обоснован, но отсутствие обновлений опаснее: устаревшие плагины и темы — один из самых частых путей, которыми заходят атакующие. По отчёту Patchstack за 2025 год, 91% новых уязвимостей в экосистеме WordPress приходился на плагины, 9% на темы, а в самом ядре их нашли всего 6.

Покажу Вам, как безопасно обновить WordPress в спокойном порядке, с копией и планом на случай сбоя. В конце Вы получите контрольный список на 15 минут, который можно распечатать и держать у компьютера.

Почему обновления ломают сайты

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

• плагин, несовместимый с новой версией ядра или PHP,
• тема, которая переопределяет функции плагина (особенно старая, купленная несколько лет назад),
• изменения, внесённые прямо в файлы темы, которые исчезают после обновления,
• слишком много изменений сразу, из-за чего неизвестно, что сломало сайт.

Все эти риски можно снизить подготовкой. Начинаем с копии.

Шаг 1: сделайте копию файлов и базы данных

Резервная копия сайта — это две вещи: файлы (тема, плагины, фотографии из медиабиблиотеки) и база данных (контент, настройки, заказы). Отсутствие одной из них означает, что восстановление не получится.

Где её сделать:

1. У хостинг-провайдера. Многие хостинговые компании делают копии автоматически. Проверьте в панели, от какого дня последняя и как её восстановить.
2. Плагином для резервного копирования. Многие плагины сохраняют копию на внешнем облачном диске. Это важно, потому что копия на том же сервере может исчезнуть вместе с сайтом.
3. Вручную. Скачайте файлы по FTP, а базу экспортируйте в панели хостинга.

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

Шаг 2: проверьте на тестовой копии

Тестовая копия (по-английски staging) — это точная копия сайта по другому, скрытому адресу. Сначала Вы обновляете её, проверяете, всё ли работает, и только потом повторяете изменения на основном сайте.

Часть хостингов предлагает это в панели как готовую функцию, хотя не во всех тарифах. Загляните в предложение своего поставщика и поищите названия «staging», «тестовая среда» или «клонирование сайта». Если у Вашего хостинга этого нет, существуют плагины, которые создают тестовую копию в подкаталоге.

Для обычного сайта-визитки это можно пропустить, если у Вас хорошая копия. Для магазина, бронирований и платежей тестовая копия обязательна: ошибка в кассе стоит реальных заказов.

Шаг 3: обновляйте в правильном порядке

Порядок имеет значение. Я придерживаюсь такого:

1. Плагины, один за другим, а не все сразу.
2. Тема (и дочерняя тема, если Вы её используете).
3. Ядро WordPress.
4. Версия PHP на сервере, если хостинг её повышает (об этом ниже).

После каждого обновления откройте главную страницу, одну внутреннюю страницу и контактную форму. Это занимает минуту, а если что-то сломается, Вы точно знаете, какое изменение виновато. Обновление плагинов по одному — самый простой способ поиска неисправностей. Если у плагина Вы видите сообщение «Обновление не будет работать с используемой версией WordPress», вернитесь к нему после обновления ядра.

Перед обновлением ядра прочитайте, что меняет новая версия. В панели в разделе Консоль → Обновления (в польском интерфейсе Kokpit → Aktualizacje) Вы увидите, требует ли WordPress более новой версии PHP и отмечен ли какой-либо плагин как непроверенный с этой версией.

Шаг 4: PHP — тихий виновник

Многие сбои возникают не из-за самого WordPress, а из-за смены версии PHP на сервере. Старые плагины бывают несовместимы с новым PHP, а новый WordPress может требовать более новой версии PHP, чем у Вас. Версию Вы найдёте в панели WordPress в разделе Инструменты → Здоровье сайта (Narzędzia → Stan witryny), на вкладке «Информация» (раздел «Сервер»).

По данным wordpress.org, актуальный WordPress (в октябре 2026 г. версия 7.1) требует не ниже PHP 7.4, а рекомендуется PHP 8.3 или новее. Доступные у хостинга версии PHP можно проверить в его панели. Подробнее о том, почему старый PHP — проблема, я пишу в совете PHP 8.2 и конец поддержки: проверьте свой сайт. Меняйте PHP отдельно от обновления WordPress, лучше на тестовой копии.

Автоматические обновления: что включить, а что нет

WordPress сам устанавливает малые версии ядра, то есть в основном исправления безопасности. Это хорошая настройка по умолчанию, и отключать её я не советую. Обратите внимание на большие версии: в установках, созданных начиная с WordPress 5.6 (декабрь 2020 г.), они по умолчанию тоже устанавливаются сами. Проверить это можно в Консоль → Обновления. Надпись «Этот сайт автоматически обновляется до каждой новой версии WordPress» означает, что большие версии устанавливаются автоматически, а ссылка под ней переключает обновления только на выпуски поддержки и исправления безопасности. Плагины и темы по умолчанию требуют Вашего клика, но Вы можете включить для них автоматические обновления по ссылке «Включить автообновление», отдельно у каждого плагина (в разделе Плагины) и у темы (в Внешний вид → Темы).

Моё правило:

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

Что делать, если сайт упал

Даже при хорошей подготовке случается сбой. Сначала спокойно, без кликов наугад. План на случай сбоя:

1. Проверьте почту администратора. Когда плагин или тема вызывает критическую ошибку, WordPress отправляет на административный адрес e-mail (из Настройки → Общие) сообщение со ссылкой на режим восстановления, если сервер отправляет письма. В польской версии панели этот режим называется «tryb awaryjny», а ссылка по умолчанию действительна в течение суток. После входа по ней неисправный плагин приостанавливается только в Вашем сеансе, поэтому отключите его или обновите в панели. До тех пор посетители продолжают видеть ошибку.
2. Отключите недавно обновлённый плагин. Если в панель войти не удаётся, подключитесь по FTP или через файловый менеджер и переименуйте его папку в wp-content/plugins, например дописав -off. WordPress перестанет её загружать.
3. Включите вывод ошибок. В файле wp-config.php можно временно записывать сообщения в журнал:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Ошибки Вы найдёте в файле wp-content/debug.log. После исправления верните WP_DEBUG в значение false и удалите файл debug.log, потому что по умолчанию он лежит в каталоге, доступном из интернета, и может раскрывать подробности сайта.

4. Восстановите копию. Если через 30 минут Вы по-прежнему не понимаете, в чём дело, не боритесь дальше. Восстановите копию, сделанную до обновления, и попробуйте снова на тестовой копии.
5. Запишите, что произошло. Название плагина и текст ошибки пригодятся Вам или тому, кто Вам поможет.

Хорошо иметь в телефоне номер поддержки хостинга. Часто там умеют восстановить копию за несколько минут.

Плагины, заброшенные авторами

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

Как их найти:

• в Консоль → Обновления посмотрите, нет ли у плагинов, ожидающих обновления, пометки «Не проверено» в совместимости с Вашей версией WordPress, а в Плагины нажмите «Подробнее» и проверьте, нет ли предупреждения, что плагин не тестировался с используемой версией WordPress,
• в каталоге плагинов на wordpress.org проверьте дату последнего обновления,
• удалите плагины, которыми больше не пользуетесь. Отключённый плагин по-прежнему лежит на сервере и по-прежнему может содержать уязвимость.

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

Контрольный список на 15 минут перед обновлением

Распечатайте и отмечайте перед каждым крупным обновлением:

1. Полная копия (файлы и база) сделана сегодня и сохранена вне сервера.
2. Я знаю, как её восстановить и кому звонить в хостинге.
3. В Консоль → Обновления проверено, что именно будет обновляться.
4. Проверена версия PHP (Инструменты → Здоровье сайта) и требования новой версии.
5. Для магазина и бронирований: сначала обновление на тестовой копии.
6. Отключены или удалены плагины, которыми я не пользуюсь.
7. Обновление в порядке: плагины → тема → ядро, одно изменение за раз.
8. После каждого изменения проверено: главная страница, внутренняя страница, контактная форма, а в магазине добавление в корзину.
9. В конце выполнен тестовый заказ или бронирование, если они у Вас есть.
10. Записаны дата и список изменений в заметке.

Срок лучше выбрать на вторник или среду утром, а не на пятницу после обеда. Если что-то сломается, у Вас будет целый рабочий день на исправление.

Как проверить, в каком состоянии Ваш сайт

Если Вы не знаете, не остался ли Ваш сайт без должного ухода, начните с бесплатного инструмента «Проверить сайт». За 30 секунд он проверяет скорость, SEO, безопасность и другие области, а результат показывает, что нужно исправить в первую очередь. Он не заменит просмотр панели WordPress, но сразу покажет видимые проблемы.

Итог

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

Если не хотите заниматься этим самостоятельно, я возьму обновления на себя в рамках технической поддержки: копии, обновления и быстрая реакция от 149 зл в месяц без НДС. Можете также написать мне, и я отвечу в течение 24 часов.