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

Что подготовить до переноса

Сначала определите границы переезда. При смене только хостинга домен и адреса страниц остаются прежними. Обычно достаточно скопировать файлы и базу, изменить подключение к новой базе и направить домен на новый сервер. При смене домена меняются также постоянные ссылки, настройки сайта и записи, в которых хранится прежний URL. Для интернет-магазина, форума или сайта с активными заявками потребуется отдельное окно переключения: данные продолжают поступать даже во время копирования.

Запишите, где сейчас размещены сайт, домен, зона DNS, электронная почта и внешние сервисы. Это могут быть разные компании. Перенос веб-сайта сам по себе не требует переноса регистрации домена или почтового сервера.

• Получите доступ к панели старого и нового хостинга, файлам по SFTP (защищённой передаче файлов) или SSH (защищённой командной оболочке), базе MySQL/MariaDB и управлению DNS (системой доменных имён).
• Проверьте версию PHP, нужные расширения, лимиты загрузки и выполнения, поддержку MySQL/MariaDB, планировщика заданий и доступный объём диска. Уточните требования темы и плагинов.
• Узнайте текущие DNS-записи A, AAAA, CNAME, MX, TXT и NS. Зафиксируйте адреса для www и корня домена, настройки SPF, DKIM и DMARC для почты.
• Оцените размер wp-content/uploads, базы, каталога кэша и резервных копий; проверьте свободное пространство на новом тарифе и ограничения импорта.

Пример стартовой конфигурации для небольшого сайта без тяжёлого магазина: 2 виртуальных процессорных ядра, 2–4 ГБ оперативной памяти, SSD, актуальная совместимая версия PHP, веб-сервер и MySQL/MariaDB. Это ориентир для обсуждения с провайдером, а не универсальный минимум. Статический блог, WooCommerce и высоконагруженный проект потребуют разных ресурсов.

Сделайте две независимые копии

Сохраните отдельно архив файлов и SQL-дамп базы. Не ограничивайтесь встроенным экспортом WordPress: раздел «Инструменты → Экспорт» в первую очередь переносит содержимое, но не гарантирует перенос всех настроек плагинов, файлов темы и медиа. Автоматический бэкап хостинга полезен, однако отдельная копия вне обоих серверов лучше защищает от ошибок доступа или удаления аккаунта.

В архив файлов включите wp-content, wp-admin, wp-includes, файлы корня, wp-config.php и скрытые файлы вроде .htaccess. Проверьте, не размещены ли медиа, конфиги или загрузки вне стандартной директории. Отдельно сохраните правила веб-сервера, конфигурацию cron, перенаправления, SSL-сертификаты при необходимости, настройки SMTP и интеграций. Храните дампы и ключи доступа в закрытом месте.

Проверьте резервную копию: архив должен открываться, SQL-файл — содержать структуру и данные таблиц, а время создания — соответствовать состоянию перед работами. До любого импорта в существующую базу обязательно сохраните её отдельный дамп.

Подготовьте новый хостинг

Добавьте домен в панели нового провайдера, но пока не меняйте общедоступные DNS-записи. Создайте каталог сайта и пустую базу данных с отдельным пользователем и нужными правами. Запишите имя базы, логин, пароль и хост сервера БД. Если новый хостинг автоматически установил чистый WordPress, не смешивайте его таблицы с переносимыми: сначала удалите тестовую установку штатным способом либо используйте отдельную пустую базу.

Настройте веб-сервер так, чтобы корневой каталог указывал на сайт, PHP обрабатывался корректно, а права на файлы не были чрезмерно широкими. Если переносите сайт с Apache на Nginx, правила из .htaccess напрямую работать не будут: перенесите нужные перенаправления и правила ЧПУ (человеко-понятных URL) в конфигурацию Nginx. Проверьте лимиты PHP, размер запроса, отправку почты и фоновые задания.

Перенесите файлы WordPress

На виртуальном хостинге загрузите архив через файловый менеджер либо передайте файлы с помощью SFTP. Не забудьте включить отображение скрытых файлов. При SSH удобен rsync: он сохраняет структуру каталогов и позволяет повторно передать только изменившиеся файлы. Запускайте его с учётными данными и путями своей инфраструктуры.

rsync -avz /path/to/site/ user@new-server:/var/www/example.com/

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

Проверьте наличие wp-config.php, папок wp-content/themes, wp-content/plugins и wp-content/uploads. Если часть медиа находится в объектном хранилище или на CDN (сети доставки контента), отдельно проверьте пути, ключи доступа и доступность объектов. Перенос только локального каталога не копирует внешнее хранилище.

Экспортируйте и восстановите базу данных

Через phpMyAdmin на старом хостинге выберите правильную базу и выполните экспорт в SQL. Для большого сайта удобнее командная строка; доступность mysqldump или mariadb-dump зависит от окружения. Важно выгрузить таблицы целиком, включая пользовательские таблицы плагинов, и учесть размер дампа.

mysqldump --single-transaction --default-character-set=utf8mb4 -u OLD_USER -p OLD_DB > wordpress.sql

