Перенос WordPress на другой хостинг: четыре пути и их цена

Задача: магазин на WordPress 6.x с WooCommerce живёт на дешёвом shared-хостинге, корзина отдаётся медленно, нужно уйти на VPS. Очевидное решение — плагин миграции «в один клик» — именно на таком сайте и ломается: сборка архива падает по max_execution_time, а если архив всё-таки доехал, на новом месте пустеют настройки темы и виджеты. Ниже — четыре рабочих пути, чем каждый платит, и разбор одного из них по шагам.

Исходные данные примера

Возьмём характерный случай, с такими вводными работать приходится чаще всего:

• WordPress 6.x (в примере 6.8), WooCommerce, около 30 активных плагинов;
• wp-content/uploads — порядка 14 ГБ, база — около 1,2 ГБ, причём половина объёма приходится на wp_options с транзиентами и постмета заказов;
• старый хостинг: PHP 8.1, MySQL, доступ только по SFTP и phpMyAdmin;
• новый: VPS с PHP 8.3, Nginx, SSH и установленным WP-CLI 2.x;
• домен остаётся тем же — это важно, к этому вернёмся.

До начала стоит проверить три вещи: лимит на импорт дампа в панели нового хостинга, версию PHP, под которую собраны ваши плагины, и наличие object-cache.php или advanced-cache.php в wp-content — это дроп-ины от кеширующих плагинов, которые на новом сервере будут ссылаться в пустоту.

Четыре способа и чем каждый платит

Плагин миграции

All-in-One WP Migration, Duplicator, Migrate Guru и аналоги собирают файлы и базу в один архив, который разворачивается на новом месте. Выигрыш: не нужен ни SSH, ни понимание, что такое дамп. Плата: всё делается силами PHP под веб-сервером, то есть упирается в max_execution_time, memory_limit и лимит на размер загружаемого файла. У бесплатных версий есть ограничение на размер импортируемого архива — актуальное значение смотрите на странице конкретного плагина, оно меняется от версии к версии. На 15 ГБ такой путь превращается в лотерею.

Руками: SFTP плюс phpMyAdmin

Качаете файлы, экспортируете базу через phpMyAdmin, загружаете обратно. Полный контроль, работает на любом хостинге. Плата — время и два классических грабель: FTP-клиент по умолчанию не показывает скрытые файлы, и .htaccess остаётся на старом сервере; а импорт дампа через веб-интерфейс ограничен upload_max_filesize и живёт ровно до таймаута запроса. База на гигабайт здесь уже проблема.

WP-CLI и rsync

Дамп делается консольной утилитой, файлы синхронизируются по SSH, замена URL — через wp search-replace, который умеет работать с сериализованными данными. Это самый быстрый и предсказуемый вариант, плюс его можно прогнать повторно: rsync догонит только изменившееся. Плата: нужен SSH хотя бы на одной стороне, лучше на обеих, и готовность работать в терминале.

Перенос силами нового хостинга

Многие провайдеры переносят сайт бесплатно: вы даёте доступы, они всё делают. Выигрыш очевиден. Плата — вы не управляете ни временем, ни порядком действий, и расхождение данных между старым и новым сайтом становится чужой зоной ответственности. Для магазина, который принимает заказы круглосуточно, это главный риск.

Сравнение

Когда что выбирать

Критерий простой — объём базы и наличие SSH, а не красота решения:

1. Сайт-визитка или блог до пары гигабайт, SSH нет — плагин миграции. Это дешевле всего по вашему времени.
2. SSH нет, но база больше лимита импорта — руками, с разбиением дампа по таблицам через phpMyAdmin или загрузкой дампа по SFTP и импортом из панели, если провайдер это умеет.
3. Магазин, большой медиаархив, база от полугигабайта, SSH есть — WP-CLI и rsync. Других вариантов, которые закончатся в обозримый срок, здесь по сути нет.
4. Переезд не срочный, и вы готовы отдать контроль — миграция силами хостера.

Перенос ломается не на копировании файлов. Он ломается на том, о чём забыли: кеш-дроп-ины, системный cron, отправка писем, TTL у DNS и заказы, которые в момент переключения уходят на старый сервер.

Разбор: тот же сайт по третьему пути

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

# WP-CLI 2.x
wp core version                  # фиксируем версию ядра
wp db size --tables              # видно, какие таблицы раздуты
wp plugin list --status=active --field=name   # находим кеширующие плагины

# кеширующие плагины выключаем до дампа, иначе их дроп-ины уедут вместе с базой
wp plugin deactivate 

# дамп в utf8mb4, без блокировки таблиц на запись
wp db export ../dump.sql --single-transaction --default-character-set=utf8mb4

