Перенос сайта WordPress на другой хостинг: три способа

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

Что именно переносим

Файлы. Всё содержимое корневой папки WordPress: wp-admin, wp-includes, wp-content (темы, плагины, загрузки), wp-config.php, .htaccess и всё, что лежит рядом. Ядро WordPress технически можно не копировать, а скачать заново — оно одинаковое. Но копировать целиком проще и безопаснее: в корне часто оказываются файлы подтверждения домена, старые лендинги, скрипты платёжных систем.

База данных. Записи, страницы, товары, настройки, пользователи, комментарии, содержимое большинства плагинов — всё это в MySQL. Файл дампа с расширением .sql и есть база.

Та же механика работает и в обратную сторону — когда сайт собран локально на компьютере и переезжает на свой первый хостинг: те же файлы, дамп базы и замена адреса.

DNS. Домен указывает на IP-адрес старого сервера. Пока запись не изменена, посетители приходят на старый хостинг, что бы вы ни скопировали на новый.

Отдельная вещь, о которой вспоминают в последний момент, — почта на домене. Если ящики вида info@вашсайт.ru обслуживает старый хостинг, при смене NS-серверов они перестанут работать. Либо заводите ящики на новом хостинге заранее, либо оставляете MX-записи указывать на прежний почтовый сервер.

Подготовка: что сделать до копирования

На эти проверки уходит полчаса, и они окупаются: почти все проблемы после переезда родом отсюда.

Снимите размер сайта и число файлов. По SSH: du -sh . покажет объём, find . -type f | wc -l — количество файлов. Второе важнее первого: на виртуальном хостинге есть лимит inodes (обычно 200–500 тысяч), и сайт с большой медиатекой или кэшем миниатюр может в него упереться на новом тарифе. Заодно поймёте, пролезет ли сайт в плагин миграции — там ограничение по объёму архива.

Сверьте стек. Версия PHP на старом хостинге и на новом должны совпадать хотя бы по мажорной ветке. Переезд с PHP 7.4 сразу на 8.3 вместе с переносом — плохая идея: если сайт упадёт, вы не поймёте, дело в миграции или в несовместимом плагине. Сначала переезд, потом обновление PHP. Посмотреть текущую версию: Консоль → Информация о системе в админке WordPress или php -v в SSH.

Отключите кэш. Это самая частая причина белого экрана после переезда. Плагины кэширования (LiteSpeed Cache, W3 Total Cache, WP Super Cache) оставляют в wp-content два drop-in файла — advanced-cache.php и object-cache.php, — которые жёстко привязаны к путям и к Redis на старом сервере. На новом сервере такого Redis нет, и сайт отдаёт белый экран ещё до загрузки темы. Перед снятием копии деактивируйте плагин кэша, удалите папку wp-content/cache и оба drop-in файла, если они остались.

Сделайте резервную копию — обе части. Даже если переносить будет поддержка. Архив файлов и дамп базы, скачанные к себе на компьютер, — это точка возврата на случай, если что-то пойдёт не так сразу на обеих площадках. Копия, лежащая только на сервере провайдера, такой точкой не является.

Запишите доступы. Логин и пароль от панели старого хостинга, FTP/SSH, реквизиты базы из wp-config.php (константы DB_NAME, DB_USER, DB_PASSWORD, DB_HOST), доступ к DNS-записям домена — это может быть панель регистратора, а не хостинга. Отсутствие доступа к DNS обнаруживают обычно в момент, когда всё остальное уже готово.

Три способа: что выбрать

Бесплатный перенос силами провайдера — вариант по умолчанию для большинства. Он есть не у всех: по данным официальных сайтов на август 2026 бесплатную миграцию заявляют Beget, Timeweb, FirstByte, Джино, NetAngels и FirstVDS, а SpaceWeb, REG.RU и RuVDS — нет. Актуальные условия по каждому провайдеру собраны в рейтинге хостингов.

Способ 1: перенос силами нового хостинга

