Как перенести сайт WordPress с помощью плагина миграции
Если нужно быстро перенести WordPress на новый домен или хостинг без ручного копирования файлов и базы данных, плагин миграции обычно закрывает задачу лучше всего. Но это работает не во всех сценариях одинаково: один сайт можно перенести за несколько минут, а другой упрётся в лимиты хостинга, размер архива или несовместимость плагина с сервером.
Ниже разберём, когда плагин миграции действительно удобен, как выбрать подходящее решение и что проверить после переноса, чтобы не ловить битые ссылки, ошибки входа и проблемы с изображениями.
Когда плагин миграции — правильный выбор
Плагин миграции нужен, когда вы хотите перенести сайт целиком: файлы WordPress, базу данных, темы, плагины, медиафайлы и настройки. Это хороший вариант, если задача звучит так: «у меня есть рабочий сайт, и я хочу получить его точную копию на другом домене или хостинге».
Такой способ особенно удобен для:
- переезда с тестового домена на основной;
- смены хостинга без ручной работы с FTP и phpMyAdmin;
- создания копии сайта для разработки или проверки обновлений;
- переноса небольшого и среднего сайта, где архив не упирается в ограничения сервера.
Если сайт очень большой, база тяжёлая, а хостинг режет время выполнения PHP или размер загружаемых файлов, один плагин может не справиться. Тогда иногда проще использовать встроенный инструмент хостинга, SSH/rsync или помощь техподдержки. Плагин — не универсальная замена всем способам миграции, а самый удобный из них для типового сайта.
Какой плагин миграции выбрать
Смысл выбора здесь не в количестве функций, а в том, насколько плагин подходит под ваш сценарий. Для большинства владельцев сайтов важны три вещи: простота, предсказуемость и возможность восстановить сайт без ручного редактирования базы.
| Плагин | Когда подходит | Что учитывать |
|---|---|---|
| Duplicator | Перенос сайта на другой хостинг или домен, создание пакета для восстановления | Удобен для типовой миграции, но на очень больших сайтах может потребовать аккуратной настройки и подходящего хостинга |
| All-in-One WP Migration | Быстрый перенос через экспорт и импорт, особенно если нужен простой интерфейс | У бесплатной версии часто упираются в ограничения по размеру импорта; это важно проверить заранее |
| UpdraftPlus | Когда нужен не только перенос, но и регулярные резервные копии с возможностью восстановления | Как инструмент миграции удобен, если уже используется для бэкапов; для разового переезда не всегда самый прямой вариант |
| WPvivid Backup Plugin | Перенос и резервное копирование в одном решении | Подходит тем, кому нужен более гибкий сценарий с копиями и переносом, но интерфейс чуть сложнее, чем у самых простых решений |
Если вам нужен именно разовый перенос без ручной возни, я бы смотрел сначала на Duplicator или All-in-One WP Migration. Первый чаще выбирают, когда нужен более контролируемый пакет переноса. Второй удобен, если хочется максимально простой сценарий «экспортировал — импортировал» и размер сайта не слишком большой.
Если вы уже используете плагин для резервных копий, иногда разумно не ставить ещё один инструмент только ради миграции. Но если текущий плагин неудобен для переноса, лучше взять отдельное решение, чем пытаться подгонять неподходящий инструмент.
Подготовка перед переносом
Перед миграцией не стоит сразу нажимать «экспорт». Сначала проверьте несколько вещей — это экономит время, если что-то пойдёт не так.
- Сделайте свежую резервную копию сайта на старом хостинге.
- Проверьте, хватает ли места на диске и на старом, и на новом хостинге.
- Убедитесь, что версия PHP на новом сервере совместима с вашей версией WordPress и плагинами.
- Если на сайте есть кэш, временно отключите агрессивные кэширующие плагины перед переносом.
- Если используется CDN или отдельная система кэширования, заранее запланируйте её очистку после переноса.
Это не формальность. Большая часть проблем после миграции связана не с самим плагином, а с окружением: лимитами хостинга, старой версией PHP, нехваткой памяти или тем, что сайт после переноса продолжает отдавать старый кэш.
Как перенести сайт WordPress через плагин миграции
Логика у большинства плагинов похожа: на старом сайте вы создаёте архив или пакет, затем переносите его на новый домен или хостинг и запускаете восстановление. Отличаются детали интерфейса, но общий порядок действий обычно такой.
1. Установите плагин на старом сайте
Ставьте плагин только из официального каталога WordPress или с сайта разработчика. Для миграции это особенно важно: расширение получает доступ к файлам сайта и базе данных, поэтому сомнительные сборки использовать нельзя.
После установки запустите создание пакета переноса. В зависимости от плагина это может называться export, backup, package или archive.
2. Сформируйте архив сайта
Плагин обычно упаковывает файлы WordPress и дамп базы данных. На этом этапе могут всплыть ограничения:
- нехватка памяти PHP;
- таймаут при создании архива;
- запрет на запись в папку временных файлов;
- слишком большой объём медиафайлов.
Если архив не создаётся, не спешите переустанавливать WordPress. Сначала проверьте лимиты хостинга и журнал ошибок. Иногда достаточно увеличить memory_limit или использовать режим архивирования, который предлагает сам плагин.
3. Перенесите пакет на новый хостинг
Дальше вы загружаете архив и установочный файл на новый сервер. У некоторых плагинов это делается через обычную загрузку в браузере, у других — через отдельный installer.php или похожий скрипт.
На новом хостинге должен быть пустой или почти пустой каталог сайта. Если там уже лежит старая установка WordPress, конфликт версий и файлов почти гарантирован. Лучше заранее удалить лишнее или перенести сайт в отдельную директорию.
4. Запустите восстановление и замену адресов
Самый важный момент — корректная замена старого домена на новый. Хороший плагин миграции делает это автоматически, включая записи в базе данных, где хранятся ссылки, изображения и настройки темы. Именно поэтому ручной поиск и замена по базе обычно не нужны.
После восстановления проверьте, что сайт открывается по новому домену, а в админке нет ссылок на старый адрес. Если сайт переезжал на другой домен, иногда нужно отдельно обновить настройки в Настройки → Общие, если плагин не сделал это автоматически.
Что проверить после переноса
Даже если сайт открылся, это ещё не значит, что миграция завершена без ошибок. После переноса проверьте несколько точек, которые чаще всего ломаются.
- Главная страница и несколько внутренних страниц открываются без редиректов на старый домен.
- Изображения загружаются и не ведут на прежний адрес.
- Форма обратной связи, поиск и меню работают как раньше.
- Вход в админку проходит без ошибок.
- Постоянные ссылки не дают 404.
Если на сайте используются плагины кэша, безопасности или редиректов, очистите кэш и проверьте их настройки. Иногда именно они мешают увидеть результат переноса: сайт уже переехал, а браузер или плагин продолжает отдавать старые данные.
После смены домена отдельно проверьте SSL-сертификат. Если HTTPS не настроен на новом хостинге или сертификат ещё не выпущен, сайт может открываться с предупреждением браузера. Это не ошибка миграции как таковой, но она часто всплывает именно после переезда.
Типичные ошибки при переносе сайта плагином
Самая частая ошибка — выбирать плагин только по популярности, не проверив ограничения бесплатной версии. Для небольшого блога это может быть незаметно, а для сайта с большим количеством медиафайлов импорт внезапно упрётся в лимит.
Ещё несколько проблем, которые встречаются на практике:
- Перенос на хостинг с низкими лимитами. Плагин не виноват, если сервер обрывает процесс на середине архивации или распаковки.
- Старые абсолютные ссылки в базе. Если плагин не заменил домен корректно, картинки и кнопки будут вести на старый адрес.
- Конфликт с кэшем. После переноса сайт вроде бы работает, но часть страниц показывает старую версию.
- Смешение ручного и автоматического переноса. Когда файлы копируют вручную, а базу импортируют плагином, легко получить несоответствие путей и настроек.
- Оставленный старый сайт в открытом доступе. Если не закрыть старый домен или не настроить редирект, поисковики и пользователи могут попасть не туда.
Если переносите рабочий проект, не удаляйте старый сайт сразу после миграции. Сначала убедитесь, что новый домен полностью обслуживает сайт, а формы, письма и авторизация работают стабильно. Старую копию лучше держать хотя бы несколько дней как страховку.
Когда плагина недостаточно
Плагин миграции — хороший инструмент, но не всегда лучший. Если сайт очень большой, содержит десятки гигабайт медиафайлов или работает на нестандартной серверной конфигурации, проще и надёжнее использовать другие способы.
В таких случаях смотрите на:
- встроенную миграцию у хостинга;
- перенос через SSH и rsync;
- ручной импорт базы данных и файлов, если нужен полный контроль;
- помощь техподдержки хостинга, если у вас нет доступа к серверным инструментам.
Если задача сводится к одному сайту на обычном shared-хостинге, плагин почти всегда удобнее ручного переноса. Но если вы регулярно переносите несколько проектов или работаете с тяжёлыми сайтами, стоит заранее выбрать инструмент, который не будет упираться в лимиты на каждом втором проекте.
Что в итоге выбрать
Если нужен быстрый перенос без ручной работы, начните с плагина миграции, который подходит по размеру сайта и типу хостинга. Для простого переезда чаще всего достаточно Duplicator, All-in-One WP Migration или WPvivid Backup Plugin. Если у вас уже есть рабочий инструмент для резервных копий, возможно, отдельный плагин не понадобится.
Главное — не смотреть только на кнопку «перенести сайт». Перед установкой проверьте ограничения по размеру, совместимость с PHP и то, как плагин заменяет домен в базе. Именно эти детали определяют, будет ли миграция быстрой или превратится в долгую ручную доработку.
Если хотите подобрать плагин под конкретный сценарий, удобнее начинать не с названия, а с ответа на вопрос: вы переносите небольшой сайт, большой проект или хотите одновременно настроить резервные копии. От этого зависит, какой инструмент окажется действительно полезным, а какой только добавит лишнюю сложность.