Как вручную перенести WordPress: файлы, база данных, DNS

Это руководство пошагово описывает ручной перенос сайта WordPress с одного сервера на другой: копирование файлов, перенос базы данных, замена URL и переключение DNS с простоем, близким к нулю. Оно рассчитано на тех, кто уверенно работает с SSH и командной строкой. Плагин миграции не нужен, а в конце мы разберём, когда плагин всё же является разумным выбором.

Что на самом деле нужно переносить

Сайт WordPress состоит из трёх частей: каталога wp-content (темы, плагины, загрузки), базы данных MySQL или MariaDB и нескольких настроек в wp-config.php. Само ядро WordPress заменяемо: ту же версию можно скачать заново на целевом сервере. Прежде чем что-либо трогать, убедитесь, что на целевом сервере установлена та же или более новая версия PHP, есть нужные плагинам расширения (чаще всего: mysqli, gd или imagick, curl, zip) и достаточно места на диске для каталога загрузок.

Шаг 1: скопируйте файлы

Используйте rsync по SSH. Он сохраняет метки времени, показывает прогресс и позволяет позже запустить его повторно, докопировав только изменившиеся файлы:

rsync -avz --exclude 'wp-content/cache' old-server:/var/www/example.com/ /var/www/example.com/

Каталоги кеша исключайте: они всё равно создаются заново и часто содержат жёстко прописанные пути. Если старый хостинг даёт только FTP, скачайте один tar-архив, а не тысячи отдельных файлов:

tar czf site.tar.gz -C /var/www/example.com .

Шаг 2: выгрузите и импортируйте базу данных

На старом сервере:

mysqldump --single-transaction --default-character-set=utf8mb4 -u dbuser -p dbname > site.sql

--single-transaction даёт согласованный снимок без блокировки работающего сайта. Скопируйте файл и импортируйте его на новом сервере:

mysql -u dbuser -p newdbname < site.sql

Если имя базы или пользователь на новом сервере меняются, сначала создайте их и выдайте права. С обеих сторон сохраняйте кодировку utf8mb4: незаметный откат на utf8 обрезает эмодзи и любые другие 4-байтовые символы.

Шаг 3: замените URL безопасным способом

Если домен остаётся прежним, пропустите этот шаг. Если он меняется, никогда не запускайте простой SQL UPDATE ... REPLACE() по всем таблицам. WordPress хранит настройки виджетов, опции тем и данные плагинов в виде сериализованных массивов PHP, а в них записаны длины строк. Слепая замена меняет строки, но не длины, и данные тихо перестают десериализоваться: пропадают виджеты, сбрасываются настройки темы.

Правильный инструмент здесь wp-cli, он умеет работать с сериализованными данными:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

Сначала выполните прогон с --dry-run и просмотрите отчёт по таблицам. Если wp-cli недоступен, используйте безопасный для сериализации скрипт, например Search Replace DB, и удалите его с сервера сразу после завершения, иначе это общедоступная дыра.

Шаг 4: отредактируйте wp-config.php

Обновите блок базы данных под новый сервер:

define( 'DB_NAME', 'newdbname' );
define( 'DB_USER', 'newdbuser' );
define( 'DB_PASSWORD', 'newpassword' );
define( 'DB_HOST', 'localhost' );

Проверьте ещё три вещи. Во-первых, $table_prefix должен совпадать с тем, что реально лежит в дампе. Во-вторых, сохраните существующие ключи аутентификации и соли: их смена разлогинит всех пользователей. В-третьих, если в старой конфигурации были определены WP_HOME и WP_SITEURL, обновите их на новый домен, потому что они имеют приоритет над значениями в базе.

Шаг 5: протестируйте через файл hosts, затем переключите DNS

Минимум за сутки до переноса снизьте TTL A-записи до 300 секунд, чтобы после переключения старое значение быстро истекло. Пока DNS ещё указывает на старый сервер, протестируйте новый, заставив свой компьютер резолвить домен туда. Добавьте строку в /etc/hosts (в Windows: C:\Windows\System32\drivers\etc\hosts):

203.0.113.10 example.com www.example.com

Теперь ваш браузер обращается к новому серверу, а все остальные по-прежнему видят старый. Проверьте главную страницу, вход в wp-admin, постоянные ссылки на нескольких внутренних страницах, загрузку изображений и любую форму или оформление заказа. Когда всё работает, обновите записи A и AAAA, удалите строку из hosts и оставьте старый сервер работать ещё минимум 48 часов: некоторые резолверы игнорируют TTL, и перед выключением стоит дождаться, пока журнал доступа старого сервера затихнет.

Типичные точки отказа и когда достаточно плагина

Смешанный контент, постоянные ссылки, права на файлы

• Смешанный контент. Если при переносе сайт перешёл с http на https, жёстко прописанные в контенте и опциях URL вида http:// продолжают грузиться по обычному http, и браузер их блокирует. Лечится ещё одним search-replace с http://example.com на https://example.com.
• Постоянные ссылки отдают 404. Главная работает, а каждая внутренняя страница выдаёт 404. Это отсутствующая конфигурация перезаписи: на Apache не скопирован файл .htaccess или выключен mod_rewrite; на nginx в блоке сервера нет try_files $uri $uri/ /index.php?$args;. Пересохранение настроек постоянных ссылок в wp-admin создаёт .htaccess заново.
• Права на файлы. Если не работают загрузки или плагины не обновляются, файлы после копирования скорее всего принадлежат не тому пользователю. Назначьте владельцем пользователя PHP-процесса и выставьте права 755 на каталоги, 644 на файлы:

  chown -R www-data:www-data /var/www/example.com
  find /var/www/example.com -type d -exec chmod 755 {} +
  find /var/www/example.com -type f -exec chmod 644 {} +

Плагин миграции или вручную: что и когда

Duplicator, All-in-One WP Migration и похожие плагины подходят для небольшого сайта: максимум гигабайт или два, один редактор и готовность повторить весь экспорт, если что-то сорвётся. Они упаковывают всё в один архив и сами выполняют замену URL.

Ручной перенос надёжнее, когда каталог загрузок большой (упаковка плагином умирает на лимитах памяти и времени выполнения PHP), когда сайт нагружен и прямо перед переключением DNS нужен финальный инкрементальный rsync и свежий дамп, для установок multisite, и всегда, когда вы хотите точно знать, что именно было перенесено. К тому же ручной путь единственный даёт настоящую репетицию: тест через файл hosts на живой базе данных архивный плагин предложить не может.

Если вы переносите сайт к нам, и WordPress-хостинг, и обычный хостинг сайтов идут с доступом по SSH и wp-cli, поэтому каждая команда из этого руководства работает как написано. Если предпочитаете передать перенос нам, это может сделать поддержка.