Порядок такой. Регистрируете аккаунт у нового провайдера, выбираете тариф (на время переноса подойдёт тестовый период — у Beget и Джино это 30 дней, у SpaceWeb 14, у Timeweb 10). Пишете в поддержку: «Прошу перенести сайт с хостинга X, доступы прилагаю». Обычно просят FTP-доступ и доступ к панели старого хостинга либо готовый архив.

Что стоит уточнить сразу, одним сообщением:

• Перенесут ли базу вместе с файлами (иногда переносят только файлы).
• Настроят ли wp-config.php под новые реквизиты базы.
• Сколько занимает очередь — в будни это несколько часов, перед выходными бывает сутки.
• Что делать с почтой на домене.

Дальше сайт появится на новом сервере по временному адресу — обычно это техдомен вида login.hostname.ru. Не переключайте DNS, пока не проверили копию. Как проверить правильно — в разделе про DNS ниже.

Один нюанс, который поддержка не проверит за вас: если сайт использовал Redis или Memcached, на новом тарифе объектного кэша может не быть. Из девяти провайдеров каталога объектный кэш на виртуальном хостинге заявлен у NetAngels, а у SpaceWeb он появляется на тарифах от 1 199 ₽/мес. Остальные его на странице тарифов не обещают — уточняйте до переноса, а не после.

Способ 2: перенос плагином

Подходит для сайтов до 500 МБ без сложных зависимостей. Два рабочих варианта — All-in-One WP Migration и Duplicator.

All-in-One WP Migration проще: на старом сайте All-in-One WP Migration → Экспорт → В файл, получаете архив .wpress. На новом хостинге ставите чистый WordPress, тот же плагин, Импорт → Из файла. Плагин заменит базу и файлы целиком, включая ссылки в контенте. Бесплатная версия ограничивает размер импортируемого файла — на большинстве сборок это 512 МБ; обойти лимит правкой констант плагина технически можно, но после обновления плагина правка слетает.

Duplicator делает архив плюс скрипт installer.php, который разворачивает сайт на новом сервере с нуля. Он гибче — умеет менять пути и URL при установке, — но на больших сайтах бесплатная версия часто не дособирает архив по таймауту PHP.

Порядок для обоих одинаковый:

1. На старом сайте отключить кэш-плагины и удалить wp-content/cache.
2. Собрать архив, скачать его к себе (не оставлять только на сервере).
3. На новом хостинге поставить WordPress через автоустановщик панели — как это делается, разобрано в инструкции по установке WordPress.
4. Поставить плагин миграции, импортировать архив.
5. Зайти в Настройки → Постоянные ссылки и нажать «Сохранить» — это пересоздаёт правила в .htaccess.

Типичная проблема на этом пути — лимиты PHP на новом хостинге: upload_max_filesize и post_max_size меньше размера архива, max_execution_time в 30 секунд обрывает импорт. Значения меняются в панели хостинга (раздел настроек PHP) или в .htaccess; если панель их не даёт — это вопрос к поддержке, и ответ на него заодно покажет, насколько быстро она работает.

Способ 3: вручную через SSH

Самый быстрый способ для большого сайта: гигабайтная медиатека копируется между серверами напрямую, минуя ваш интернет-канал.

На старом сервере снимаем базу и архивируем файлы:

# дамп базы: реквизиты берём из wp-config.php
mysqldump -u DB_USER -p --single-transaction --default-character-set=utf8mb4 DB_NAME > ~/dump.sql

# архив файлов без кэша
cd ~/сайт/public_html
tar --exclude='wp-content/cache' --exclude='wp-content/upgrade' -czf ~/site.tar.gz .

Флаг --single-transaction снимает дамп без блокировки таблиц — на живом магазине это принципиально. --default-character-set=utf8mb4 спасает кириллицу от превращения в «кракозябры»: дамп в неправильной кодировке — вторая по частоте причина испорченного контента после переезда.

Копируем на новый сервер. Если SSH есть на обеих сторонах, быстрее всего через rsync прямо между ними:

