Как обновить WordPress и не сломать сайт: порядок, копии, откат

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

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

Почему «работает — не трогай» больше не работает

Логика «не буду обновлять, а то сломается» понятна и звучит разумно ровно до первого взлома. Устаревшее ядро, тема и плагины — это набор публично описанных уязвимостей. Когда автор плагина закрывает дыру, он описывает её в списке изменений, и с этого момента уязвимость известна всем, включая тех, кто ищет непропатченные сайты автоматическими сканерами. Ваш сайт при этом никому лично не интересен: его находят перебором, по признаку версии.

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

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

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

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

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

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

И ещё: срочные обновления безопасности ставятся сразу, без ожидания планового дня. Их видно по формулировке в списке изменений — там будет слово «уязвимость» или «security».

Шаг нулевой: копия, которую вы умеете разворачивать

Перед обновлением делается резервная копия файлов и базы данных — это не рекомендация, а обязательный шаг. Официальная справка WordPress по обновлению формулирует это прямо: копируются база целиком, все файлы установки, а также .htaccess и robots.txt, если вы их правили. И отдельно оговаривается: без копии всего сайта и базы, сделанной до попытки обновления, успешный откат практически невозможен.

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

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

Порядок обновления по шагам

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

Шаг	Что проверить сразу после	Как откатить
0. Копия файлов и базы	Архив открывается, база выгружена целиком	—
1. Плагины по одному	Главная, карточка, форма; не появилось ли новых уведомлений	Установить прежнюю версию плагина или отключить его
2. Тема	Вёрстка на всех типах страниц, меню, подвал, телефон в шапке	Вернуть прежнюю версию темы из копии
3. Ядро WordPress	Админка, редактор записей, публикация тестового черновика	Развернуть копию файлов и базы
4. Версия PHP	Весь сайт плюс отправка формы и оформление заказа	Переключить версию обратно в панели хостинга
5. Сброс кэша	Открыть сайт в режиме инкогнито: видна ли новая версия	—
6. Контроль неделю	Отчёты вебмастера: коды ответа, доступность, ошибки обхода	Развернуть копию из шага 0

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

Что проверять после каждого шага

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

Главная страница — открывается, вёрстка на месте, нет пустых блоков. Внутренняя страница — карточка товара или статья, потому что у них другой шаблон. Форма заявки — не просто видна, а отправляется: заполните и отправьте тестовую заявку, письмо должно дойти. Корзина и оформление заказа, если это магазин, — до страницы оплаты включительно. Админка — открывается редактор, сохраняется черновик.

И один пункт, который экономит недели: после обновления загляните в «Инструменты → Здоровье сайта». Встроенный инструмент показывает критические замечания и рекомендации — устаревшую версию PHP, неработающие фоновые обновления, недоступность серверов обновлений, плагины, ждущие обновления. Это быстрее, чем искать проблему по симптомам.

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

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

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

Отдельно про ядро. Мелкие выпуски, которые закрывают уязвимости, в WordPress приходят автоматически по умолчанию — и это правильно, отключать их не надо. Крупные выпуски лучше ставить руками, через неделю-две после выхода, когда авторы плагинов выпустят свои совместимые версии.

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

Что обновляем	Чем рискуем	Автообновление
Мелкие выпуски ядра (безопасность)	Почти ничем	Оставить включённым
Крупные выпуски ядра	Несовместимость плагинов и темы	Руками, через 1–2 недели после выхода
Активная тема	Слетает вёрстка и правки, внесённые в файлы	Руками, правки — в детской теме
Движок магазина и оплата	Ломается корзина и приём заказов	Руками, с тестовым заказом после
Формы заявок	Заявки перестают доходить молча	Руками, с тестовой отправкой
Кэш и оптимизация	Белый экран, битая вёрстка, старые страницы	Руками, со сбросом кэша после
Мелкие вспомогательные плагины	Низкий	Можно включить

Отдельно про PHP

PHP — это язык, на котором работает сам WordPress, и его версию задаёт хостинг, а не сайт. Посмотреть текущую можно в панели хостинга или в разделе «Здоровье сайта → Информация → Сервер».

Актуальные требования WordPress — PHP 8.3 или новее и база MariaDB 10.11 либо MySQL 8.0 и новее. Если у вас 7.4 или 8.0, переходить нужно, но не прыжком через несколько версий: переключайтесь на ближайшую следующую, проверяйте сайт целиком, потом на следующую. Причина в том, что каждая версия убирает часть устаревших конструкций; прыжок сразу на три ступени даёт кучу ошибок одновременно, и вы не понимаете, какая из них главная.

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

Белый экран после обновления: что делать

Спокойно и по порядку. Если вы обновляли по одному, виновник известен — это последнее, что вы трогали. Заходите в файловый менеджер хостинга, переименовываете папку этого плагина в wp-content/plugins — он отключается, сайт поднимается.

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

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

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

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

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

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

Смотрите дату последнего обновления и совместимость в карточке плагина на wordpress.org. Если автор не появлялся больше года — ищите замену заранее, не дожидаясь, пока плагин перестанет работать на новом PHP. Заброшенный плагин опаснее необновлённого.

Обновление сломало вёрстку. Откатывать или чинить?

Зависит от того, сколько сайт зарабатывает. Если каждый час важен — откат и разбор на копии. Если нет — можно чинить на месте, но с ограничением по времени: не нашли за час, откатывайтесь.

Позиции в поиске могут просесть из-за обновления?

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

Можно ли обновлять через панель хостинга, а не из админки?

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

Когда порядок не поможет и нужен специалист

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

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

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

Коротко

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

Порядок: копия → плагины по одному → тема → ядро → PHP → сброс кэша. На каждом шаге меняется одна переменная, и виновник поломки известен сразу.

Копия обязательна, и она должна быть проверенной. Разверните её один раз в спокойной обстановке — иначе в аварии выяснится, что архив неполный.

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

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

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

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