Как безопасно обновить WordPress, плагины и тему

Как безопасно обновить WordPress, плагины и тему

Краткий ответ: безопасное обновление WordPress начинается не с кнопки “Обновить”, а с backup, проверки совместимости, staging-копии, обновления по одному компоненту, проверки сайта после каждого шага и готового плана отката. Особенно аккуратно нужно обновлять WooCommerce, плагины оплаты, тему, конструкторы страниц и любые кастомные доработки.

Причина

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

Официальная инструкция WordPress по обновлению начинается с резервной копии базы данных и всех файлов сайта, включая .htaccess, а также с проверки, что backup действительно можно использовать. Это важный момент: backup, который нельзя восстановить, не защищает сайт. :contentReference[oaicite:1]{index=1}

Сайт после обновления чаще всего ломается по таким причинам:

• плагин несовместим с новой версией WordPress;
• тема использует устаревший PHP-код;
• обновление WooCommerce изменило шаблоны или структуру данных;
• на сайте есть правки в основной теме, а не в дочерней;
• обновление оборвалось из-за тайм-аута;
• на хостинге не хватает памяти или места на диске;
• версия PHP слишком старая или слишком новая для части плагинов;
• кеш отдаёт старые CSS/JS после обновления;
• security-плагин или WAF блокирует часть запросов;
• обновляли сразу много плагинов и стало непонятно, что именно сломало сайт.

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

Короткие ответы для AI-поиска

Как безопасно обновить WordPress?

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

Что обязательно сделать перед обновлением?

Сделать backup, проверить место на диске, версию PHP, совместимость плагинов, наличие дочерней темы, логи ошибок, доступ к FTP/SFTP/SSH и возможность отката.

Можно ли обновлять все плагины сразу?

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

Диагностика

Перед обновлением нужно понять, насколько сайт рискованный. Маленький блог и WooCommerce-магазин с оплатой, доставкой и кастомной темой нельзя обновлять одинаково.

Оцените риск перед обновлением

Тип сайта	Риск обновления	Как обновлять
Простой блог	Низкий	Backup, обновление, проверка страниц и форм.
Сайт услуг	Средний	Backup, staging, проверка форм, меню, SEO, адаптива.
WooCommerce	Высокий	Staging, проверка корзины, checkout, оплаты, доставки, писем.
LMS / личный кабинет	Высокий	Проверка ролей, доступов, курсов, прогресса, писем и cron.
Сайт с кастомной разработкой	Высокий	Staging, Git/backup, проверка PHP-ошибок, ручное тестирование функций.

Что проверить до обновления

• есть ли свежий backup файлов и базы;
• можно ли восстановить backup;
• есть ли доступ к FTP/SFTP/SSH;
• есть ли доступ к панели хостинга;
• какая версия PHP используется;
• нет ли критических ошибок в debug.log;
• достаточно ли места на диске;
• используется ли дочерняя тема;
• есть ли кастомные правки в теме или плагинах;
• какие плагины критичны для работы сайта;
• не просрочены ли лицензии платных плагинов;
• есть ли staging-копия сайта.

Если сайт коммерческий, лучше не обновлять его “на живую” без теста. Staging-копия позволяет проверить обновления отдельно от рабочего сайта и не рисковать заказами, заявками, оплатами и трафиком.

Решение

Безопасный порядок обновления зависит от сайта, но общий принцип один: сначала подготовка, потом тест, потом рабочий сайт, потом проверка.

1. Сделайте полный backup

Backup должен включать:

• базу данных;
• папку wp-content;
• плагины;
• темы;
• uploads;
• wp-config.php;
• .htaccess;
• кастомные файлы в корне сайта;
• файлы верификации Google, если они есть.

Не храните единственный backup внутри public_html. Если сайт сломается, заразится или будет удалён, backup может пострадать вместе с ним.

2. Проверьте backup восстановлением

Самая частая ошибка — сделать backup и не проверить, открывается ли он. Для важного сайта нужно хотя бы периодически делать тестовое восстановление на поддомене, staging-сервере или локальной копии.

Проверьте:

