Миграция WordPress на новый сервер: Пошаговое руководство без плагинов

Миграция WordPress на новый сервер через rsync и WP-CLI — перенос файлов и замена URL в базе данных

Переезд на новый хостинг или VPS — стресс для любого владельца сайта. Популярные плагины вроде Duplicator или All-in-One WP Migration кажутся удобным решением, но на сайтах тяжелее 2-3 ГБ они почти всегда падают с ошибкой 504 Gateway Timeout или упираются в memory_limit. К тому же, они часто переносят «мусор» из старых конфигураций.

В этом руководстве мы перенесем WordPress на новый сервер вручную, используя стандартные консольные утилиты: rsync для файлов и mysqldump для базы данных. Этот метод работает для сайтов любого размера, не требует увеличения лимитов PHP и занимает минимум времени. Мы также настроим новый стек, опираясь на наши предыдущие гайды по Nginx и PHP-FPM.

Шаг 1: Подготовка старого сервера

Чтобы избежать рассинхронизации данных (когда пользователи пишут комментарии или делают заказы во время переноса), переведем сайт в режим обслуживания.

Установите плагин «WP Maintenance Mode» или добавьте в functions.php вашей темы временный код:

// Временно включаем режим обслуживания
function customcode_maintenance_mode() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Сайт временно недоступен. Ведутся технические работы.' );
    }
}
add_action( 'get_header', 'customcode_maintenance_mode' );

Также убедитесь, что у вас есть свежий бэкап. Мы подробно разбирали создание скриптов для автоматического резервного копирования, но для миграции сделаем дамп прямо сейчас.

Шаг 2: Подготовка нового сервера

На новом сервере должен быть развернут базовый стек LEMP (Linux, Nginx, MySQL, PHP). Если вы еще этого не сделали, используйте наши инструкции:

  • Настройка Nginx reverse proxy с HTTPS
  • Оптимизация PHP-FPM под нагрузку
  • Настройка MySQL/MariaDB (innodb_buffer_pool_size и лимиты соединений)

Создайте пустую базу данных и пользователя на новом сервере:

sudo mysql -u root -p

CREATE DATABASE custom_code_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'custom_code_user'@'localhost' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON custom_code_db.* TO 'custom_code_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Шаг 3: Перенос файлов через rsync

Мы будем использовать rsync — тот же инструмент, который мы применяли для автоматического деплоя через GitHub Actions. Он передает только измененные блоки файлов, что критично для экономии трафика и времени.

Выполните эту команду на старом сервере (или на локальной машине, если у вас есть SSH-доступ к обоим серверам):

rsync -avz --progress \
    --exclude='wp-content/cache' \
    --exclude='wp-content/upgrade' \
    --exclude='wp-content/backups' \
    --exclude='.git' \
    /var/www/wordpress/ deployer@NEW_SERVER_IP:/var/www/wordpress/

Флаги -avz означают: архивный режим (сохраняет права и владельцев), подробный вывод и сжатие при передаче. Если прервете процесс, просто запустите команду снова — rsync докачает только недостающее.

Шаг 4: Перенос базы данных

Создаем дамп на старом сервере и сразу передаем его на новый, не сохраняя промежуточный файл на диск:

mysqldump -u old_db_user -p old_db_name | ssh deployer@NEW_SERVER_IP "mysql -u new_db_user -p new_db_name"

Если база данных очень большая (более 5 ГБ), лучше сжать её и передать архивом, чтобы избежать обрыва SSH-соединения:

# На старом сервере
mysqldump -u old_db_user -p old_db_name | gzip > db_dump.sql.gz

# Передаем архив на новый сервер
scp db_dump.sql.gz deployer@NEW_SERVER_IP:/tmp/

# На новом сервере распаковываем и импортируем
gunzip /tmp/db_dump.sql.gz
mysql -u new_db_user -p new_db_name < /tmp/db_dump.sql

