# Обновление WordPress: как проверить изменения на копии сайта

Источник: https://quicklanding.ru/knowledge/wordpress-update-staging/

Как готовить обновление WordPress на отдельной копии: исходное состояние, внешние подключения, порядок проверки и возврат к рабочей версии.

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

> Проверка обновления должна повторять важные действия вашего сайта. Сообщение об успешной установке файлов не подтверждает работу всех сценариев.

![Экран с программным кодом для проверки обновления сайта](/assets/images/knowledge/wordpress-update-staging.webp)

## Зафиксируйте исходное состояние

Запишите версии WordPress, темы, плагинов и PHP, а также особые доработки. Уточните, есть ли изменения внутри сторонней темы или модуля. Если код редактировали непосредственно в обновляемых файлах, новая версия может заменить эти изменения.

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

## Подготовьте пригодную резервную копию

Для обычного WordPress требуется согласованный набор файлов и базы данных. Убедитесь, что копия создана до изменений, доступна владельцу и может быть восстановлена. Архив файлов без базы не возвращает записи и настройки типичного WordPress-сайта.

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

## Создайте отдельную проверочную среду

Разместите копию на отдельном адресе или в локальной среде. Ограничьте доступ и исключите её из обычной публикации. Закрытие от индексации и ограничение доступа являются разными мерами: конфиденциальные сведения не стоит защищать одним robots.txt.

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

| Проверка среды | Зачем нужна |
| --- | --- |
| Версии PHP и расширений | Чтобы условия были близки к рабочему сайту |
| Почта и мессенджеры | Чтобы тест не рассылал реальные уведомления |
| Платёжные подключения | Чтобы отделить проверочные операции |
| CRM и фоновые задачи | Чтобы не создавать рабочие записи из копии |
| Ограничение доступа | Чтобы копия не стала публичным источником данных |

## Обновляйте с понятной последовательностью

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

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

## Проверьте больше, чем внешний вид

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

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

## Перенесите результат на рабочий сайт

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

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

## Документация и проверка сведений

Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.

- [WordPress: обновление системы](https://wordpress.org/documentation/article/updating-wordpress/)
- [WordPress: резервные копии](https://developer.wordpress.org/advanced-administration/security/backup/)

## Материалы по соседним задачам

- [Конфликт плагинов: как найти причину без экспериментов на живом сайте](/knowledge/wordpress-plugin-conflict/)
- [Резервная копия сайта: как проверить, что её можно восстановить](/knowledge/website-backup-restore/)
- [Код и доработка сайтов](/services/development/)

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

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

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

### Можно ли проверить сайт на другом PHP?

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

### Почему нельзя просто перенести тестовую базу обратно?

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

Автор: Владимир Николаев