Мы часто видим, как перенос 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 раз быстрее, контроль над процессом полный. Для 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-only wp search-replace корректно обрабатывает сериализованные данные — в отличие от ручного SQL UPDATE.
Тестирование на новом сервере (до смены 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+ успешных миграций WordPress. Экономия на хостинге после оптимизации может быть существенной. Обращайтесь — оценим проект за один день.
Разные версии 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 GB с тестированием и переключением DNS — 3–5 часов. Крупный сайт с дополнительными интеграциями — 6–8 часов. Точная оценка — после ознакомления с проектом. Получите консультацию по миграции прямо сейчас — это бесплатно и займёт не более 15 минут.