rsync -avz ~/site.tar.gz ~/dump.sql newuser@new-host.ru:~/

Дальше на новом сервере распаковываем, создаём базу через панель, импортируем дамп и правим конфиг:

tar -xzf ~/site.tar.gz -C ~/сайт/public_html
mysql -u NEW_USER -p NEW_DB < ~/dump.sql

В wp-config.php меняем четыре константы — DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Про DB_HOST стоит сказать отдельно: на многих хостингах это не localhost, а отдельный адрес вида mysql.hostname.ru или localhost:/tmp/mysql.sock. Правильное значение всегда написано в панели рядом с реквизитами базы.

Права на файлы после распаковки: каталоги 755, файлы 644, wp-config.php — 600 или 640.

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

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

wp search-replace 'https://старый-домен.ru' 'https://новый-домен.ru' --all-tables --dry-run

Сначала с --dry-run — команда покажет, сколько замен сделает, ничего не меняя. Без SSH ту же работу делает плагин Better Search Replace, у него тоже есть режим предпросмотра. WP-CLI на виртуальном хостинге есть не везде: ни один из девяти провайдеров каталога не заявляет её на странице тарифов, хотя фактически на части площадок она установлена — это вопрос к поддержке.

Переключение DNS без простоя

Здесь теряют время и трафик чаще всего.

За сутки до переезда снизьте TTL. В панели, где управляются DNS-записи домена, найдите A-запись и поставьте TTL 300 секунд вместо стандартных 3600 или 14400. TTL — это время, которое провайдеры и браузеры хранят старый ответ в кэше. Снизив его заранее, вы получите переключение за минуты; забыв — будете ждать до суток, пока часть аудитории видит старый сервер.

Проверьте копию через файл hosts. До переключения домена откройте сайт на новом сервере так, как его увидят посетители. На macOS и Linux правится /etc/hosts, на Windows — C:\Windows\System32\drivers\etc\hosts. Добавляете строку:

203.0.113.10  вашсайт.ru www.вашсайт.ru

где первым идёт IP нового сервера. После этого ваш браузер идёт на новый хостинг, а весь остальной мир — на старый. Проверяете главную, несколько внутренних страниц, админку, форму обратной связи, корзину. Убедились — удаляете строку из hosts.

Переключаете запись. Два варианта: сменить A-запись на IP нового сервера (быстрее, MX и прочие записи остаются как были) или сменить NS-серверы домена на серверы нового хостинга (проще, но переносит вместе с собой всю зону — включая почту). Для сайта с рабочей почтой на старом хостинге безопаснее менять именно A-запись.

Как проверить, что запись разошлась: dig +short вашсайт.ru или nslookup вашсайт.ru. Сравните ответ с IP нового сервера.

SSL выпускаете после переключения. Бесплатный сертификат Let’s Encrypt выдаётся только после того, как домен указывает на сервер, где он запрашивается: центр сертификации проверяет это HTTP-запросом. Поэтому порядок такой — переключили DNS, дождались обновления, нажали «Выпустить сертификат» в панели нового хостинга. Между этими событиями сайт минут двадцать может отдавать предупреждение браузера; чтобы этого не произошло, переключайте DNS в ночь на будний день, а не в понедельник утром.

Что проверить после переезда

Пройдитесь по списку прежде, чем закрывать вопрос:

