Ми часто бачимо, як перенесення WordPress перетворюється на головний біль: абсолютні шляхи в БД, серіалізовані дані, різні версії PHP — і в результаті сайт ламається. Правильний порядок дій і професійні інструменти зводять ризик до нуля, а downtime — до хвилин. Нещодавно ми мігрували інтернет-магазин на 5000 товарів — downtime склав лише 2 хвилини, всі дані залишилися цілими. У цій статті ділимося реальним досвідом: як мігрувати WordPress без втрат, використовуючи WP-CLI, і що важливо перевірити до та після переїзду.
Як мігрувати WordPress без даунтайму?
Планування починається за 48 годин: знижуємо TTL запису A до 300 секунд. Це скоротить час очікування DNS-пропагації після перемикання. Для самого перенесення обираємо один із трьох підходів:
| Метод | Складність | Downtime | Обмеження |
|---|---|---|---|
| WP-CLI + rsync | Висока | Мінімальний (1-5 хв) | Вимагає SSH-доступ |
| All-in-One WP Migration | Низька | Залежить від розміру | Безкоштовно до 512 МБ |
| Duplicator | Середня | Залежить від пакету | Немає версійності |
WP-CLI + rsync у 10 разів швидший за плагіни міграції: перенесення файлів у 10 разів швидше, контроль над процесом повний. Для VPS це однозначно переважний варіант — повний контроль, автоматична обробка серіалізованих даних, можливість інкрементального копіювання. На shared-хостингу простіше взяти готовий плагін, але для вологого тесту до перемикання DNS використовуйте /etc/hosts.
Чому серіалізовані дані — проблема?
Ручна заміна http://old-site.com на https://new-site.com через SQL — часта помилка. Серіалізовані рядки зберігають довжину даних, і при заміні довжини змінюються, що ламає масив. wp search-replace вирішує це за вас:
wp search-replace 'http://old-site.com' 'https://new-site.com' --all-tables --report-changed-only # Для staging (не змінювати URL одразу): wp search-replace 'old-site.com' 'new-site.com' --all-tables --skip-columns=guid Цей інструмент перераховує довжини, тому дані залишаються валідними. Детальніше про серіалізовані дані можна прочитати в Wikipedia. Якщо ж ви використовуєте phpMyAdmin або sed — ризикуєте отримати битий сайт і втратити час на відновлення.
Інструменти
WP-CLI + rsync — професійний підхід для VPS. Повний контроль процесу, мінімальний downtime. Плагін All-in-One WP Migration зручний для shared-хостингу, обмеження за розміром файлу в безкоштовній версії (512 MB). Duplicator створює installer-пакет, встановлюється як звичайний сайт.
Міграція через WP-CLI (рекомендується)
- Експорт із джерела:
rsync -avz --exclude='.git' --exclude='node_modules' /var/www/old-host.com/ user@new-server:/var/www/new-host.com/ wp db export --add-drop-table - | gzip > /tmp/wordpress-db.sql.gz scp /tmp/wordpress-db.sql.gz user@new-server:/tmp/ - На новому сервері налаштування оточення:
mysql -u root -e " CREATE DATABASE wordpress_new CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'new-password'; GRANT ALL PRIVILEGES ON wordpress_new.* TO 'wp_user'@'localhost';" gunzip -c /tmp/wordpress-db.sql.gz | mysql -u root wordpress_new - Оновити wp-config.php:
define('DB_NAME', 'wordpress_new'); define('DB_USER', 'wp_user'); define('DB_PASSWORD', 'new-password'); define('DB_HOST', 'localhost'); - Заміна URL в БД:
wp search-replace 'http://old-host.com' 'https://new-host.com' --all-tables --report-changed-onlywp search-replaceкоректно обробляє серіалізовані дані — на відміну від ручного SQLUPDATE. - Тестування на новому сервері (до зміни DNS): додайте в
/etc/hostsна своєму комп'ютері1.2.3.4 new-host.com www.new-host.com. Перевірте: головна сторінка, товари/пости, форми, оплата, авторизація, зображення. - Зміна DNS: після перемикання чекати поширення (зазвичай 1–4 години).
Типові помилки при міграції
| Помилка | Наслідки | Рішення |
|---|---|---|
| Заміна URL через SQL UPDATE | Пошкодження серіалізованих даних | Використовувати wp search-replace |
| Ігнорування версій PHP | Помилки сумісності плагінів | Перевірити сумісність до міграції |
| Неправильні шляхи в wp-config | Сайт не завантажується | Перевірити шляхи та права доступу |
Кейс: міграція магазину на 5000 товарів
Клієнт переносив магазин на WooCommerce з shared-хостингу на VPS. Вихідний сайт працював на PHP 7.4, новий сервер — PHP 8.2. Перед міграцією перевірили сумісність плагінів: старий плагін кешування не підтримував PHP 8.2. Замінили його на сучасний аналог до перенесення. Міграція через WP-CLI зайняла 3 години, downtime — 2 хвилини. Після зміни DNS всі товари, замовлення та зображення на місці.
Що входить в роботу
- Повний бекап вихідного сайту (файли + БД)
- Перенесення на новий сервер з налаштуванням оточення (PHP, MySQL, Nginx)
- Заміна URL в БД через wp search-replace
- Налаштування SSL-сертифіката (Certbot) — гарантія безпеки
- Тестування всіх критичних сторінок та функціоналу
- Інструкція зі зміни DNS
- Годинна підтримка після міграції
За 5+ років досвіду та 50+ успішних міграцій ми гарантуємо цілісність даних. Економія на хостингу після оптимізації може скласти до 30%. Звертайтеся — оцінимо проект за один день.
Різні версії PHP
Якщо старий хостинг — PHP 7.4, новий — PHP 8.2: перевірити сумісність усіх плагінів і тем. Більшість сучасних плагінів підтримують PHP 8.x, але деякі старі — ні. Перевірте логи PHP на новому сервері (наприклад, tail -f /var/log/php/error.log).
SSL на новому сервері
Після міграції випустіть сертифікат через Certbot. Переконайтеся, що FORCE_SSL_ADMIN у wp-config.php встановлено.
Строки
Міграція WordPress-сайту до 5 ГБ з тестуванням і перемиканням DNS — 3–5 годин. Великий сайт з додатковими інтеграціями — 6–8 годин. Точна оцінка — після ознайомлення з проектом. Отримайте консультацію з міграції прямо зараз — це безкоштовно та займе не більше 15 хвилин.