Шаг 5: Обновление wp-config.php и прав доступа

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

define( 'DB_NAME', 'custom_code_db' );
define( 'DB_USER', 'custom_code_user' );
define( 'DB_PASSWORD', 'strong_password' );
define( 'DB_HOST', 'localhost' );

Восстановите правильные права на файлы и папки, как мы делали в статье про ошибку 500 Internal Server Error:

sudo chown -R www-data:www-data /var/www/wordpress
sudo find /var/www/wordpress -type d -exec chmod 755 {} \;
sudo find /var/www/wordpress -type f -exec chmod 644 {} \;

Шаг 6: Замена URL (если меняется домен)

Если вы переезжаете на новый домен, нужно заменить старый URL во всех таблицах базы данных. Используем для этого WP-CLI, который корректно обрабатывает сериализованные данные PHP (в отличие от обычного SQL-запроса).

# Сначала делаем сухой прогон, чтобы увидеть, что будет изменено
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' --dry-run

# Если всё верно, выполняем реальную замену
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru'

# Очищаем кэш WordPress и объектный кэш
wp cache flush

Шаг 7: Тестирование на новом сервере (до смены DNS)

Прежде чем переключать DNS, проверьте, что сайт работает на новом сервере по его IP-адресу. Откройте в браузере http://NEW_SERVER_IP.

Если вы видите сайт, но без стилей (CSS), проблема в том, что браузер блокирует загрузку ресурсов с чужого домена (CORS), либо в базе данных остались жестко прописанные абсолютные пути. Также проверьте файл .htaccess (если используете Apache) или конфиг Nginx на предмет редиректов.

Шаг 8: Переключение DNS и настройка SSL

Если тест прошел успешно, меняем A-запись домена у вашего регистратора, указав IP нового сервера. Обновление DNS может занять от 15 минут до 24 часов.

Как только DNS обновится, выпустите SSL-сертификат Let's Encrypt на новом сервере:

sudo certbot --nginx -d custom-code.ru -d www.custom-code.ru

После этого уберите код режима обслуживания из functions.php (из Шага 1).

Шаг 9: Финальная проверка и очистка

После переезда обязательно проверьте:

  • Работают ли постоянные ссылки (Permalinks). Если нет — сбросьте их: wp rewrite flush
  • Отправляются ли письма (проверьте через плагин WP Mail SMTP или функцию восстановления пароля)
  • Работает ли Redis Object Cache (если вы его используете)
  • Настроены ли cron-задачи для бэкапов на новом сервере

Не забудьте отменить старый хостинг только через 3-5 дней после миграции, чтобы убедиться, что всё работает стабильно и DNS полностью обновился у всех провайдеров.

Что делать, если проблемы не решаются?

Ошибка "Error establishing a database connection" после переноса

Проверьте wp-config.php на новом сервере. Убедитесь, что пароль не содержит специальных символов, которые могут быть некорректно экранированы, или измените пароль пользователя MySQL на более простой (буквы и цифры).

Белый экран смерти (WSOD) на новом сервере

Включите режим отладки в wp-config.php (define( 'WP_DEBUG', true );). Чаще всего проблема кроется в несовместимости версии PHP на новом сервере с вашими плагинами, либо в отсутствии необходимых PHP-расширений (например, php-imagick или php-xml). Установите недостающие модули и перезапустите PHP-FPM.

Сайт работает медленно после переезда

Убедитесь, что вы применили настройки из наших гайдов по оптимизации MySQL и PHP-FPM. Также проверьте, что на новом сервере включено сжатие GZIP/Brotli в Nginx и настроено кэширование статики.

Итог

Миграция WordPress без плагинов — это не сложнее, чем их использование, но гораздо надежнее. Вы полностью контролируете процесс, не зависите от лимитов PHP и получаете чистый перенос без мусорных файлов. Сохраните этот чек-лист, и следующий переезд на более мощный сервер займет у вас не больше часа.

Теги:
WordPress