1. Главная и 5–10 внутренних страниц открываются, картинки на месте.
2. Постоянные ссылки — зайдите в Настройки → Постоянные ссылки и нажмите «Сохранить», даже если ничего не меняли. Без этого внутренние страницы часто отдают 404.
3. Индексация разрешена — Настройки → Чтение, галочка «Попросить поисковые системы не индексировать сайт» должна быть снята. Проверьте заодно вашсайт.ru/robots.txt: не осталось ли там Disallow: / с тестовой площадки.
4. HTTPS без смешанного контента — откройте консоль браузера (F12) и посмотрите, нет ли предупреждений про Mixed Content. Появляются, если часть ссылок в базе осталась на http://.
5. Админка и загрузка файлов — попробуйте залить картинку в медиатеку. Ошибка на этом шаге означает неверные права на wp-content/uploads.
6. Формы и почта. WordPress отправляет письма через mail(), и на новом хостинге они часто уходят в спам или не уходят вовсе. Нормальное решение — плагин SMTP с ящиком на своём домене.
7. Cron. Проверьте, что запланированные публикации и задачи плагинов выполняются. Если раньше был настроен системный cron, на новом хостинге его нужно создать заново — задание вида php /path/to/wp-cron.php в планировщике панели.
8. Редиректы из .htaccess — старые 301 с изменённых URL должны сохраниться. Файл .htaccess начинается с точки и в файловых менеджерах по умолчанию скрыт, поэтому его регулярно забывают скопировать.
9. Бэкапы на новом месте — включены ли автоматические копии, какая глубина хранения. У FirstByte и REG.RU заявлено хранение до 30 копий, у остальных обычно 7 дней.
10. Скорость. Замерьте TTFB на новом сервере через webpagetest.org и сравните со старым — ради этого переезд, скорее всего, и затевался. Если разница меньше ожидаемой, дело обычно не в площадке: разбор скорости по слоям показывает, где именно теряются миллисекунды.

Первую неделю имеет смысл поглядывать на отчёт об ошибках в Яндекс.Вебмастере и Search Console: рост 404 или 5xx там виден раньше, чем в аналитике.

Частые проблемы и что они значат

«Error establishing a database connection». WordPress не подключается к базе: неверные реквизиты в wp-config.php или неправильный DB_HOST. Проверьте пароль (при копировании часто теряется последний символ) и значение хоста базы в панели нового хостинга.

Белый экран. Чаще всего — оставшийся object-cache.php или advanced-cache.php от плагина кэша, реже несовместимость плагина с версией PHP. Удалите оба файла из wp-content, а если не помогло — включите вывод ошибок, добавив в wp-config.php строки define('WP_DEBUG', true); и define('WP_DEBUG_LOG', true);, и посмотрите wp-content/debug.log.

Сайт открывается, а админка уходит в бесконечный редирект. В базе прописан старый адрес: таблица wp_options, поля siteurl и home. Правится через phpMyAdmin или временной строкой в wp-config.php: define('WP_HOME','https://вашсайт.ru'); define('WP_SITEURL','https://вашсайт.ru');.

Вместо кириллицы «кракозябры». Дамп снят или залит в другой кодировке. Лечится повторным переносом базы с явным указанием --default-character-set=utf8mb4 на обеих операциях. Чинить контент постфактум почти всегда дороже, чем перезалить базу.

403 Forbidden на всём сайте. Права на файлы после распаковки архива — типично, когда tar сохранил права 777 или владельца другого пользователя. Выставьте 755/644 командами из раздела выше.

Часть картинок пропала. Перенеслась база, но не все файлы из wp-content/uploads. Сравните число файлов на обоих серверах: find wp-content/uploads -type f | wc -l.

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

Переезд ради переезда обычно не окупается. Разумные поводы: упёрлись в лимиты тарифа (503 при росте трафика, превышение inodes), нужен объектный кэш или свежая версия PHP, которых нет у текущего провайдера, поддержка отвечает сутками, цена продления выросла вдвое.

Плохой повод — «где-то дешевле на 50 рублей». Разница в 600 ₽ за год не стоит вечера работы и риска потерять почту. Если сомневаетесь, стоит ли уходить, сверьтесь с чек-листом выбора хостинга — он показывает, какие ограничения действительно критичны, а какие терпимы.

И обратная ситуация: если сайт упирается в ресурсы, менять один виртуальный хостинг на другой смысла мало — нужен VPS или managed-тариф. Для магазина на WooCommerce разница особенно заметна, там свои требования к стеку — они разобраны в разделе про хостинг для WooCommerce.