Команда подходит для согласованного снимка транзакционных таблиц InnoDB. Если используются нетранзакционные таблицы или сайт активно записывает данные, организуйте окно обслуживания и проверьте согласованность копии. Пароль лучше вводить по запросу, а не помещать в историю команд.

Импортируйте дамп в новую пустую базу через панель или команду. Для уже используемой базы сначала сделайте отдельную резервную копию и убедитесь, что импорт не перезапишет чужие таблицы. Не заменяйте рабочую базу новым дампом без сохранённой версии и плана восстановления.

mysql -u NEW_USER -p NEW_DB < wordpress.sql

После импорта сравните количество и префиксы основных таблиц. Стандартный префикс wp_ может отличаться. Проверьте кодировку, ошибки импорта, объём данных и наличие актуальных записей. При разрыве соединения, лимите размера файла или несовместимости версии используйте другой способ импорта либо попросите провайдера увеличить доступные лимиты.

Исправьте wp-config.php

В конфигурации сайта замените параметры DB_NAME, DB_USER, DB_PASSWORD и DB_HOST на данные новой базы. Проверьте $table_prefix — он должен соответствовать импортированным таблицам. Не публикуйте содержимое wp-config.php и не передавайте пароль в общедоступных обращениях.

define('DB_NAME', 'new_database');
define('DB_USER', 'new_user');
define('DB_PASSWORD', 'YOUR_SECRET');
define('DB_HOST', 'localhost');

Это лишь пример. Адрес базы может быть отдельным именем узла, а не localhost. При нестандартной структуре также проверьте переопределения путей, WP_HOME, WP_SITEURL, настройки Redis, отправки почты и среды исполнения.

Проверьте сайт до смены DNS

Лучший способ тестирования при сохранении домена — направить только свой компьютер на IP нового сервера с помощью локального файла hosts. Тогда браузер отправит запрос с обычным именем домена на новый хостинг, а остальные посетители останутся на старом. Для проверки www добавьте отдельную строку.

203.0.113.10 example.com
203.0.113.10 www.example.com

IP-адрес из примера предназначен только для документации. На Windows файл находится по пути C:\Windows\System32\drivers\etc\hosts; для изменения нужны права администратора. На macOS и Linux обычно используют /etc/hosts. После тестирования удалите временные строки и очистите кэш DNS при необходимости.

При такой проверке нужен правильно настроенный виртуальный хост, а HTTPS должен работать для исходного домена. Самоподписанный или отсутствующий сертификат вызовет предупреждение. Для предварительного выпуска сертификата иногда подходит проверка владения доменом через DNS-01, а обычная HTTP-01 требует доступности проверочного файла на веб-сервере через порт 80. Некоторые хостинги предлагают своё предварительное тестирование — уточните, как оно обращается с URL и авторизацией.

• Откройте главную, несколько внутренних страниц, категории, поиск, изображения, PDF, CSS и JavaScript. Проверьте URL с www и без него, HTTP → HTTPS, правила переадресаций и страницу 404.
• Войдите в /wp-admin, сохраните тестовую черновую запись, загрузите изображение и проверьте постоянные ссылки в «Настройки → Постоянные ссылки».
• Проверьте формы, уведомления, платежные шлюзы в безопасном тестовом режиме, личный кабинет, корзину, поиск по сайту, вебхуки и сторонние API.
• Посмотрите журнал ошибок PHP и веб-сервера, задания cron, очереди, настройки кэширования и ограничения прав доступа.

Не отправляйте реальные заказы и платежи на тестовый экземпляр: это может создать дубли. Временную копию закройте от посторонних средствами авторизации или сетевых ограничений. Не оставляйте в ней публично доступные дампы SQL и архивы.

Если домен меняется: обновите URL безопасно

При переносе с example.com на example.net нужно изменить адрес сайта в WordPress и ссылки в сохранённых данных. В «Настройки → Общие» есть «Адрес WordPress (URL)» и «Адрес сайта (URL)». Обычно они совпадают, но WordPress может находиться в отдельном каталоге. Менять эти значения на рабочем старом сайте до готовности новой копии необязательно и рискованно: можно нарушить доступ к административной панели.

В базе встречаются сериализованные значения PHP: вместе со строкой хранится её длина. Простая SQL-команда REPLACE способна повредить такие поля. Используйте инструмент, который понимает сериализацию, например WP-CLI. Сначала запустите пробный проход, затем замену на новой копии после резервирования базы.

wp search-replace 'https://example.com' 'https://example.net' --all-tables-with-prefix --skip-columns=guid --dry-run
wp search-replace 'https://example.com' 'https://example.net' --all-tables-with-prefix --skip-columns=guid

Флаг --dry-run показывает потенциальные изменения, не записывая их. --skip-columns=guid оставляет идентификаторы материалов без массового изменения. Проверьте особенности плагинов и таблиц вне префикса: они могут требовать собственной миграции. При необходимости обработайте также варианты http, www и адреса старых каталогов; не заменяйте слишком короткие фрагменты вроде одного имени бренда.

