Перенос WordPress на другой хостинг или домен: порядок действий

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

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

Сначала определите, что именно меняется

Составьте короткую карту: старый адрес, новый адрес, место хранения файлов и базы, почта, CDN и внешние интеграции. Отдельно отметьте, кто управляет доменом и DNS. Доступ к WordPress не всегда даёт доступ к этим настройкам.

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

Сделайте согласованную резервную копию

У WordPress две основные части: файлы и база. В файлах находятся загрузки, темы, плагины и конфигурация; записи, пользователи и многие настройки лежат в базе. Копия каталога сайта обычно не включает саму базу MySQL или MariaDB. Экспорт записей из админки тоже не является полной копией установки.

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

Если используете WP-CLI, экспорт базы можно выполнить так. Путь условный: каталог должен существовать и находиться вне публичного корня сайта.

wp db export /private/backups/site-before-move.sql

Не оставляйте SQL-дамп доступным по адресу сайта. Он может содержать персональные сведения и настройки интеграций. Архив файлов, экспорт базы и сведения о версии окружения храните вместе, но отдельно от единственного сервера, который собираетесь отключить. Общие меры защиты разобраны в практическом гайде по безопасности WordPress.

Проверка копии — это попытка восстановить её в подготовленной среде. Наличие большого ZIP-файла не подтверждает, что внутри есть все загрузки, а SQL-экспорт читается и относится к тому же состоянию сайта.

Подготовьте новый хостинг до изменения DNS

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

Перенесите файлы и восстановите базу в отдельную целевую базу. В wp-config.php укажите её имя, пользователя, пароль и адрес сервера. Не угадывайте DB_HOST: у нового провайдера это может быть отдельный узел. Проверьте также префикс таблиц и нестандартные пути.

Для импорта через WP-CLI используется команда ниже. Выполнять её следует в контексте новой установки и только после проверки целевой базы: импорт изменяет её содержимое.

wp db import /private/backups/site-before-move.sql

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

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

При прежнем домене не заменяйте URL без причины

Если домен, протокол и пути остаются прежними, массовая замена адресов обычно не нужна. Основная работа — воспроизвести серверное окружение, проверить копию и направить DNS на новый хостинг. Временный технический адрес провайдера не обязан становиться постоянным адресом WordPress.

Проверьте два значения: home — адрес сайта для посетителя, siteurl — расположение файлов ядра WordPress. В стандартной установке они часто совпадают, но при ядре в отдельном каталоге могут различаться. Константы WP_HOME и WP_SITEURL в конфигурации способны переопределять значения из базы.

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

Если меняется домен: замена адресов без повреждения данных

WordPress и плагины могут хранить URL внутри сериализованных PHP-структур, где записана длина строк. Обычная текстовая замена по SQL-дампу способна нарушить эту структуру. WP-CLI search-replace учитывает сериализацию; это одна из причин пользоваться специализированным инструментом.

Учебный пример ниже относится к целевой копии сайта. Домены old.example и new.example нужно заменить своими значениями. Сначала получите отчёт без записи:

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

Посмотрите список таблиц и число замен. Параметр --all-tables-with-prefix расширяет обработку на таблицы с префиксом установки, включая таблицы плагинов. Проверьте, что этот набор действительно относится к переносимому сайту. Колонку guid в таком сценарии пропускают.

Когда область проверена и резервная копия готова, ту же команду выполняют без --dry-run. Отдельно проверьте варианты старого адреса с HTTP и www: одна точная строка не охватывает автоматически все написания. Не заменяйте любое совпадение названия домена во всех таблицах сервера.

После изменения адресов проверьте медиа, меню, виджеты, настройки конструктора и созданные CSS-файлы. Некоторые плагины требуют пересборки своих ресурсов. Удалять старый домен из текста исторической статьи только потому, что он встретился при поиске, тоже не всегда правильно.

Проверьте копию по сценарию посетителя

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

Если главная работает, а записи возвращают 404, проверьте постоянные ссылки и конфигурацию веб-сервера. Обновление правил WordPress не заменяет настройку Nginx; файл .htaccess относится к окружениям, которые его обрабатывают. Не переносите правила Apache на другой сервер как универсальное решение.

Очистите нужные слои кеша и убедитесь, что открываете ответ нового сервера. Проверьте отправку тестового письма, cron, очереди, загрузку файлов, права доступа и логи ошибок PHP. Разницу между кешем страницы и объектным кешем объясняет обзор кеширования WordPress.

Переключите трафик и проверьте свежие данные

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

Скорость распространения зависит от кешей и настроек DNS; нет универсального срока, за который каждый посетитель обязательно окажется на новом сервере. Следите за запросами к обеим площадкам. Не допускайте, чтобы старый и новый сайты независимо принимали заказы или комментарии: данные разойдутся.

При смене домена настройте постоянные перенаправления со старых страниц на соответствующие новые. Не отправляйте все URL на главную. Обновите внутренние ссылки, canonical и sitemap; для подходящего переезда домена используйте Change of Address в Google Search Console. Google рекомендует сохранять перенаправления как минимум год, а для пользователей часто разумно дольше.

Смена хостинга без изменения URL — другой сценарий: ему не нужны перенаправления на новый домен и уведомление о смене адреса. В обоих случаях после запуска проверьте отсутствие случайного noindex и блокировок обхода на рабочих страницах.

План отката нужен до переключения

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

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