Як перенести сайт на WordPress на новий хостинг без простою

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

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

• Доступ до старого хостингу (файли й база даних або панель керування), нового хостингу та DNS-провайдера домену. DNS-провайдер — там, куди вказують NS-сервери: часто це реєстратор, іноді Cloudflare або старий хостинг.
• Повна резервна копія поточного сайту, яку ви завантажили собі, а не така, що зберігається лише на старому сервері.
• Публічна IP-адреса нового сервера. Якщо не впевнені, яка саме, див. Як знайти IP сервера.
• Версії PHP і бази даних старого сайту. Відтворіть їх на новому сервері або перевірте, що ваша тема й плагіни підтримують новіші версії.
• Список важливих сторінок: головна, запис, рубрика, пошук, контактна форма, кошик і оформлення замовлення, якщо у вас WooCommerce, а також wp-admin.

Уже зараз перевірте поточний TTL A-запису домену за допомогою перевірки TTL. Він знадобиться для розрахунку часу в кроці 1.

1. 1

   Крок 1: Знизьте TTL за добу

   У DNS-панелі встановіть TTL A-запису (і AAAA, якщо є) на 300 секунд, залишивши його спрямованим на старий сервер. Перед перемиканням зачекайте щонайменше стільки, скільки становив старий TTL. Див. Знизьте TTL перед перенесенням.

2. 2

   Крок 2: Створіть резервну копію старого сайту

   Зробіть повну резервну копію файлів і бази даних і завантажте її. Це ваш план відкату, якщо щось піде не так.

3. 3

   Крок 3: Скопіюйте файли й базу даних на новий хостинг

   Скористайтеся плагіном для міграції, інструментом перенесення від хостингу або скопіюйте вручну через WP-CLI. Залиште home і siteurl на робочому домені.

4. 4

   Крок 4: Відкрийте сайт на новому сервері

   Створіть посилання-превʼю зі своїм доменом і новим IP. Пройдіться ключовими сторінками, увійдіть у wp-admin і завантажте зображення, щоб перевірити права доступу до файлів.

5. 5

   Крок 5: Запустіть QA-сканування

   Запустіть QA-звіт для превʼю, щоб виявити биті сторінки, відсутні завантаження, цикли редиректів, змішаний вміст і жорстко прописані URL. Виправте й запустіть знову.

6. 6

   Крок 6: Заморозьте вміст і виконайте фінальну синхронізацію

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

7. 7

   Крок 7: Перемкніть DNS

   Спрямуйте A-записи домену і www на новий IP. Оновіть або видаліть старий AAAA-запис, щоб відвідувачі з IPv6 не потрапляли далі на старий хостинг.

8. 8

   Крок 8: Стежте за поширенням і збережіть старий хостинг

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

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

Для ручного копіювання команди виглядають так. Експорт виконуйте на старому сервері, імпорт — на новому:

# Old server: export the database and pack the files
wp db export site.sql
tar -czf site-files.tar.gz --exclude=wp-content/cache .

# New server: unpack, import, check the site URL
tar -xzf site-files.tar.gz
wp db import site.sql
wp option get home
wp option get siteurl

Якщо новий хостинг видав інші облікові дані бази даних, оновіть DB_NAME, DB_USER, DB_PASSWORD і DB_HOST у wp-config.php перед перевіркою.

WordPress зберігає власну адресу в базі даних (home і siteurl) і будує з неї більшість посилань. Поширена помилка — змінити їх на IP сервера чи тимчасове імʼя хоста, щоб перевірити новий сервер. Це працює до перемикання, а потім кожне жорстко прописане посилання вказує на тимчасову адресу.

Залиште обидва значення на робочому домені, наприклад https://example.com, і перевіряйте сайт під цим імʼям. Посилання-превʼю DNSPeek робить саме це: воно підключається до нового IP і запитує ваш справжній домен, тож WordPress поводиться так, ніби DNS уже перемкнуто. Посилання, редиректи й cookie входу переписуються на адресу превʼю, тому ви можете увійти в wp-admin і пройтися сайтом. Докладніше в документації: Превʼю сайту на WordPress на новому хостингу.

Багато хостингів випускають безкоштовний сертифікат лише після того, як домен спрямовано на них, бо перевірка домену відбувається через HTTP на самому домені. До перемикання новий сервер може показувати самопідписаний або стандартний сертифікат. Це нормально й не привід відкладати перенесення.

У превʼю DNSPeek, поки сертифіката немає, встановіть для посилання режим SSL Пропускати перевірку. Інакше плагін чи правило примусового HTTPS може зациклити редирект, коли превʼю переходить на HTTP. Після перемикання перевірте справжній сертифікат за допомогою перевірки SSL. Подробиці: Режими SSL.

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

Платіжні шлюзи й провайдери входу знають лише ваш справжній домен, тому повертають клієнтів на той сервер, на який вказує публічний DNS. Перевірте оформлення замовлення з тестовим шлюзом на превʼю, а одразу після перемикання оформіть одне справжнє або тестове (sandbox) замовлення. Див. чого не вміють превʼю.