Перенос WordPress на другой хостинг часто выглядит простой задачей: скачать файлы, экспортировать базу и загрузить всё на новый сервер. На практике проблемы обычно появляются позже — сайт открывается не по тому адресу, часть изображений ведёт на старый домен, формы перестают отправляться, cron не запускается, а SSL или редиректы начинают конфликтовать.
Этот материал полезен владельцам WordPress-сайтов и разработчикам, которым нужно перенести проект на новый shared-хостинг, VPS или другой сервер без потери контента и с контролируемым переключением. Ниже — порядок миграции, который позволяет заранее проверить новое окружение и не превращать смену хостинга в аварийные работы.
Если нужен технический перенос под ключ с проверкой темы, плагинов, базы, DNS и форм, это относится к задачам доработки WordPress и сопровождения сайта после миграции.
Архитектура безопасного переноса WordPress
- Исходный сайтФиксируем текущее состояние, версии PHP, WordPress, тему, плагины и важные интеграции.
- Резервная копияСохраняем файлы и отдельный экспорт базы данных до любых изменений.
- Новый серверГотовим PHP, базу, веб-сервер, SSL и конфигурацию WordPress.
- ТестированиеПроверяем сайт на новом окружении до переключения основного DNS.
- ПереключениеМеняем DNS и повторно проверяем сайт, формы, cron, почту и интеграции.
Главный принцип: DNS переключается в самом конце, когда новая копия уже работает и прошла техническую проверку.
Что именно нужно перенести
WordPress состоит не только из каталога wp-content. Для полноценной миграции важно учитывать несколько частей системы.
| Компонент | Что переносим | Что проверить |
|---|---|---|
| Файлы | WordPress, тема, плагины, uploads, дополнительные серверные файлы | Права доступа, владельца файлов, скрытые файлы |
| База данных | Таблицы WordPress и данные плагинов | Кодировка, префикс таблиц, корректный импорт |
| wp-config.php | Настройки подключения и проектные константы | DB_HOST, DB_NAME, DB_USER, salts, environment-specific параметры |
| Веб-сервер | Правила rewrite и серверные ограничения | .htaccess для Apache или конфигурацию Nginx |
| Внешняя инфраструктура | DNS, SSL, SMTP, cron, webhook и API endpoint | Что привязано к старому IP, hostname или пути |
Почему копирования файлов недостаточно
Большая часть содержимого WordPress хранится в базе данных. Там находятся записи, настройки, меню, виджеты, данные WooCommerce и значения многих плагинов. Поэтому перенос только каталога сайта не создаёт рабочую копию.
Отдельная сложность — абсолютные URL и сериализованные данные. Обычная SQL-замена строк может повредить сериализованные значения. В документации WordPress для миграции отдельно упоминается WP-CLI, а команда wp search-replace умеет обрабатывать сериализованные данные и поддерживает режим --dry-run.
Шаг 1. Зафиксируйте исходное состояние
Перед переносом полезно записать то, что придётся сравнить после миграции:
- версию WordPress и PHP;
- активную тему и список критичных плагинов;
- используемый домен и схему HTTPS;
- отправку почты;
- расписание cron-задач;
- webhook и API-интеграции;
- формы обратной связи и оплату, если они есть.
Это превращает финальную проверку в конкретный список, а не в случайное кликанье по страницам.
Шаг 2. Сделайте резервную копию файлов и базы
Официальное руководство WordPress рекомендует сохранять и базу, и файлы перед техническими изменениями. Для миграции это особенно важно: исходный сайт остаётся точкой возврата, пока новая версия не проверена.
Если доступен WP-CLI, экспорт базы можно сделать отдельной командой:
wp db export backup-before-migration.sqlКоманда wp db export использует параметры базы из wp-config.php и создаёт SQL-дамп. Хранить такой файл лучше вне публичного web-root, чтобы он не был доступен по URL.
Шаг 3. Подготовьте новое окружение до копирования сайта
На новом сервере сначала создаётся база, пользователь базы, каталог сайта и подходящая версия PHP. Если проект использует специфические PHP-расширения, ImageMagick, Redis, cron или нестандартные лимиты, их лучше подготовить до переноса.
Для обычного сайта важно сверить как минимум:
- PHP и необходимые расширения;
- лимиты памяти и загрузки файлов;
- режим работы PHP-FPM, если используется;
- rewrite для постоянных ссылок;
- возможность выпускать SSL для домена;
- исходящую почту или подключение SMTP.
Шаг 4. Перенесите файлы и импортируйте базу
Файлы WordPress можно перенести средствами панели, SFTP/SSH или архивом. Базу удобнее импортировать отдельно, чтобы ошибка импорта не смешивалась с проблемами файловой системы.
При доступном WP-CLI импорт выглядит так:
wp db import backup-before-migration.sqlКоманда импортирует SQL в базу, указанную в wp-config.php. Она не создаёт базу автоматически, поэтому база и доступы должны быть подготовлены заранее.
Шаг 5. Настройте wp-config.php для нового сервера
На этом этапе чаще всего меняются параметры подключения к базе. Не стоит переносить server-specific настройки вслепую: пути к кешу, Redis, SMTP, environment variables и дополнительные константы могут отличаться.
Если в проекте используются секреты, их не следует публиковать в репозитории или вставлять в статью. На сервере такие значения лучше держать в конфигурации окружения или защищённом wp-config.php.
Шаг 6. Если меняется домен — выполните безопасный search-replace
Когда домен остаётся тем же, глобальная замена URL обычно не нужна. Если меняется адрес сайта, используйте инструмент, который понимает структуру WordPress.
Сначала полезно выполнить пробный проход:
wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run --skip-columns=guidПосле проверки результата можно повторить команду без --dry-run. WP-CLI отдельно документирует работу с сериализованными данными, поэтому такой способ безопаснее простого текстового replace в SQL-файле.
Шаг 7. Проверьте новую копию до смены DNS
Идеальный момент для обнаружения ошибок — до того, как посетители попадут на новый сервер. В зависимости от инфраструктуры сайт можно проверять через временный hostname, hosts-файл или отдельный технический домен.
Проверьте:
- главную и несколько внутренних страниц;
- вход в wp-admin;
- изображения и файлы;
- постоянные ссылки;
- формы;
- AJAX и REST endpoint;
- корзину и checkout, если используется WooCommerce;
- ошибки PHP и JavaScript.
Шаг 8. Переключите DNS и выпустите SSL
Только после проверки новой копии имеет смысл направлять основной домен на новый сервер. Время распространения DNS зависит от настроек зоны и кеширования, поэтому некоторое время запросы могут попадать и на старую, и на новую площадку.
Если сайт принимает новые заказы, комментарии или заявки непосредственно в WordPress, этот переходный период нужно учитывать. Для динамического проекта иногда полезно на короткое время ограничить изменения или выполнить финальную синхронизацию базы перед переключением.
Шаг 9. После DNS проверьте не только страницы
Факт открытия главной страницы ещё не означает, что перенос завершён. После переключения нужно протестировать то, что работает в фоне или зависит от домена:
- SSL и редирект HTTP → HTTPS;
- формы и SMTP;
- WP-Cron или системный cron;
- webhook;
- REST API;
- кеширование;
- генерацию изображений;
- платёжные и CRM-интеграции;
- резервное копирование уже на новом сервере.
Для сложного проекта такую проверку лучше включать в работу WordPress-разработчика, а не считать перенос завершённым сразу после смены IP.
Типовые ошибки при миграции WordPress
| Ошибка | Что происходит | Как избежать |
|---|---|---|
| Переносят только файлы | Нет настроек и контента из базы | Всегда переносить файлы и базу как единый проект |
| Меняют URL обычным SQL replace | Можно повредить сериализованные данные | Использовать WP-CLI search-replace с dry-run |
| DNS меняют слишком рано | Ошибки обнаруживаются уже на боевом трафике | Сначала проверить новый сервер |
| Забывают cron и webhook | Фоновые задачи молча перестают работать | Составить список внешних интеграций заранее |
| Удаляют старый сервер сразу | Нет быстрого варианта отката | Сохранять старую копию до завершения проверки |
Когда такой перенос подходит
Перенос на другой хостинг или VPS имеет смысл, когда текущая площадка ограничивает нужную версию PHP, ресурсы, cron, доступ к серверу, интеграции или дальнейшее развитие проекта. Он также нужен при смене подрядчика или объединении инфраструктуры.
Когда лучше выбрать другой вариант
Если проблема только в одном тяжёлом плагине, ошибке темы или неоптимальной базе, смена сервера сама по себе может ничего не исправить. Сначала полезно провести диагностику и понять, действительно ли узкое место находится на стороне хостинга. Для этого можно начать с технической доработки WordPress.
Чек-лист перед переключением домена
- Есть отдельная резервная копия файлов и базы
- Новый сервер соответствует требованиям проекта
- База импортирована без ошибок
- wp-config.php использует настройки нового окружения
- Новая копия проверена до изменения DNS
- Постоянные ссылки и изображения работают
- Формы, почта, cron и webhook протестированы
- SSL готов к работе на основном домене
- Старый сервер не удаляется до финальной проверки
Частые вопросы
Можно ли перенести WordPress без смены домена?
Да. В этом случае основной URL остаётся прежним, а меняется сервер, на который указывает DNS. Это упрощает миграцию, потому что обычно не требуется глобальная замена домена в базе.
Нужно ли переносить всю базу данных?
Для полноценного клонирования сайта — да. В базе находятся записи, настройки WordPress и данные большинства плагинов. Частичный перенос используется только для специальных задач и требует отдельного плана.
Зачем использовать WP-CLI search-replace?
Команда умеет обрабатывать сериализованные данные WordPress и поддерживает dry-run. Это снижает риск повредить структуру данных при смене домена.
Можно ли сначала переключить DNS, а потом настраивать сервер?
Технически можно, но это повышает риск простоя. Безопаснее сначала подготовить и проверить новую копию, а DNS менять после тестирования.
Когда можно удалить старую копию сайта?
После того как новый сервер стабильно работает, проверены формы, фоновые задачи, SSL, интеграции и создан новый резервный backup. До этого старая копия остаётся полезной точкой отката.
Нужен ли VPS для любого WordPress-сайта?
Нет. Небольшому проекту может быть достаточно качественного shared-хостинга. VPS оправдан, когда нужны отдельные серверные настройки, больше контроля, ресурсы или нестандартная инфраструктура.
Вывод
Хороший перенос WordPress — это не копирование архива, а последовательная смена окружения с возможностью проверки и отката. Сначала фиксируется исходное состояние и делается backup, затем поднимается новая копия, проверяются данные и только после этого переключается DNS.
Если нужно перенести существующий WordPress-проект, проверить новый VPS и устранить проблемы после миграции, можно описать задачу A.S Groups.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.