Перенос сайта на другой хостинг обычно откладывают до последнего: боятся потерять письма клиентов или уронить сайт на пару дней посреди рабочей недели. На практике оба риска снимаются одним приёмом: развести по времени переключение сайта и переключение почты, и держать старый хостинг живым, пока новый не подтвердит свою работоспособность. Ниже план, которым пользуюсь сам, когда переношу клиентские сайты на WordPress, 1С-Битрикс и кастомном PHP с одного хостинга на другой.
Когда перенос сайта на другой хостинг оправдан
Смена хостинга не решает проблем с самим сайтом: кривой код или тяжёлые плагины будут тормозить и на новом сервере. Но есть поводы, из-за которых перенос оправдан.
- Старый тариф упирается в лимиты по нагрузке, и сайт падает при всплеске трафика: рассылка, реклама, сезонная распродажа.
- Нужен SSH-доступ или гибкий cron для фоновых задач, например для бота на aiogram или сценариев в n8n, а текущий провайдер даёт только панель без доступа к серверу.
- Провайдер поднял цену в несколько раз при продлении или закрывает бизнес, и ждать до последнего дня рискованно.
- Техподдержка не реагирует на инциденты по многу часов, а для интернет-магазина каждый час простоя это упущенные заказы.
Если сайт собран в Тильде, эта инструкция не про него: Тильда хостит сайты на своих серверах, и переносить там физически нечего, кроме выгрузки статического html-архива, после которого перестанут работать формы, каталог и оплата. Дальше речь про WordPress, 1С-Битрикс и кастомные сайты на PHP и MySQL, которые действительно живут на арендованном хостинге и могут переехать на другой.
Подготовка: что скопировать и проверить перед переносом хостинга
Перед тем как заводить аккаунт у нового провайдера, выписываю всё, что должно переехать вместе с сайтом.
- Файлы: папка с ядром CMS, загруженные картинки и документы, кастомные плагины и темы, .htaccess и любые правки php.ini.
- База данных целиком, с проверкой её реального размера, чтобы понимать, сколько займёт экспорт и импорт.
- Список задач cron: агенты Битрикс, wp-cron, собственные скрипты по расписанию.
- Список почтовых ящиков на домене и их объём, отдельно от сайта.
- SSL-сертификат, если он платный, а не выпущен автоматически через Let’s Encrypt.
- Полная зона DNS текущего домена, чтобы не потерять редкие записи вроде TXT для SPF или поддомены, которые давно не трогали.
Отдельно снижаю TTL у A и MX записей минимум за 48 часов до переноса, обычно до 300 секунд. Пока TTL высокий, DNS-серверы по всему миру держат старое значение в кэше по несколько часов, и после переключения часть посетителей ещё долго будет попадать на старый сервер. С низким TTL переключение происходит за считанные минуты у большинства провайдеров.
Способ переноса файлов и базы стоит выбирать под конкретную CMS.
| Метод | Что переносит | Когда использовать |
|---|---|---|
| Вручную через SFTP и mysqldump | Файлы и базу отдельными действиями, полный контроль над процессом | Подходит для любой CMS, особенно когда нужно перенести только часть файлов |
| Штатный бэкап-архив панели хостинга | Файлы, базу и иногда настройки cron одним архивом | Удобно, когда старый и новый хостинг работают на одной и той же панели управления |
| Плагин миграции для WordPress | Файлы, базу и замену адресов в контенте, если домен меняется | Подходит для WordPress, экономит время при большом количестве плагинов |
| Штатный модуль резервного копирования в 1С-Битрикс | Файлы и базу с учётом структуры модулей Битрикс | Подходит для сайтов на Битрикс, особенно с собственными модулями |
Перенос файлов и базы данных без остановки сайта
Старый сайт продолжает работать и принимать посетителей всё время, пока копирую файлы на новый сервер: это чтение с диска, оно не мешает текущим посетителям и не создаёт заметную нагрузку. Файлы копирую по SFTP или rsync, в зависимости от того, что даёт панель хостинга.
С базой сложнее, потому что она меняется в реальном времени: новые заказы, комментарии, правки в админке. Поэтому экспорт базы делаю в два захода. Первый, черновой, снимаю заранее, чтобы прогнать импорт и проверить, что на новом сервере всё поднимается без ошибок.
mysqldump -u DB_USER -p --single-transaction --quick DB_NAME > backup.sql
mysql -u NEW_DB_USER -p NEW_DB_NAME < backup.sqlВторой, финальный экспорт снимаю прямо перед переключением DNS, когда уже понятно, что структура и права на новом сервере в порядке. Дельта между черновым и финальным экспортом обычно занимает пару минут даже для базы на несколько гигабайт, поэтому реального простоя не возникает: сайт всё это время открыт на старом сервере, а на новом уже стоит актуальная копия.
Для WordPress отдельно ничего в базе менять не нужно, если домен остаётся тем же: адреса в таблице настроек и в контенте не меняются. Для 1С-Битрикс после переноса проверяю права на папки кэша и загрузок и запускаю переиндексацию поиска, потому что индекс не переезжает вместе с базой автоматически.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Проверка нового хостинга до переключения DNS
Прежде чем менять публичные DNS-записи, открываю сайт на новом сервере локально, через правку файла hosts на своём компьютере. Эта правка меняет адрес сайта только для одного устройства и не влияет на других посетителей.
203.0.113.10 example.ru
203.0.113.10 www.example.ruПосле этого проверяю на новом сервере версию PHP и набор расширений, обычно нужны mbstring, curl, gd или imagick, intl, права на папки, работу форм и админки. Если панель хостинга поддерживает выпуск SSL-сертификата на технический домен до переключения, выпускаю его заранее. Если нет, сертификат Let’s Encrypt на новом сервере обычно выпускается автоматически через несколько минут после того, как DNS начинает указывать на новый IP, и на это время браузеры могут показывать предупреждение о небезопасном соединении.
Перенос почты при смене хостинга без потери писем
Здесь работает то же разделение, что и в DNS: у домена отдельно есть A‑запись, которая отвечает за сайт, и отдельно MX-записи, которые отвечают за почту. Их можно переключать независимо друг от друга, и это главный способ не потерять письма при переезде.
Первый вариант, самый спокойный: почту вообще не трогать. MX-записи продолжают смотреть на старый хостинг, пока переезжает только сайт. Так можно жить сколько угодно, но платить за два хостинга подряд обычно смысла нет дольше пары месяцев, поэтому дальше почту всё равно стоит перенести.
Второй вариант: переносить почту вместе с сайтом, но по отдельному графику. Пока оба хостинга работают, синхронизирую ящики по IMAP: подключаю старый и новый ящик в одном почтовом клиенте и копирую папки между ними, либо использую встроенный инструмент миграции почты, если он есть в панели нового хостинга. Только после того как все письма на месте и новый ящик проверен, переключаю MX-записи. Пока TTL низкий, переключение занимает те же минуты, что и для сайта.
Отдельно проверяю записи SPF, DKIM и DMARC: если почта переезжает на новый сервер, в SPF нужно указать его как разрешённый источник отправки, иначе исходящие письма начнут падать в спам у получателей. Это касается и служебных писем от самого сайта: подтверждений заказа в WooCommerce, уведомлений от формы обратной связи, писем от Т‑Банка или другого эквайринга о статусе оплаты. Сами вебхуки от платёжных систем и служб доставки вроде СДЭК продолжат работать без изменений, если адрес обработчика на сайте не меняется, потому что они идут не на почту, а на URL сайта, который просто указывает теперь на новый сервер.
Переключение DNS и проверка после переноса сайта на другой хостинг
Когда черновая копия на новом сервере проверена, а почта синхронизирована, переключаю A‑запись на IP нового сервера. При TTL в 300 секунд большая часть посетителей начинает попадать на новый сервер в течение 5-30 минут, хотя отдельные провайдеры могут держать кэш дольше из-за собственных настроек.
После переключения проверяю:
- открывается ли сайт по https без предупреждений браузера;
- работают ли формы и приходят ли уведомления на почту;
- срабатывают ли вебхуки от платёжных систем и служб доставки;
- выполняются ли задачи по расписанию: агенты Битрикс, wp-cron, собственные скрипты;
- стоят ли на месте счётчики аналитики и коды подтверждения прав в панелях вебмастеров;
- уходит ли исходящая почта с домена без пометки спама.
Старый хостинг не отключаю ещё одну-две недели: если через несколько дней всплывёт что-то не проверенное сразу, можно быстро свериться со старой копией или откатить DNS назад. Если на новом сервере после переноса 1С-Битрикс ломаются пути или переиндексация, для точечных правок есть отдельная услуга: доработка и поддержка 1С-Битрикс, обычно это быстрее, чем разбираться самому в чужих модулях.
Частые вопросы
Сколько времени занимает перенос сайта на другой хостинг без простоя
Сам перенос файлов и базы занимает от пары часов до суток в зависимости от объёма: интернет-магазин с медиатекой в несколько гигабайт копируется дольше блога. TTL нужно снизить за 48 часов до переключения, а само переключение DNS и финальная сверка укладываются в 1-2 часа, если подготовка сделана заранее.
Нужно ли менять регистратора домена при переносе на другой хостинг
Нет, домен и хостинг это разные вещи. При смене хостинга меняются только DNS-записи, A и при необходимости MX, которые прописываются у регистратора или в панели DNS-провайдера. Сам домен трогать не нужно.
Что будет с почтой, если старый хостинг отключат раньше, чем запланировано
Если MX ещё смотрит на старый сервер, а его отключили, письма начнут возвращаться отправителям с ошибкой доставки. Поэтому до полного переключения почты старый хостинг должен оставаться оплаченным и рабочим, а если провайдер грозится закрыться, почту стоит перенести в первую очередь, раньше самого сайта.
Как проверить, что сайт на новом хостинге работает, до переключения DNS
Через правку локального файла hosts, который подменяет для конкретного компьютера IP-адрес домена, не трогая публичные DNS-записи. Так можно открыть сайт на новом сервере в браузере, проверить формы и базу, и только потом переключать DNS для всех посетителей.