Как перенести WordPress на другой хостинг — пошаговая инструкция
Перенос WordPress на другой хостинг — это не только копирование файлов. Нужно перенести базу данных, подправить wp-config.php, настроить веб-сервер и переключить DNS. При этом, если домен остаётся тем же, менять адреса в базе не требуется.
Почему сайт ломается при переезде
Чаще всего после переноса всплывают четыре проблемы:
- Подключение к базе данных. В wp-config.php прописаны имя базы, пользователь, пароль и хост старого хостинга. Пока они не заменены, WordPress не может подключиться к новой БД и показывает ошибку установки соединения.
- Версии PHP и MySQL. Актуальные требования WordPress: PHP 7.4+, MySQL 5.7+ или MariaDB 10.3+, HTTPS. Если на новом хостинге используется слишком старая или несовместимая версия PHP, сайт может не загрузиться. Несовместимость часто вызвана не самим ядром, а темой и плагинами.
- Права на файлы и владелец. На каждом хостинге своя схема: где-то PHP работает от пользователя аккаунта, где-то — от системного пользователя веб-сервера. Если владелец и группа файлов не совпадают с ожиданиями сервера, появляются ошибки записи, а иногда и 500.
- URL в базе данных. Это актуально только при смене домена: в wp_options хранятся siteurl и home, а в wp_posts и wp_postmeta — ссылки на старый адрес. При переезде на другой хостинг с тем же доменом менять их не нужно.
Подготовка: полный бэкап
Первый шаг — бэкап файлов и базы данных, до любых действий с хостингом. WP-CLI берёт параметры подключения из wp-config.php:
# Бэкап файлов (укажите фактическую директорию WordPress)
tar -czf ~/backup-site-$(date +%Y%m%d).tar.gz /путь/к/директории-wordpress/
# Экспорт БД через WP-CLI
wp db export ~/backup-db-$(date +%Y%m%d).sqlЕсли SSH недоступен — скачайте файлы через FTP/SFTP, а базу экспортируйте в phpMyAdmin (вкладка Экспорт, формат SQL). Проверьте, что архив открывается и дамп не пустой; для важных сайтов желательно убедиться, что SQL-дамп действительно содержит таблицы и данные. Затем скачайте бэкап на локальный компьютер: копия, которая лежит на том же сервере, бэкапом не считается.
Перенос без смены домена — основной сценарий
Если домен остаётся тем же, замена URL в базе обычно не требуется. Процесс выглядит так.
Шаг 1. Создайте базу данных на новом хостинге
Создайте БД и пользователя с правами на неё в панели хостинга (ISPmanager, Plesk, cPanel — интерфейс зависит от провайдера). Запишите имя базы, пользователя, пароль и хост: они понадобятся в wp-config.php.
Команда wp db create нужна только на серверах, где у пользователя действительно есть права создавать базы из CLI — в обычной ситуации база создаётся в панели. Учтите: wp db import базу не создаёт, он импортирует SQL в уже существующую базу.
Шаг 2. Скопируйте файлы
Загрузите все файлы WordPress на новый хостинг. Для большинства пользователей проще всего FTP/SFTP (FileZilla и аналоги): выделить содержимое корня сайта и залить в корень нового домена. Владельцам SSH быстрее rsync:
rsync -avz --progress /путь/к/сайту/ user@new-server:/путь/на/новом/сервере/Типовые права: директории 755, файлы 644, wp-config.php можно сделать строже (600 или 640). Это типовой вариант, а не универсальный: решающую роль играют не только цифры chmod, но и владелец/группа файлов и схема запуска PHP на конкретном хостинге.
Шаг 3. Импортируйте базу данных
В phpMyAdmin выберите новую базу, откройте вкладку Импорт и загрузите SQL-дамп. Либо через WP-CLI:
wp db import ~/backup-db-20260818.sqlПосле импорта проверьте наличие всех необходимых таблиц. Неполный импорт может привести к ошибкам сайта или отсутствию части данных.
Шаг 4. Настройте wp-config.php
Пропишите данные новой базы в wp-config.php на новом сервере. Хост базы не всегда localhost — уточните значение у хостинга:
define('DB_NAME', 'newdomain_wp');
define('DB_USER', 'newdomain_user');
define('DB_PASSWORD', 'новый_пароль');
define('DB_HOST', 'хост_базы_от_хостинга');Соли при переносе менять не обязательно — можно оставить прежние. Если всё же обновляете соли, помните: все авторизованные пользователи будут разлогинены. Если в старом wp-config.php были дополнительные константы или настройки кэша и внешних сервисов, перенесите их на новый сервер и проверьте совместимость.
Шаг 5. Настройте веб-сервер
На Apache правила обычно задаются в .htaccess. Если файл использовался на старом сервере, перенесите его и проверьте, что mod_rewrite и разрешение .htaccess настроены на новом сервере. Если в .htaccess были собственные редиректы или другие правила, сохраните их перед пересохранением постоянных ссылок и проверьте после него. После переноса пересохраните постоянные ссылки в админке (Настройки → Постоянные ссылки → Сохранить), чтобы WordPress переписал правила.
На Nginx .htaccess не работает: правила rewrite нужно прописать в конфиге виртуального хоста в зависимости от настроек веб-сервера:
location / {
try_files $uri $uri/ /index.php?$args;
}Это типовой пример для обычного WordPress; конкретная конфигурация Nginx зависит от сервера, PHP-FPM и дополнительных правил.
Шаг 6. Проверьте сайт на новом сервере до переключения DNS
Не переключайте DNS вслепую. Сначала откройте сайт, минуя DNS: через hosts-файл (прописать новый IP для домена на локальной машине), временный технический домен хостинга, staging URL или другой способ, который предлагает провайдер. При проверке через hosts WordPress всё равно использует значения siteurl и home из базы. Для корректного тестирования нового сервера их может потребоваться временно изменить на адрес нового сервера, а после проверки вернуть прежние значения перед переключением DNS. Проверьте главную, статьи, страницы, товары и админку на новом сервере, пока домен ещё отдаёт старый сайт.
Шаг 7. Переключите DNS
Если вы контролируете TTL, его можно снизить до 300 секунд за несколько часов или заранее до переезда — это ускорит распространение, но не обязательное условие. После переноса смените A-запись на IP нового хостинга.
Время переключения зависит от TTL, кэшей DNS и конкретных резолверов — единого срока нет. Проверка dig показывает состояние одного DNS-сервера, а не всей сети:
dig +short A домен.ru @8.8.8.8Если домен за Cloudflare, различайте два механизма: DNS-запись обновляется по TTL, а HTTP-кэш Cloudflare — отдельный механизм, из-за которого посетители могут видеть старую версию страницы. Очистка кэша Cloudflare ускоряет обновление сайта, но к переключению DNS отношения не имеет.
Проверка результата
Когда DNS переключился и сайт открывается с нового сервера, пройдите по чеклисту:
- главная, статьи, страницы, товары и админка открываются
- HTTPS работает: сертификат выпущен и не даёт ошибок
- редиректы корректны, в том числе с http на https
- формы отправляют сообщения — проверьте тестовым письмом
- авторизация: вход и выход из аккаунта
- существующие изображения отображаются; попробуйте загрузить новое в медиабиблиотеку
- WooCommerce, если используется: корзина, оформление заказа, письма о заказах; дополнительно проверьте очередь фоновых заданий Action Scheduler
- cron и фоновые задачи, если они настроены
- логи PHP и веб-сервера — нет новых ошибок
Дополнительные проверки:
- Ядро. wp core verify-checksums сверяет только файлы ядра — плагины и тему он не проверяет
- Остатки старого URL. Если домен менялся, проверьте, не осталось ли ссылок на старый адрес: wp search-replace 'https://старый-домен.ru' 'https://новый-домен.ru' --all-tables --precise --skip-columns=guid --dry-run или wp db search 'старый-домен.ru' --all-tables. Старый адрес может легально встречаться в GUID и сторонних данных — это не ошибка, поэтому пустой результат не обязателен
- Кэши. Очистите object cache (wp cache flush), а также кэш конкретного плагина или сервера; при наличии доступа сбросьте OPcache; при persistent object cache очистите Redis/memcached, если после переноса сайт продолжает использовать старые данные; сайт за Cloudflare — очистите HTTP-кэш
- Почта. Отправьте тестовое письмо через форму обратной связи или через настроенный на сайте SMTP-плагин. Разделяйте MX и SMTP: MX-записи отвечают за получение почты на ящики, SMTP-сервер — за отправку. Перенос сайта не переносит почтовые ящики: если почта осталась у старого провайдера и MX не менялись, получение почты переезд не затрагивает
Если домен меняется: замена URL в базе
При смене домена адреса в базе менять нужно. Используйте wp search-replace — он корректно обрабатывает сериализованные данные плагинов и опций, в отличие от ручной замены в SQL-редакторе:
wp search-replace 'https://старый-домен.ru' 'https://новый-домен.ru' --all-tables --precise --skip-columns=guid--all-tables означает все таблицы базы, включая не-WordPress. Если база используется только этим сайтом, это нормально; если в той же базе находятся другие приложения или сайты, ограничьте список таблиц.
При миграции с изменением домена исключите колонку guid из замены: --skip-columns=guid. GUID — не обычная ссылка, а идентификатор записи, и менять его не рекомендуется, даже при смене домена.
Если адрес сайта изменился только по протоколу (http на https), проверьте и при необходимости обновите home и siteurl:
wp option update home 'https://домен.ru'
wp option update siteurl 'https://домен.ru'Если WP_HOME или WP_SITEURL заданы в wp-config.php, они имеют приоритет над значениями home и siteurl в базе.
Когда этот способ не сработает
1. База больше, чем позволяет phpMyAdmin
На больших дампах phpMyAdmin упирается в лимиты по размеру загрузки и времени выполнения. Тогда используйте CLI-инструменты: mysql или wp db import. На пределы влияют разные параметры: лимиты PHP (upload_max_filesize, post_max_size), max_allowed_packet в MySQL/MariaDB, таймауты и способ импорта — универсального одного решения нет.
2. PHP-несовместимость темы или плагинов
На новом хостинге версия PHP может отличаться. Несовместимость часто вызывает не ядро, а темы и плагины со старым кодом (например, устаревшие функции вроде each() — это лишь пример, не главная причина). До переключения PHP проверьте совместимость темы и плагинов. На рабочем сайте не выводите ошибки посетителям: логируйте их в файл. Минимальная конфигурация в wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );3. Переезд с Apache на Nginx
.htaccess на Nginx не работает. Правила редиректов, защиты и кэширования переносите в конфиг Nginx, а не в .htaccess. Пересохранение постоянных ссылок в админке обновляет rewrite-правила на Apache; для Nginx правила прописываются в конфигурации веб-сервера.
4. Почта остаётся у старого провайдера
Ящики на домене могут продолжать обслуживаться старым хостингом: MX-записи останутся прежними, и получение почты переезд не затронет. Отправка писем сайтом настраивается отдельно (SMTP-плагин, почтовый сервис) и зависит от нового сервера.
Частые вопросы
Нужна помощь с переносом WordPress?
Перенесу сайт без потери контента и позиций: файлы, база, DNS, почта и проверка после переезда. Есть опыт с Beget, Timeweb и Reg.ru.
