Как обновить WordPress без поломки сайта: пошаговая инструкция 2026

«Появилось обновление WordPress 6.5» — и каждый раз дилемма. Обновишь — есть шанс что плагин конфликтнёт и весь сайт встанет белым экраном. Не обновишь — через месяц найдут уязвимость и сайт взломают. Я разобрал, как обновлять WordPress, плагины, тему и PHP так, чтобы не получить 500-ю ошибку и не угрохать выходные на починку. С пошаговым чек-листом, командами WP-CLI и инструкциями для нетехнических владельцев.

Зачем обновлять WordPress — и почему откладывать опасно

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

Что ломается у тех, кто НЕ обновляется

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

Кроме безопасности, старые версии перестают работать с современным хостингом. WordPress 5.x уже не запустится на PHP 8.2, который сейчас стандарт у Beget и Timeweb. Старые плагины перестают поддерживать новые ядра — через год вы обнаружите, что половина критичных плагинов больше не получает обновлений и помечена как «не тестировалось с вашей версией WordPress».

Что ломается у тех, кто обновляется БЕЗ подготовки

Другая крайность — нажать «обновить всё» и пойти пить кофе. Через 5 минут сайт показывает белый экран WordPress, 500-ю ошибку или «Briefly unavailable for scheduled maintenance». Конкретные причины я разберу в разделе про устранение поломок, а пока — навскидку:

• Плагин обновился под новое ядро, но другой плагин ещё не успел — конфликт
• Тема использует функцию, которая deprecated в новой версии — fatal error
• В обновлении изменился API, кастомный код в functions.php перестал работать
• PHP-расширение, которое требует новый плагин, не установлено на хостинге

Решение — не выбор между «обновляться» и «не обновляться», а правильный процесс: бэкап, staging, постепенно по одному, с проверкой после каждого шага.

Что проверить ДО обновления — чек-лист из 7 пунктов

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

Версия PHP на хостинге — совместима ли с новым ядром

WordPress 6.x официально поддерживает PHP 7.4 и выше, но рекомендует PHP 8.2 или 8.3. Если у вас на хостинге всё ещё PHP 7.0 или 7.2 — обновление ядра пройдёт, но плагины могут начать сыпать ошибки. Узнайте текущую версию через панель хостинга или через WordPress Site Health.

Требования и совместимость:

• PHP 7.4 — минимум, но устарел, постепенно теряет поддержку плагинов
• PHP 8.0–8.1 — рабочий вариант, основная масса плагинов поддерживает
• PHP 8.2 — современный стандарт, рекомендуется для всех новых сайтов
• PHP 8.3 — самая свежая версия, но не все плагины ещё с ней дружат

Если хостинг не даёт обновить PHP до 8.2+ — это сигнал, что пора переехать на современный хостинг. Beget, Timeweb, Selectel поддерживают свежие версии PHP из коробки.

Совместимость плагинов и темы — где смотреть «Tested up to»

В каталоге плагинов WordPress (wordpress.org/plugins/) на странице каждого плагина есть блок «Tested up to: X.X». Это последняя версия ядра, с которой плагин официально протестирован. Если у вас стоит плагин «Tested up to: 6.2», а вы обновляете ядро до 6.5 — есть шанс на конфликт.

Самый простой способ массовой проверки — расширение WP Compatibility Checker или встроенный в Site Health индикатор «Plugin and theme auto-updates». Они помечают каждый плагин по совместимости и показывают, какие из них могут вызвать проблемы.

Дочерняя тема (child theme) — или правки в functions.php напрямую?

Если вы или предыдущий разработчик правили functions.php в основной теме (а не в дочерней) — обновление темы перезапишет все правки. Проверить это просто:

# через SSH
diff -q wp-content/themes/your-theme/functions.php /tmp/original-functions.php

# или просто посмотреть размер — если меняли, размер будет отличаться от стандартного

Если правки есть и они в основной теме — НЕ обновляйте тему. Сначала переносите правки в дочернюю тему. Иначе после обновления потеряете всё. О том как это сделать — в разделе про обновление темы ниже.

Site Health — встроенный диагностический инструмент

В wp-admin → Инструменты → Здоровье сайта WordPress показывает список потенциальных проблем: устаревшие плагины, проблемы с REST API, неоптимальные настройки. Перед обновлением — пройдитесь по красным предупреждениям, исправьте критичные.

Логи ошибок — есть ли уже какие-то проблемы