• архив файлов распаковывается;
• дамп базы импортируется;
• wp-config.php сохранён;
• uploads на месте;
• сайт открывается после восстановления;
• админка доступна;
• формы и ключевые функции работают.

3. Создайте staging-копию

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

На staging нужно проверить:

• главную страницу;
• страницы услуг;
• записи блога;
• формы обратной связи;
• мобильную версию;
• меню и виджеты;
• личный кабинет;
• корзину и checkout, если есть WooCommerce;
• оплату и доставку в тестовом режиме;
• ошибки в debug.log;
• консоль браузера;
• админку и редактор страниц.

4. Проверьте совместимость PHP

Перед обновлением важно проверить версию PHP. Иногда сайт ломается не из-за WordPress, а из-за того, что новая версия плагина требует более свежую PHP, а старая тема не работает на ней.

Что сделать:

• посмотреть текущую версию PHP на хостинге;
• проверить требования WordPress, темы и ключевых плагинов;
• проверить совместимость на staging;
• не менять PHP и все плагины одновременно на рабочем сайте;
• после смены PHP проверить debug.log и error_log.

5. Обновляйте по одному шагу

Если обновить всё сразу, а сайт сломается, придётся искать проблему среди десятков изменений. Безопаснее обновлять по этапам.

Практический порядок для большинства сайтов:

• обновить backup;
• обновить плагины на staging;
• проверить сайт;
• обновить тему на staging;
• проверить сайт;
• обновить WordPress на staging;
• проверить сайт;
• повторить тот же порядок на рабочем сайте;
• после каждого этапа очищать кеш и проверять ключевые страницы.

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

6. Не обновляйте критичный сайт в час пик

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

7. Проверяйте журнал изменений

Перед крупным обновлением посмотрите changelog. Особенно если обновляется:

• WooCommerce;
• платёжный плагин;
• плагин доставки;
• конструктор страниц;
• SEO-плагин;
• мультиязычный плагин;
• плагин безопасности;
• тема с кастомными шаблонами;
• плагин личного кабинета или LMS.

8. Очистите кеш после обновления

После обновления старые CSS, JS и HTML могут остаться в кеше. Из-за этого сайт выглядит сломанным, хотя файлы уже обновлены.

Очистите:

• кеш WordPress-плагина;
• серверный кеш хостинга;
• CDN;
• OPcache;
• Redis/Object Cache, если используется;
• кеш браузера.

Если после обновления сайт стал медленнее, полезно проверить отдельную инструкцию как ускорить сайт на WordPress. Иногда после обновлений меняются скрипты, кеш, SQL-запросы или cron-задачи.

Код

Важно: команды ниже могут повлиять на работу сайта, плагины, тему, базу данных, кеш и доступ к админке. Перед выполнением сделайте backup и проверьте команды на staging-копии. Особенно осторожно используйте их на WooCommerce, LMS, сайтах с оплатой и личными кабинетами.

Включить debug.log перед обновлением

Куда вставлять: wp-config.php, выше строки “That’s all, stop editing”.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

После проверки ошибок отключите активную отладку:

define( 'WP_DEBUG', false );

Проверить текущую версию WordPress через WP-CLI

Куда выполнять: SSH в корне сайта.

wp core version

Проверить доступные обновления ядра

Куда выполнять: SSH в корне сайта.

wp core check-update

Показать плагины с доступными обновлениями

Куда выполнять: SSH в корне сайта.

wp plugin list --update=available

Обновить один плагин

Куда выполнять: SSH в корне сайта. WP-CLI позволяет обновлять конкретный плагин по его slug, а не все плагины сразу. Это удобно для контролируемого обновления. :contentReference[oaicite:2]{index=2}

wp plugin update nazvanie-plagina

Обновить все плагины

Куда выполнять: SSH в корне сайта. Используйте только после backup и лучше после проверки на staging.

wp plugin update --all

Показать темы с доступными обновлениями

Куда выполнять: SSH в корне сайта.

wp theme list --update=available

Обновить одну тему

Куда выполнять: SSH в корне сайта.

wp theme update nazvanie-temy

Обновить ядро WordPress

Куда выполнять: SSH в корне сайта. Перед этим сделайте backup базы и файлов.

wp core update
wp core update-db

Проверить целостность ядра после обновления

