Никогда не обновляйте плагины и темы прямо на продакшне. Staging-сайт — точная копия вашего сайта для безопасных экспериментов.

Метод 1: Плагин WP Staging (самый простой)

Установите WP Staging из репозитория WordPress
WP Staging → Create new staging site
Укажите поддиректорию (например, staging)
Нажмите Start Cloning
Staging будет доступен по адресу yoursite.com/staging

Учебный макет: Create new staging site. Выделены раздел, поле и следующий шаг. — Учебный макет. Расположение элементов зависит от версии панели. Данные приведены для примера.

Метод 2: Ручной клон через cPanel

# 1. Создайте субдомен staging.yoursite.com → папка /staging
# 2. Скопируйте файлы:
cp -r public_html/* public_html/staging/

# 3. Создайте новую БД (cPanel → MySQL Databases)
# 4. Экспортируйте БД:
mysqldump -u user -p production_db > staging.sql
# 5. Импортируйте в новую БД:
mysql -u user -p staging_db < staging.sql

# 6. В wp-config.php поменяйте DB_NAME и SITEURL

Деплой изменений со staging на продакшн

После тестирования на staging:

Плагины/темы: установите те же версии на продакшне
Код: скопируйте изменённые файлы через FTP
База данных: используйте WP Migrate DB Pro для переноса

⚠️ Закройте staging от индексации Google. В wp-config.php staging-сайта добавьте header X-Robots-Tag: noindex или используйте password protection.

💡 Для VPS используйте WP-CLI: wp db export и wp search-replace для замены URL в базе данных.

Разбор ошибок при работе со staging

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

Текст ошибки или симптом	Причина	Что делать
Error establishing a database connection сразу после клонирования	В wp-config.php остались DB-креды продакшна, а новая база называется иначе	Прописать DB_NAME, DB_USER и DB_PASSWORD новой базы staging
Ссылки и изображения ведут на продакшн-домен	В базе данных остались абсолютные URL исходного сайта	Выполнить wp search-replace именно на staging, а не на проде
There has been a critical error on this website после клонирования	Не хватило memory_limit PHP на клонирование большой базы данных	Временно поднять memory_limit в php.ini на время операции
403 Forbidden при открытии /staging/	Директория staging защищена паролем через .htaccess, но креды не переданы разработчику	Проверить Basic Auth в .htaccess или временно снять защиту для теста

О правильном порядке резервного копирования перед клонированием — в статье про бэкап WordPress.

Когда staging-копия не подходит

Тестирование платёжных шлюзов — большинство эквайрингов не принимают запросы со staging-поддомена без отдельной песочницы, тестируйте в sandbox-режиме самой платёжной системы
Проверка реальной нагрузки и скорости — staging обычно делит ресурсы сервера с продакшном, цифры будут неточными
Синхронизация с внешними вебхуками (Telegram-бот, CRM) — вебхуки продолжат стучаться на продакшн-URL, а не на staging
Долгоживущий staging как «вторая копия сайта» — со временем он расходится с продакшном по контенту и превращается в самостоятельный источник правды, которому нельзя доверять
Проверка функций, зависящих от реального IP посетителя (геолокация, антифрод) — staging-домен и его IP отличаются от продакшна, поведение таких функций будет другим

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

Автоматизация staging через WP-CLI на VPS

На VPS staging удобнее собирать скриптом на WP-CLI, а не через панель управления, — особенно если процесс нужно повторять регулярно:

wp db export /tmp/prod.sql --path=/var/www/production
scp /tmp/prod.sql user@server:/var/www/staging/
wp db import /tmp/prod.sql --path=/var/www/staging
wp search-replace 'example.com' 'staging.example.com' --path=/var/www/staging --all-tables

Подробный разбор самих команд WP-CLI — в статье про команды WP-CLI.

Как убедиться, что staging реально изолирован

robots.txt на staging содержит строку Disallow: /
В ответе сервера присутствует заголовок X-Robots-Tag: noindex
Учётные данные базы данных отличаются от продакшна, а не просто скопированы
В Google Search Console нет проиндексированных страниц со staging-доменом
Файл .htaccess или конфигурация веб-сервера для staging-поддомена физически отделены от продакшн-конфига, а не являются его копией с одной изменённой строкой

curl -sI https://staging.example.com/ | grep -i x-robots-tag
curl -s https://staging.example.com/robots.txt