Откройте wp-content/debug.log (если включён WP_DEBUG_LOG) или error log на хостинге. Если там уже сыпятся PHP-ошибки или предупреждения — лучше сначала разобраться с ними, потом обновляться. Иначе после обновления добавятся новые ошибки и не поймёте, что новое, а что старое.

Свободное место на диске и в БД

Обновление WordPress занимает временное пространство — распаковываются архивы, держится резервная копия. Минимум 100 МБ свободного места. Проверка через SSH:

df -h ~
du -sh ~/public_html

Время для отката — есть ли часы на ремонт

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

Шаг 1 — бэкап перед обновлением

Бэкап — это не «можно сделать» а «обязательно». Если что-то сломается при обновлении, бэкап откатит сайт на рабочее состояние за 5 минут. Без бэкапа вы либо разбираетесь в чужом коде часами, либо платите за срочное восстановление 5–10 тысяч.

Что включает полный бэкап

Полный бэкап WordPress — это три части:

• Файлы ядра, плагинов, темы — папка wp-content/ и корневые PHP-файлы (index.php, wp-load.php, wp-config.php и т.д.)
• База данных MySQL — все таблицы wp_* с контентом, настройками, пользователями
• Конфигурация — wp-config.php с доступами к БД, .htaccess с правилами сервера

Бэкап только файлов или только БД — это не бэкап. Если плагин обновился и сломал структуру таблицы — бэкап без БД не поможет. Если что-то изменилось в темах — без файлов не откатишь.

Как сделать бэкап через UpdraftPlus за 5 минут

UpdraftPlus — самый популярный бэкап-плагин для WordPress. Бесплатной версии хватает для большинства сайтов. Шаги:

1. Установите плагин: Плагины → Добавить новый → UpdraftPlus → Установить → Активировать
2. Откройте настройки: Настройки → UpdraftPlus Backups
3. Перейдите на вкладку «Settings» — выберите облачное хранилище (Google Drive, Dropbox, Yandex.Disk через сторонний адаптер)
4. Авторизуйтесь в выбранном облаке через кнопку
5. Вернитесь на вкладку «Current Status» и нажмите «Backup Now»
6. В диалоге выберите все три галочки: Database, Files, Send to remote storage
7. Нажмите «Backup Now», ждите 2–5 минут

В результате в облаке появятся 4 файла: backup_*-db.gz (БД) и три backup_*-others/plugins/themes/uploads.zip. Скачайте их локально для надёжности — облако одно, диск другое.

Бэкап средствами хостинга

Большинство нормальных хостеров делают бэкапы автоматически. У Beget — раздел «Резервные копии» в панели, бэкапы хранятся 7–14 дней. У Timeweb — аналогично. У Reg.ru — на отдельных тарифах. Для критичного обновления стоит сделать ручной бэкап через панель прямо перед обновлением — он гарантированно содержит свежее состояние.

Бэкап через WP-CLI

Для тех, кто работает через SSH:

# файлы
cd ~/public_html
tar -czf ~/backup-$(date +%Y%m%d).tar.gz wp-content wp-config.php .htaccess

# база данных
wp db export ~/db-$(date +%Y%m%d).sql --add-drop-table

Двухкомандный бэкап. Скопируйте оба файла локально или в облако через scp.

Шаг 2 — staging: проверяем обновление на тестовой копии

Staging-сайт — это полная копия продакшена, на которой можно обновляться без риска. Поломалось — пересоздал staging из свежей копии и проверяешь дальше. Это страховка следующего уровня после бэкапа.

Создание staging через WP Staging

Плагин WP Staging создаёт копию сайта в подпапке (например, your-site.ru/staging-001/) одной кнопкой. Шаги:

1. Установите плагин WP Staging из репозитория
2. Откройте WP Staging → Sites/Start в меню админки
3. Введите имя сайта (например, test-update)
4. Выберите, какие папки и таблицы клонировать (по умолчанию — всё)
5. Нажмите «Start Cloning» — займёт 1–10 минут в зависимости от размера сайта

В результате доступна по URL your-site.ru/test-update/. Логин/пароль те же, что на боевом. Теперь можно обновлять WordPress, плагины, тему — что бы ни произошло, боевой сайт не пострадает.

Staging средствами хостинга