Файлы — на новый сервер. Кеш и временные каталоги не нужны, их содержимое только замедлит синхронизацию:

rsync -az --delete \
  --exclude 'wp-content/cache/' \
  --exclude 'wp-content/upgrade/' \
  -e ssh ./ user@new-host:/var/www/site/

На новом сервере правим подключение к базе и разворачиваем дамп. wp config set пишет константы прямо в wp-config.php, руками открывать файл не нужно:

cd /var/www/site
wp config set DB_NAME new_db_name
wp config set DB_USER new_db_user
wp config set DB_PASSWORD 'YOUR_DB_PASSWORD'
wp config set DB_HOST localhost

wp db import ../dump.sql
wp core verify-checksums          # проверяем, что ядро доехало без потерь
wp db check

Ключевая деталь, которую часто делают зря: если домен не меняется, search-replace не нужен вообще. Прогонять его стоит только при смене домена или когда вы тестируете сайт на техническом поддомене. И только с предварительным прогоном:

# сначала всегда --dry-run, он показывает число замен по таблицам
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' \
  --all-tables-with-prefix --skip-columns=guid --dry-run

--skip-columns=guid нужен потому, что guid записей — идентификатор для фидов, а не адрес, и менять его не надо. Полный список флагов команды есть в документации WP-CLI. После импорта — wp cache flush и wp rewrite flush --hard.

Проверять результат до переключения DNS удобнее через файл hosts на своей машине: прописываете туда IP нового сервера и тот же домен. Тогда сайт открывается с нового хостинга под рабочим доменом, без технических поддоменов и без замены URL в базе.

Что ломается чаще всего

• Error establishing a database connection. Почти всегда — DB_HOST: у части провайдеров это не localhost, а отдельный хост или сокет. Второй вариант — пользователь БД создан, но не привязан к базе.
• Белый экран или 500 после импорта. Смотрите error_log сервера или включите WP_DEBUG_LOG. Типичная причина — старый плагин под PHP 8.3 валится с Fatal error: Uncaught Error. Лечится обновлением плагина или откатом минорной версии PHP на новом сервере.
• Кракозябры в текстах. Дамп снят в одной кодировке, база создана в другой. Поэтому в экспорте явно указывается --default-character-set=utf8mb4, а новая база создаётся с той же кодировкой и collation, что DB_CHARSET и DB_COLLATE в wp-config.php.
• Пустые настройки темы, слетевшие виджеты и слайдеры. Это след ручного REPLACE по дампу или поиска-замены в текстовом редакторе: ломается сериализация. Откатывайтесь на исходный дамп и используйте wp search-replace.
• 404 на всех внутренних страницах, главная работает. На Apache — не доехал .htaccess (скрытые файлы в FTP-клиенте). На Nginx правил из .htaccess нет в принципе, нужен try_files в конфиге сайта.
• Сайт работает, письма не уходят. Новый сервер не настроен на отправку или у домена нет SPF и DKIM под него. На магазине это тихая поломка: заказы приходят, уведомления нет.
• Задачи перестали выполняться. Если на старом хостинге был системный cron с вызовом wp-cron.php, он не переезжает вместе с файлами. Проверьте запланированные события и настройте cron заново.

Отдельная история — окно переключения DNS. Снизьте TTL записи заранее, за сутки, переведите магазин в режим каталога или обслуживания, сделайте финальный дамп и догоняющий rsync по uploads, и только потом меняйте запись. Пока кеши резолверов обновляются, часть посетителей ещё видит старый сервер — если он остаётся включённым и способен принимать заказы, вы получите два расходящихся набора данных. Сертификат HTTPS на новом сервере стоит выпустить до переключения, иначе первые посетители увидят предупреждение браузера.

Что делать дальше

Первое после переезда — бэкап на новом месте и пробное восстановление: бэкап, который никто не разворачивал, бэкапом не считается. Дальше: включите обратно кеширование и object cache под конфигурацию нового сервера, проверьте OPcache, замерьте TTFB на тех же страницах, что и до переноса, и неделю держите старый хостинг оплаченным вместе с дампом базы. Если домен менялся, настройте 301 со старого адреса и отправьте новый sitemap в панель для веб-мастеров. Оптимизация раздутой wp_options и чистка транзиентов — отдельная тема, в переносе её лучше не трогать.

Сериализованные данные — способ, которым WordPress хранит массивы и объекты в одном текстовом поле базы (настройки темы, виджеты, метаданные). В такой строке перед каждым значением записана его длина. Если заменить текст обычным SQL REPLACE, длина перестанет совпадать с содержимым, и WordPress просто не сможет прочитать значение — отсюда пустые настройки после «успешного» переноса.