Тестова копія перед міграцією: як перевірити сайт без ризику

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

Найбезпечніший підхід — спочатку створити тестову копію сайту, перевірити її в ізольованому середовищі й лише після цього переносити зміни в робочу версію. Це не усуває всі ризики, але дає змогу виявити значну частину проблем до моменту, коли вони вплинуть на відвідувачів і замовлення.

Що таке staging

Staging — це тестове середовище, у якому розгорнута копія робочого сайту. Воно може розміщуватися на окремому піддомені, іншому сервері або в окремому каталозі хостингу. Важливо, щоб тестова версія не змішувалася з продакшном — тобто з сайтом, який зараз бачать користувачі.

На staging можна перевірити оновлення CMS, плагінів і тем, зміну версії PHP, роботу після перенесення на новий сервер, а також налаштування кешування та SSL. Для WordPress бажано, щоб тестове середовище було максимально схожим на майбутній продакшн: з тією самою версією PHP, бази даних, вебсервером і ключовими розширеннями.

Перед початком робіт варто:

• створити резервну копію файлів і бази даних;
• записати поточні версії PHP, CMS, тем і плагінів;
• зафіксувати налаштування DNS, пошти, cron-завдань та інтеграцій;
• перевірити, хто має доступ до тестової копії;
• підготувати спосіб швидкого повернення до попередньої версії.

Резервна копія не повинна зберігатися лише на тому самому хостингу. Якщо під час міграції буде пошкоджено файли або базу даних, локальна чи віддалена копія дасть більше шансів відновити сайт без критичної втрати інформації.

Копіювання файлів і бази

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

Під час копіювання перевіряють:

• чи всі файли передані без помилок і в потрібних каталогах;
• чи збереглися права доступу до файлів і папок;
• чи імпортована база даних повністю;
• чи збігаються назва бази, користувач і пароль у wp-config.php;
• чи відповідає кодування бази даних вимогам сайту;
• чи не залишилися биті або неповні таблиці після імпорту.

Якщо staging працює на іншому домені або піддомені, у базі можуть залишитися старі абсолютні URL. Просте масове редагування SQL-файлів небезпечне для серіалізованих даних WordPress: воно може пошкодити налаштування віджетів, плагінів або тем. Для заміни адрес краще використовувати інструмент, який коректно обробляє структуру даних, і перед цим обов’язково зробити додаткову копію бази.

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

Тест форм та інтеграцій

Візуально сайт може виглядати справним, але критичні функції часто залежать від зовнішніх сервісів. Тому після міграції потрібно окремо протестувати форми зворотного зв’язку, замовлення, реєстрацію, відновлення пароля, поштові повідомлення та передачу даних у CRM.

Для кожної форми перевірте:

• чи відправляється запит без помилки;
• чи з’являється коректне повідомлення користувачу;
• чи надходить лист на потрібну адресу;
• чи не потрапляють повідомлення до спаму;
• чи передаються всі поля в CRM або іншу систему;
• чи не дублюються заявки після повторного натискання кнопки.

Платіжні системи, SMS-сервіси, аналітика та вебхуки на staging можуть працювати інакше, ніж у продакшні. Якщо інтеграція підтримує тестовий режим, використовуйте саме його. Не варто без перевірки проводити реальні платежі або надсилати тестові дані в робочу CRM — це може створити хибні замовлення чи дублікати клієнтів.

Окремо перевірте HTTPS, змішані запити, роботу JavaScript, завантаження файлів і відповіді AJAX. Якщо сайт використовує cron, черги або фонову обробку, переконайтеся, що відповідні завдання не запускаються паралельно на staging і не змінюють робочі дані.

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

Закриття від індексації

Тестова копія не повинна конкурувати з основним сайтом у пошуковій видачі. Якщо staging доступний з інтернету, його необхідно закрити від індексації та, бажано, обмежити доступ до нього для сторонніх осіб.

Найнадійніший варіант — захистити тестовий сайт авторизацією на рівні сервера. Додатково можна застосувати:

• заборону індексації в налаштуваннях SEO-плагіна;
• директиву noindex для сторінок тестової копії;
• заборону обходу в robots.txt;
• обмеження доступу за IP або через VPN;
• тимчасовий окремий піддомен без публічного поширення адреси.

Сам по собі файл robots.txt не є засобом захисту: пошукові роботи можуть не виконати його, а стороння людина все одно зможе відкрити сайт за прямим посиланням. Тому на staging не варто залишати реальні персональні дані, ключі API, платіжні реквізити або доступи до служб, якщо вони не потрібні для тестування.

Після завершення міграції перевірте, щоб заборона індексації випадково не залишилася на продакшні. Така помилка може поступово прибрати робочий сайт із пошукової видачі.

Перенесення змін у продакшн

Після тестування потрібно визначити, які саме зміни переносяться на робочий сайт. Не завжди безпечно просто замінити весь продакшн вмістом staging: за час перевірки могли з’явитися нові замовлення, коментарі, користувачі або записи в базі.

Перед фінальним перенесенням:

1. зафіксуйте список перевірених змін;
2. створіть свіжу резервну копію продакшну;
3. визначте період мінімальної активності користувачів;
4. за потреби увімкніть режим технічних робіт;
5. узгодьте порядок перенесення файлів, бази, конфігурації та DNS;
6. після завершення перевірте сайт із різних пристроїв і мереж.

Особливо уважно потрібно переносити базу даних, якщо на сайті постійно створюються нові записи. Повна заміна бази staging може стерти актуальні замовлення або заявки. У такій ситуації потрібна продумана синхронізація даних, а не механічне копіювання.

Після перемикання DNS перевірте код відповіді сторінок, SSL-сертифікат, перенаправлення, форми, авторизацію, оплату, пошту, аналітику та доступ до адміністративної панелі. Старий сервер не варто одразу видаляти: спочатку переконайтеся, що сайт стабільно працює, а резервні копії доступні. Якщо виявлено помилки, подальші дії краще виконувати після діагностики, оскільки необережне повторне копіювання або видалення файлів може ускладнити відновлення даних.