У некоторых хостеров есть встроенная функция staging. У Beget на тарифе «WP-сборка» — Управление сайтом → Staging. У FastVPS — отдельные среды через WP Toolkit (Plesk). Если у вас такая возможность есть — пользуйтесь, будет надёжнее плагина (изолированная БД, отдельный пользователь).

Что тестировать после обновления на staging

Не верьте «сайт открылся — значит работает». Прокликайте по чек-листу:

• Главная страница — все блоки на месте, картинки грузятся
• Внутренние страницы (категории, услуги, контакты)
• Каталог и карточка товара (для интернет-магазина)
• Корзина: добавление, удаление, переход к оформлению
• Оформление заказа и оплата (тестовый заказ через карту хостинга)
• Форма обратной связи: отправляется и приходит на email
• Личный кабинет, регистрация, вход (если есть)
• REST API: /wp-json/wp/v2/posts возвращает JSON
• Админка: создание поста, редактирование настроек, медиатека

Если хоть что-то сломалось на staging — НЕ обновляйте боевой. Сначала разбираетесь, что именно сломалось.

Шаг 3 — обновление ядра WordPress

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

Обновление из админки — одна кнопка

Самый простой путь. В wp-admin → Консоль → Обновления или Dashboard → Updates есть кнопка «Обновить до версии X.X.X». Нажимаете, ждёте 1–2 минуты, готово. WordPress сам:

• Включает режим обслуживания (создаёт .maintenance файл)
• Скачивает новую версию с downloads.wordpress.org
• Распаковывает и заменяет файлы ядра
• Обновляет схему БД (если нужно)
• Удаляет .maintenance и возвращает сайт

Если процесс прерывается — может остаться .maintenance файл, и сайт будет показывать «Briefly unavailable for scheduled maintenance». Решение: подключиться по FTP и удалить .maintenance в корне.

Ручное обновление через FTP/SFTP — когда админка не работает

Если админка лежит после неудачного обновления, делаем руками:

1. Скачайте свежий WordPress с ru.wordpress.org/download/
2. Распакуйте архив локально
3. Через FileZilla подключитесь к серверу (или через SFTP)
4. Перейдите в корень сайта (public_html)
5. Загрузите все файлы и папки из распакованного архива КРОМЕ wp-content и wp-config.php — это заменит ядро, сохранив ваш контент и настройки
6. В файле wp-config.php ничего не трогайте — он остаётся ваш

После этого зайдите на your-site.ru/wp-admin/ — WordPress предложит обновить БД, нажмите кнопку. Готово.

Обновление через WP-CLI: wp core update

Самый быстрый способ для технических. Через SSH:

# обновить ядро до последней версии
wp core update

# обновить с проверкой версии (можно указать конкретную)
wp core update --version=6.5

# обновить структуру БД после ядра
wp core update-db

# проверить контрольные суммы
wp core verify-checksums

Команда wp core update делает то же самое, что кнопка в админке, но без UI. Удобно для cron-скриптов и массового обновления нескольких сайтов.

Шаг 4 — обновление плагинов без конфликтов

Плагины — главный источник проблем при обновлении. 7 из 10 поломок WordPress случаются именно на этом этапе, не на ядре. Подход: по одному, с проверкой, по приоритету.

По одному, не все сразу — почему это важно

Если обновить 30 плагинов одновременно и сайт сломается, как понять какой именно виноват? Никак. Придётся отключать всё и включать по одному до момента поломки — это часы работы. Если обновлять по одному с проверкой после каждого — поломка обнаружится сразу.

Через WP-CLI:

# список плагинов, требующих обновления
wp plugin list --update=available --fields=name,version,update_version

# обновить один конкретный
wp plugin update yoast-seo

# обновить все одной командой (НЕ рекомендуется без staging)
wp plugin update --all

Какие обновлять первыми, какие подождать неделю

Приоритеты обновления плагинов:

1. Security-плагины первыми — Wordfence, Solid Security. Они фиксят дыры безопасности и обычно стабильны
2. Технические плагины — кэширование (WP Rocket, LiteSpeed), оптимизация (Autoptimize). Тоже обычно стабильны
3. SEO и аналитика — Yoast, Rank Math. Стабильны, но не критичны
4. Кастомные плагины с большим функционалом — WooCommerce, Elementor. Их обновление часто что-то ломает, лучше через staging
5. Малоиспользуемые плагины с major-обновлениями — подождать неделю, посмотреть отзывы. Иногда первая мажорная версия глючит, в течение недели выходит фикс

Автообновление плагинов — когда включать, когда нет