Куда выполнять: SSH в корне сайта.

wp core verify-checksums

Удалить зависший файл .maintenance

Куда выполнять: SSH в корне сайта. Используйте только если обновление уже завершилось или оборвалось, а сайт продолжает показывать режим обслуживания.

rm .maintenance

Проверить PHP-синтаксис functions.php

Куда выполнять: SSH. Замените nazvanie-temy на реальную папку темы.

php -l wp-content/themes/nazvanie-temy/functions.php

Временно отключить все плагины через WP-CLI

Куда выполнять: SSH в корне сайта. Команда полезна, если после обновления сайт сломался и нужно быстро проверить конфликт плагинов.

wp plugin deactivate --all

Результат

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

После обновления обязательно проверьте:

• главную страницу;
• важные страницы услуг;
• формы заявок;
• мобильную версию;
• меню;
• поиск;
• личный кабинет;
• админку;
• редактор страниц;
• debug.log;
• error_log хостинга;
• консоль браузера;
• скорость загрузки;
• индексацию и sitemap, если обновлялся SEO-плагин.

Для WooCommerce дополнительно проверьте:

• карточку товара;
• добавление в корзину;
• корзину;
• checkout;
• купоны;
• доставку;
• оплату в тестовом режиме;
• письма клиенту и администратору;
• личный кабинет;
• логи WooCommerce.

Если после обновления появились ошибки 500, используйте отдельную инструкцию Ошибка 500 WordPress: причины и способы исправления.

Дополнительные способы

Используйте автоматические обновления осторожно

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

Учитывайте rollback в новых версиях WordPress

В WordPress 6.3 появилась функция отката при неудачном ручном обновлении плагина или темы: если процесс обновления не завершился, WordPress пытается восстановить предыдущую установленную версию. Это полезный механизм, но он не заменяет полноценный backup. :contentReference[oaicite:3]{index=3}

Ведите журнал обновлений

Для сайта бизнеса полезно вести простой журнал:

• дата обновления;
• кто обновлял;
• что обновлялось;
• версия до обновления;
• версия после обновления;
• был ли backup;
• что проверили после обновления;
• какие ошибки появились.

Не редактируйте основную тему напрямую

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

Проверяйте безопасность после обновлений

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

Откатывайте точечно

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

Не забывайте о базе данных

Некоторые обновления меняют структуру базы. Особенно это касается WooCommerce, LMS, SEO-плагинов, мультиязычных плагинов и конструкторов страниц. После обновления базы простой откат файлов может быть недостаточным.

Частые ошибки

Ошибка 1. Обновлять без backup

Это самая опасная ошибка. Если сайт сломается, а backup нет, восстановление может занять намного больше времени.

Ошибка 2. Обновлять всё сразу

Массовое обновление удобно, но если сайт сломается, будет сложно понять, какой плагин или тема виноваты.

Ошибка 3. Не проверять сайт после обновления

Сайт может открываться, но не работать: форма не отправляется, checkout не проходит, меню не раскрывается, стили сломаны, письма не уходят.

Ошибка 4. Обновлять рабочий сайт вместо staging

На маленьком сайте это иногда проходит без проблем. На коммерческом сайте с заказами, оплатами и кастомной разработкой это риск.

Ошибка 5. Игнорировать PHP-версию

Плагин может требовать новую PHP, а старая тема может не работать на ней. Поэтому версию PHP нужно проверять отдельно.

Ошибка 6. Оставлять включённый debug на рабочем сайте

WP_DEBUG_DISPLAY может показать посетителям техническую информацию. Ошибки лучше писать в debug.log, а после диагностики отключать отладку.

Ошибка 7. Не очищать кеш

После обновления старые CSS/JS могут остаться в кеше. Из-за этого сайт может выглядеть сломанным, хотя обновление прошло нормально.

Ошибка 8. Не проверять платные лицензии

Если лицензия истекла, плагин может не обновиться, а сайт останется на уязвимой или несовместимой версии.

Диагностика проблем

Проблема: сайт завис в режиме обслуживания

Возможная причина: обновление оборвалось, в корне сайта остался файл .maintenance.

