WordPress 7.0.2: как проверить обновление и работу сайта
17 июля 2026 года вышел WordPress 7.0.2 — срочное защитное обновление. Оно закрывает две уязвимости, а для затронутых версий команда WordPress включила принудительную установку через систему автообновлений. Поэтому новый номер версии мог появиться в панели без участия владельца сайта.
Сам факт обновления — ещё не вся проверка. После замены файлов сайт может открываться, но перестать отправлять формы, принимать оплату, выполнять фоновые задания или показывать посетителям свежую версию страницы из-за кэша. Ниже — порядок, который помогает быстро проверить главное и не переходить к необоснованному откату.
Сначала проверьте, какая версия должна быть установлена
Исправление выпущено сразу для нескольких поддерживаемых веток WordPress:
| Установленная версия | Версия с исправлением |
|---|---|
| 7.0.0–7.0.1 | 7.0.2 |
| 6.9.0–6.9.4 | 6.9.5 |
| 6.8.0–6.8.5 | 6.8.6 |
Версии старше 6.8 не затронуты именно этими двумя проблемами. Это не означает, что устаревшую установку можно считать безопасной: у неё могут быть другие известные уязвимости и проблемы совместимости.
Номер версии можно посмотреть в разделе «Консоль → Обновления». Ещё один путь — «Инструменты → Здоровье сайта → Информация → WordPress». Если сайт показывает 7.0.0 или 7.0.1, 6.9.0–6.9.4 либо 6.8.0–6.8.5, исправление ещё не установлено.
Проверьте не только главную страницу
Откройте сайт в приватном окне браузера, чтобы не полагаться на старую авторизованную сессию. Проверьте главную, одну типовую внутреннюю страницу и самые важные для обращений или продаж разделы. Для интернет-магазина это карточка товара, корзина и оформление заказа; для корпоративного сайта — услуги, контакты и форма заявки.
Посмотрите страницы на компьютере и телефоне. Обновление ядра не должно менять дизайн само по себе, но эта проверка помогает заметить ошибки, которые проявились после одновременного обновления темы, плагина или кэша.
Пройдите критичные действия как посетитель
Страница с кодом 200 ещё не доказывает, что сайт решает задачу бизнеса. Выполните короткий функциональный тест:
- Отправьте тестовую заявку и убедитесь, что посетитель видит подтверждение, а письмо действительно приходит получателю.
- Если на сайте есть корзина, создайте тестовый заказ по согласованному сценарию и проверьте его появление в системе.
- Проверьте поиск, фильтры, личный кабинет и другие функции, без которых посетитель не сможет выбрать услугу или товар.
- Откройте административную панель и убедитесь, что страницы, записи и медиафайлы доступны без фатальных ошибок.
- Если используются обмены с CRM, учётной системой или внешним каталогом, проверьте время и результат последней синхронизации.
Тестовые заявки и заказы лучше явно помечать, чтобы сотрудники не приняли их за реальные обращения.
Проверьте резервную копию и возможность восстановления
Официальная инструкция WordPress рекомендует делать резервную копию перед обновлением. В рабочей копии должны быть и файлы, и база данных: отдельно сохранённая тема не поможет восстановить заказы, настройки и содержимое страниц.
Важно знать не только дату копии, но и порядок возврата. Уточните, где она хранится, относится ли к нужному домену и как восстановить сайт, если ошибка обнаружится позднее. Автоматическая надпись «backup completed» полезна только вместе с понятным способом восстановления.
Если обновление уже произошло, не откатывайте сайт только из-за смены версии. Сначала зафиксируйте симптомы и время их появления. Откат возвращает и исправленные уязвимости, поэтому его применяют как контролируемую временную меру, когда причина сбоя подтверждена и есть план повторного обновления.
Посмотрите «Здоровье сайта», но не ограничивайтесь им
В разделе «Инструменты → Здоровье сайта» WordPress показывает проблемы фоновых обновлений, связи с WordPress.org, REST API, запланированных задач и конфигурации сервера. Красное сообщение о неработающих фоновых обновлениях важно разобрать: иначе следующее защитное исправление тоже может не установиться.
При этом зелёный статус не проверяет доставку писем, оплату, обмен с CRM и все сценарии конкретного сайта. Экран диагностики дополняет функциональный тест, а не заменяет его.
Что делать, если версия не обновилась или появились ошибки
Не устанавливайте случайный «ремонтный» плагин и не отключайте защиту сервера наугад. Сначала сохраните текущее состояние, проверьте доступ к файлам и базе, посмотрите сообщения WordPress и журналы ошибок за время обновления. Частые технические причины — недостаточные права на файлы, невозможность связаться с WordPress.org, зависшая фоновая задача или нехватка ресурсов сервера.
Если в панели показано неудачное обновление, сайт застрял в режиме обслуживания или после установки перестали работать формы и оплата, нужна проверка с возможностью безопасного возврата. Когда своих доступов или проверенного порядка восстановления нет, эту задачу можно передать в техническую поддержку сайтов на WordPress.
Чек-лист после обновления WordPress
- Записать текущую версию WordPress и время проверки.
- Убедиться, что установлена исправленная версия своей ветки.
- Проверить свежую резервную копию файлов и базы данных.
- Открыть ключевые страницы на компьютере и телефоне.
- Отправить тестовую форму и проверить доставку письма.
- Проверить заказ, оплату, поиск, фильтры и интеграции, если они используются.
- Посмотреть критические сообщения в разделе «Здоровье сайта».
- Очистить кэш, если посетители получают старую версию страниц.
- Зафиксировать ошибки и время их появления до любых откатов.
