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

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

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

Метод 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