В WordPress 5.5+ есть встроенное автообновление плагинов. По умолчанию выключено. Включается в списке плагинов кликом «Включить автообновления» рядом с каждым.

Когда включать: для security-плагинов (закрывают уязвимости — каждый день промедления = риск), для маленьких стабильных плагинов с минорными обновлениями.

Когда НЕ включать: для критичных плагинов с большой функциональностью (WooCommerce, Elementor, плагины оплаты), для премиум-плагинов с лицензией (могут потребовать активацию после обновления), на коммерческих сайтах в сезон.

Шаг 5 — обновление темы без потери изменений

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

Зачем нужна дочерняя тема и как она спасает кастомизацию

Дочерняя тема (child theme) — это тема, которая наследует все стили и функции родительской, но позволяет добавлять свои поверх. Когда обновляется родительская тема, дочерняя остаётся нетронутой. Все ваши правки сохраняются.

Создание дочерней темы за 3 шага:

1. Создайте папку wp-content/themes/your-theme-child/
2. Создайте в ней файл style.css с заголовком:

/*
Theme Name: Your Theme Child
Template: your-theme
Version: 1.0
*/

3. Создайте functions.php с подключением стилей родителя:

<?php
add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style('parent-style',
        get_template_directory_uri() . '/style.css'
    );
});

Теперь активируйте дочернюю тему в Внешний вид → Темы. Все правки делайте только в её файлах. Родительскую тему обновляйте без страха.

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

Если вы (или предыдущий разработчик) правили родительскую тему, надо сначала перенести правки в дочернюю:

1. Сделайте полный бэкап
2. Создайте дочернюю тему по инструкции выше
3. Найдите все ваши правки в родительской теме (особенно functions.php, style.css, шаблоны)
4. Скопируйте файлы с правками в дочернюю тему — например, wp-content/themes/your-theme/header.php в wp-content/themes/your-theme-child/header.php
5. Активируйте дочернюю тему
6. Проверьте сайт — всё ли на месте, выглядит ли так же
7. Только теперь обновляйте родительскую тему

Звучит долго, но делается один раз и навсегда решает проблему обновлений темы.

Шаг 6 — что делать сразу после обновления

Обновили — не отключаемся, проверяем что всё работает. У WordPress есть встроенные инструменты диагностики, плюс свой чек-лист.

Site Health и loopback request

В Инструменты → Здоровье сайта WordPress показывает результат внутренних проверок. Особое внимание:

• REST API — должен возвращать ответ. Если красный — что-то блокирует API (плагин безопасности, .htaccess)
• Loopback request — сайт может «звонить сам себе». Если красный — могут не работать cron-задачи и автообновления
• HTTPS — все ресурсы по https. Если жёлтый — есть «mixed content», нужно поправить
• PHP-расширения — все нужные модули установлены

Чек-лист после обновления

Прокликайте основные сценарии работы сайта (тот же чек-лист, что для staging):

• Главная — внешний вид, картинки, шрифты
• Внутренние страницы — все на месте
• Каталог и фильтры (для магазина)
• Тестовый заказ через сайт от начала до конца
• Формы — отправляются, приходят на email
• Админка — создаётся пост, работает медиатека
• Логи — нет ли новых PHP-ошибок в wp-content/debug.log

После обновления сайт может тормозить, потому что сбросились кэши и opcache. Это нормально первые сутки. Если медленно осталось через неделю — стоит подключить оптимизацию скорости и пересобрать кэширование. Кстати, после обновлений хорошо сделать оптимизацию БД — почистить ревизии, транзиенты, autoload-опции.

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

Бывает. Даже при идеальной подготовке. Главное не паниковать и идти по диагностической схеме.

Белый экран смерти (WSOD) — включаем WP_DEBUG в wp-config.php

Открываете сайт — пустая белая страница без единого слова. Это «White Screen of Death». Причина — фатальная PHP-ошибка, которую WordPress по умолчанию не показывает. Включаем дебаг через FTP в wp-config.php:

// найдите строку WP_DEBUG и поправьте:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// добавьте строку выше /* That's all, stop editing! */

Перезагрузите страницу. Теперь все ошибки пишутся в wp-content/debug.log. Откройте файл, найдите последние FATAL ERROR — там будет конкретная причина и какой плагин/файл виноват.

Самые частые причины WSOD после обновления: несовместимость плагина с новым ядром, использование deprecated-функций, превышение лимита памяти (увеличьте WP_MEMORY_LIMIT до 256M).

