Під час перенесення сайту на інший хостинг недостатньо просто скопіювати файли та базу даних. Користувачі потрапляють на сервер за DNS-записами, тому саме зміна DNS визначає, коли відвідувачі почнуть бачити нову версію сайту. Якщо виконати перемикання поспіхом, частина людей ще деякий час потраплятиме на старий сервер, а інша — на новий.
Така ситуація називається DNS-пропагацією. Вона може супроводжуватися тимчасовою недоступністю, різними версіями сайту, помилками входу або втратою даних, якщо сайт продовжує приймати замовлення на старому сервері. Безпечне перенесення передбачає підготовку, перевірку та лише після цього зміну DNS.
TTL перед міграцією
TTL (Time to Live) визначає, як довго DNS-відповідь зберігатиметься в кеші провайдерів, браузерів і локальних мереж. Чим більший TTL, тим довше частина користувачів може отримувати стару IP-адресу після перемикання.
За кілька днів до перенесення варто зменшити TTL для записів, які планується змінювати, наприклад A або CNAME. Часто використовують значення від 300 до 600 секунд, але конкретний параметр залежить від налаштувань DNS-провайдера та особливостей домену.
- Перевірте, де саме керуються DNS-записи: у реєстратора, хостинг-провайдера або окремого DNS-сервісу.
- Зменште TTL заздалегідь, а не безпосередньо перед зміною IP.
- Після завершення перенесення поверніть оптимальне значення TTL, щоб зменшити кількість DNS-запитів.
Зменшення TTL не скасовує вже сформований кеш. Деякі мережі можуть ігнорувати задане значення або зберігати записи довше. Тому перемикання не варто планувати на період пікового навантаження чи важливої рекламної кампанії.
Основні DNS-записи
Перед зміною DNS потрібно зафіксувати поточну конфігурацію домену. Помилка в одному записі може вплинути не лише на сайт, а й на електронну пошту, піддомени або сторонні сервіси.
- A — спрямовує домен або піддомен на IPv4-адресу сервера.
- AAAA — використовується для IPv6-адреси.
- CNAME — створює псевдонім для іншого доменного імені.
- MX — визначає сервери, які приймають пошту домену.
- TXT — містить записи SPF, DKIM, підтвердження сервісів та інші службові дані.
- NS — вказує, які DNS-сервери є авторитетними для домену.
Якщо пошта працює через зовнішній сервіс, MX-, SPF- і DKIM-записи не можна автоматично замінювати на налаштування нового хостингу без перевірки. Інакше сайт може відкритися, але листи перестануть надходити або почнуть потрапляти до спаму.
До перемикання підготуйте новий сервер: перенесіть файли, базу даних, налаштуйте версію PHP, права доступу, SSL-сертифікат, cron-завдання та конфігурацію CMS. Для WordPress також важливо перевірити адресу сайту в налаштуваннях і переконатися, що посилання, медіафайли та підключення до бази даних працюють коректно.
Перед будь-якими змінами зробіть резервну копію файлів, бази даних і DNS-конфігурації. Якщо копіювання виконується вручну, перевірте, що архів можна розпакувати, а база даних дійсно містить потрібні таблиці. Неповна копія не захистить від втрати даних.
Якщо проблема пов’язана не лише з хостингом, а й зі статусом домену, окремо ознайомтеся з матеріалом Що робити, якщо закінчилася реєстрація домену.
Паралельна робота серверів
Найбезпечніший підхід — певний час підтримувати старий і новий сервер паралельно. На новому сервері сайт перевіряють до зміни DNS, використовуючи тимчасовий домен, тестовий піддомен або локальний файл hosts. Це дає змогу виявити помилки без впливу на всіх відвідувачів.
Перевірте на новому сервері:
- завантаження головної сторінки та ключових розділів;
- роботу форм зворотного зв’язку, пошуку й авторизації;
- створення замовлення або іншої критично важливої дії;
- підключення до бази даних;
- завантаження зображень, файлів і статичних ресурсів;
- роботу HTTPS без помилок сертифіката;
- редиректи, правила веб-сервера та URL без дублювання домену.
Особливо уважно потрібно працювати із сайтами, де дані змінюються протягом дня: інтернет-магазинами, порталами, системами бронювання та сайтами з активними заявками. Якщо після первинного копіювання на старому сервері з’являються нові замовлення або коментарі, перед фінальним перемиканням знадобиться повторна синхронізація бази даних.
Не редагуйте одночасно робочу базу на двох серверах без чіткого плану. Це може спричинити конфлікти та втрату частини записів. На час фінальної синхронізації іноді тимчасово обмежують приймання змін або переводять сайт у режим технічних робіт — але лише після створення резервної копії та попередження користувачів.
Перевірка з різних мереж
Після зміни DNS сайт може відкриватися по-різному залежно від провайдера, регіону, типу підключення та DNS-кешу. Перевірка з одного комп’ютера не показує повної картини.
Для контролю використовуйте кілька способів:
- мобільний інтернет і домашню або офісну мережу;
- різні браузери та пристрої;
- зовнішні DNS-перевірки для A, AAAA, CNAME і MX-записів;
- команди
dig,nslookupабо аналогічні інструменти; - перевірку через VPN або мережу з іншого регіону, якщо сайт має міжнародну аудиторію.
Порівнюйте не лише факт відкриття сторінки, а й IP-адресу сервера, версію контенту, роботу форм, авторизації та пошти. Якщо частина запитів іде на старий сервер, це ще може бути нормальним наслідком кешування. Якщо ж новий сервер повертає помилки 500, 502, 403 або проблеми з базою даних, DNS не є єдиною причиною — потрібно перевіряти конфігурацію сервера та застосунку.
Не очищайте кеш навмання на робочому сайті та не змінюйте системні файли без копії. Невірна правка конфігурації веб-сервера або файлу WordPress може зробити сайт недоступним навіть після правильного перемикання DNS.
Коли вимикати старий хостинг
Старий хостинг не слід вимикати одразу після зміни DNS. Частина користувачів і поштових серверів ще може звертатися до старої IP-адреси через кеш. Крім того, за цей час можна виявити помилки, які не проявилися під час тестування.
Перед відключенням переконайтеся, що:
- основні DNS-резолвери вже повертають адресу нового сервера;
- сайт стабільно працює з кількох мереж і пристроїв;
- нові замовлення, заявки, листи та інші дані надходять без помилок;
- SSL, редиректи, піддомени й пошта налаштовані коректно;
- створено фінальну резервну копію старого сайту та бази даних;
- на новому сервері є доступ до журналів помилок і панелі керування.
Замість негайного видалення облікового запису краще спочатку залишити старий хостинг активним на перехідний період, якщо це можливо. Збережіть резервні копії локально або в окремому надійному сховищі. Після остаточного вимкнення старого сервера відновлення даних може бути неможливим.
Якщо сайт залишається недоступним, DNS-записи суперечать один одному, втрачено доступ до реєстратора або під час синхронізації виникли помилки бази даних, варто зупинити подальші зміни та звернутися до спеціаліста. Спочатку потрібно визначити, на якому рівні проблема: у домені, DNS, мережі, веб-сервері, CMS чи базі даних. Лише після такої діагностики можна безпечно продовжувати перенесення.