После смены домена настройте постоянные перенаправления 301 со старых страниц на соответствующие новые, обновите канонические адреса, карту сайта, настройки аналитики и поисковых сервисов. Старый домен желательно сохранить доступным на период перехода. Для сети WordPress Multisite смена домена сложнее: нужны дополнительные проверки сетевых таблиц, сопоставлений доменов и путей; универсальную замену применять без отдельного плана нельзя.

Подготовьте HTTPS, DNS и почту

Сертификат и редиректы

Для нового сервера выпустите или установите TLS-сертификат на нужные имена — example.com и www.example.com, если используются оба. Проверьте автопродление. После запуска настройте единый вариант URL и перенаправление с HTTP на HTTPS без циклов. Если перед сайтом расположен прокси или CDN, проверьте режим шифрования между ним и исходным сервером.

Переключение записей DNS

DNS определяет, куда направляются запросы к домену. Если авторитетные DNS-серверы остаются прежними, часто достаточно изменить A-запись на IPv4 нового сервера и AAAA-запись при использовании IPv6; для www проверьте CNAME или собственные A/AAAA. Если меняете NS (делегирование зоны), предварительно перенесите все нужные записи в новую зону. Не меняйте NS только потому, что меняется хостинг.

За день или раньше уменьшите TTL (время кэширования DNS-записи), если панель разрешает. Это сокращает время хранения старого ответа у части резолверов, но не гарантирует мгновенного переключения: прежний TTL уже мог быть закэширован. При смене NS распространение изменений и кэши делегирования могут вести себя иначе. Проверьте также DNSSEC: записи DS у регистратора должны соответствовать новому провайдеру DNS либо быть корректно изменены при переезде.

Что произойдёт с электронной почтой

Если почта обслуживается отдельно — например, внешним почтовым провайдером, — сохраните MX-записи и связанные TXT/CNAME: SPF, DKIM, DMARC, подтверждения владения доменом. Если ящики и почтовый сервер находятся на старом хостинге, заранее перенесите сами письма, пользователей, пароли или настройки доступа и согласуйте смену MX. Изменение веб-A-записи само по себе не переносит почтовые ящики.

Отдельно проверьте отправку писем из WordPress: SMTP-плагин, ключи транзакционного сервиса, SPF/DKIM и письма с форм. Успешная отправка формы на экране ещё не означает, что сообщение доставлено адресату.

Переключите рабочий сайт без потери новых данных

Критическая часть миграции — записи, возникшие после первого копирования. Пока часть посетителей попадает на старый сервер, а другая часть на новый, заказы, комментарии и заявки могут оказаться в двух базах. Простая повторная заливка дампа поверх уже работающей новой базы затрёт поступившие туда данные.

Для сайта с изменяемым содержимым назначьте короткое окно обслуживания: остановите публикации и оформление заказов, сохраните финальный дамп старой базы, убедитесь, что на новой ещё нет полезных записей, затем синхронизируйте данные и переключите DNS. Если отключить запись нельзя, нужна согласованная стратегия репликации или сверки данных на уровне приложения; миграционный плагин сам по себе не обеспечивает бесшовное слияние заказов.

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

Проверьте запуск и подготовьте откат

С разных сетей проверьте, что домен разрешается в ожидаемый адрес, а на новом сервере работают и главная, и внутренние страницы. Посмотрите серверные журналы, 404/500, ошибки подключения к базе, производительность, дисковое место и SSL. Протестируйте формы и почту реальными тестовыми адресами, а заказы — в предусмотренном платёжной системой режиме без списания денег. Убедитесь, что бэкапы нового хостинга включены и действительно восстанавливаются.

Для диагностики DNS подойдут команды ниже. Если перед сервером работает CDN или прокси, публичный IP может относиться именно к ним — оценивайте результат с учётом своей схемы.

nslookup example.com
nslookup -type=MX example.com

План отката подготовьте до переключения: храните адрес старого сервера, рабочий дамп и архив, снимок новой базы перед возвратом, прежние DNS-записи и время переключения. При серьёзной ошибке верните нужные DNS-записи, восстановите согласованную версию данных и только затем снова разрешите запись. Простой возврат A-записи без анализа новых заказов может привести к их потере. Изменения тоже кэшируются, поэтому откат не всегда мгновенный.

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

Когда лучше использовать плагин миграции

Плагины резервного копирования и миграции могут упаковать файлы и базу, развернуть копию и заменить адреса. Это удобно на типовых сайтах без SSH, но стоит проверить ограничения размера архива, совместимость PHP, условия платных функций, размер свободного места и требования к доступу. Некоторые провайдеры предлагают перенос силами поддержки; заранее уточните, входят ли в него почта, DNS, SSL и финальная синхронизация заказов.

Ручной перенос полезнее, когда требуется контролировать каждую часть инфраструктуры, есть нестандартные каталоги, выделенный сервер или собственный процесс развёртывания. В любом случае тестирование, DNS, доставка почты и план отката остаются отдельными задачами.