500-я ошибка после обновления — разбор по шагам

Сайт показывает «500 Internal Server Error». Чек-лист по убыванию вероятности:

1. .htaccess — переименуйте файл в .htaccess.bak через FTP. Если сайт открылся — проблема в нём. Зайдите в Настройки → Постоянные ссылки, нажмите «Сохранить» — WordPress пересоздаст .htaccess.
2. Версия PHP — после обновления плагина может потребоваться более новая версия. В панели хостинга переключите на PHP 8.2 или 8.3.
3. Лимит памяти — добавьте в wp-config.php: define('WP_MEMORY_LIMIT', '256M');
4. Плагины — переименуйте папку wp-content/plugins в plugins-off. Если сайт открылся — виноват один из плагинов. Переименуйте обратно и поочерёдно отключайте плагины из админки.
5. Тема — в БД через phpMyAdmin поменяйте опции template и stylesheet на стандартную тему twentytwentyfour. Если запустилось — виновата тема.

Откатить WordPress на предыдущую версию

Если ядро после обновления вызывает критические ошибки — откатываемся:

# через WP-CLI на конкретную версию
wp core update --version=6.4.3 --force

# или ручной откат
# 1. Скачать старую версию с https://wordpress.org/download/releases/
# 2. Распаковать
# 3. Загрузить через FTP, заменив все файлы кроме wp-content и wp-config.php
# 4. Зайти в админку, может попросить обновить БД — отказаться

Альтернативный путь — плагин WP Downgrade. Устанавливаете, выбираете нужную версию из списка, нажимаете «Update». Удобно для нетехнических.

Откатить плагин на старую версию

Если конкретный плагин стал виновником — плагин WP Rollback делает откат одним кликом. Установите, потом в списке плагинов появится ссылка «Rollback» рядом с каждым. Выбираете нужную версию, и плагин восстанавливает её.

Альтернатива — восстановить плагин из бэкапа: распакуйте архив, найдите папку нужного плагина в wp-content/plugins/, замените на сервере. После этого деактивируйте автообновление плагина, чтобы не повторилось.

Обновление PHP для WordPress — когда и как переходить на 8.2 / 8.3

PHP — это движок, на котором работает WordPress. Старая версия PHP — это медленный сайт и накапливающиеся проблемы безопасности. Современный стандарт — PHP 8.2.

Минимальные требования WordPress к PHP

Как обновить PHP в панели хостинга и не уронить сайт

Универсальный порядок для Beget, Timeweb, Reg.ru:

1. Сделайте полный бэкап (если не делали недавно)
2. Перед переключением проверьте все плагины через Site Health на совместимость с новым PHP. Wordfence, например, иногда требует обновления для PHP 8.3
3. Зайдите в панель хостинга → раздел «PHP» или «Версия PHP»
4. Выберите новую версию (8.2 или 8.3)
5. Сохраните настройки
6. Сразу проверьте сайт: главная, админка, формы
7. Если что-то сломалось — переключите PHP обратно через ту же панель, потом разбирайтесь

Переключение PHP — обратимая операция. Не работает на новой версии — за 2 минуты вернётся на старую. Это менее рискованно, чем обновление ядра WordPress.

Если хостинг физически не поддерживает PHP 8.2+ — это устаревшая платформа, пора переехать на современный хостинг. На современных Beget, Timeweb, Selectel PHP 8.2 идёт по умолчанию.

Чек-лист обслуживания WordPress — что и как часто

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

Ежедневно / еженедельно / ежемесячно — таблица регламента

Суммарно — около 10–15 часов в месяц на полноценное обслуживание сайта. Для одного сайта это нагрузка на разработчика 2–3 часа в неделю.

Когда передать обслуживание подрядчику и сколько это стоит

Считайте: час веб-разработчика — 2 000–3 500 ₽. Регулярное обслуживание — 10–15 часов в месяц. По часам это выходит 20 000–50 000 ₽ в месяц, если делать через разовые задачи фрилансеру.

Абонентское сопровождение от меня — от 5 000 ₽/мес и включает: ежедневные бэкапы, обновления (ядро, плагины, тема, PHP), мониторинг работоспособности 24/7, оперативное реагирование на инциденты, security-проверки, оптимизацию БД. Это в 4–10 раз дешевле, чем поштучные заказы.

Частые вопросы