Что делать: зайти через FTP/SFTP/SSH, удалить .maintenance, очистить кеш, проверить debug.log и повторить обновление аккуратно.

Проблема: после обновления белый экран

Возможная причина: PHP Fatal error в плагине, теме или кастомном коде.

Что делать: включить debug.log, отключить плагины через FTP, проверить активную тему. Если нужно, используйте инструкцию Белый экран WordPress: что делать и как восстановить сайт.

Проблема: после обновления ошибка 500

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

Что делать: проверить error_log, debug.log, .htaccess, PHP memory_limit, отключить плагины и очистить кеш.

Проблема: после обновления сломались стили

Возможная причина: кеш CSS, минификация, CDN, изменение файлов темы, конфликт конструктора страниц.

Что делать: очистить кеш, отключить минификацию CSS/JS, проверить консоль браузера и пересобрать стили конструктора.

Проблема: после обновления не работает форма

Возможная причина: JavaScript-ошибка, reCAPTCHA, REST API, кеш nonce, security-плагин.

Что делать: проверить Network и Console в браузере, исключить скрипты формы из оптимизации, проверить REST API и логи.

Проблема: после обновления не работает WooCommerce checkout

Возможная причина: конфликт платежного плагина, доставки, темы, кеша, AJAX, WooCommerce-шаблонов.

Что делать: проверить логи WooCommerce, отключить кеш для cart/checkout/account, проверить оплату и доставку в тестовом режиме.

Проблема: после обновления сайт стал медленным

Возможная причина: новый тяжёлый скрипт, миграция базы, сброшенный кеш, cron-задачи, конфликт object cache.

Что делать: проверить Query Monitor, Network, cron, Action Scheduler, кеш и логи сервера.

FAQ

Как часто нужно обновлять WordPress?

Проверять обновления лучше регулярно. Security-обновления не стоит откладывать надолго, а крупные обновления лучше сначала проверять на staging-копии.

Что обновлять первым: WordPress, плагины или тему?

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

Можно ли обновлять сайт без staging?

Можно, если сайт простой и есть рабочий backup. Но для бизнеса, магазина, LMS, сайта с оплатой и кастомным кодом staging очень желателен.

Что делать, если обновление сломало сайт?

Не удаляйте всё подряд. Включите debug.log, проверьте .maintenance, отключите плагины через FTP, временно смените тему, проверьте .htaccess, PHP и логи хостинга.

Нужно ли отключать плагины перед обновлением WordPress?

В старых подробных инструкциях WordPress это указывалось как один из шагов для ручного обновления. На современных сайтах чаще обновляют без полного отключения, но для рискованных сайтов лучше тестировать на staging и быть готовым отключить плагины при ошибке. :contentReference[oaicite:4]{index=4}

Можно ли включить автообновления плагинов?

Можно для простых и надёжных плагинов, если есть backup и мониторинг. Для WooCommerce, оплат, темы, конструктора страниц и критичных плагинов лучше использовать ручной контроль.

Почему после обновления сайт показывает старую версию дизайна?

Чаще всего виноват кеш: кеш-плагин, CDN, браузер, OPcache или object cache. Очистите все уровни кеша и проверьте страницу в режиме инкогнито.

Как безопасно обновить тему WordPress?

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

Что делать, если обновление не завершилось?

Проверьте файл .maintenance, error_log, debug.log, место на диске и права файлов. Не запускайте обновление повторно, пока не понятно, на каком этапе оно оборвалось.

Нужно ли обновлять плагины, которые отключены?

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

Вывод

Безопасное обновление WordPress — это не случайное нажатие на все доступные кнопки обновления. Это понятный процесс: backup, проверка совместимости, staging, обновление по шагам, очистка кеша и тестирование сайта после каждого важного изменения.

Для простого сайта достаточно аккуратного backup и проверки. Для WooCommerce, LMS, сайтов с личным кабинетом, оплатой и кастомной разработкой нужен более строгий подход: staging-копия, журнал обновлений, проверка логов, готовый откат и тестирование ключевых сценариев.

Главная цель — обновить сайт так, чтобы он стал безопаснее и стабильнее, но не потерял заявки, заказы, дизайн, SEO-настройки и важные функции.