Как перенести сайт к новому хостинг-провайдеру без простоя

Перенос сайта на новый хостинг пугает не копированием файлов, а риском потерять заявки, заказы, почту или позиции в поиске из-за малейшего простоя. По опыту могу сказать: большинство аварийных ночей после миграции случаются не из-за сложности переноса, а из-за отсутствия чёткой последовательности. Если заранее подготовить площадку, синхронизировать данные и аккуратно переключить DNS, сайт продолжит работать для пользователей без видимых разрывов. Ниже — рабочая схема, которая подходит и небольшому корпоративному сайту, и интернет-магазину на WordPress, 1C-Битрикс, OpenCart, Joomla или самописном приложении.

Что значит «без простоя» на практике

Абсолютно нулевой простой в мире сетей и серверов — скорее исключение, чем правило. Но для посетителя переезд должен быть незаметным. Это означает, что в момент переключения трафика сайт отвечает, новые заявки не теряются, письма доходят, база данных не расходится между старым и новым сервером, а поисковые роботы не упираются в длинные серии 5xx или пустые страницы.

Главная задача — не просто скопировать файлы, а организовать короткий период параллельной работы двух площадок, когда трафик переключается либо постепенно, либо в один управляемый момент. Именно это позволяет избежать эффекта «сайт лежит, пока DNS обновляется».

Когда миграция особенно критична

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

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

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

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

Чек-лист перед переносом

• Текущая CMS, версия PHP, СУБД и веб-сервера.
• Размер файлового хранилища и базы данных.
• Где находятся cron-задачи и фоновые обработчики.
• Используется ли Redis, Memcached, очереди, object storage.
• Как устроена почта: на хостинге, в стороннем сервисе или на отдельном сервере.
• Какие DNS-записи сейчас используются.
• Какие поддомены должны переехать вместе с основным сайтом.
• Есть ли SSL-сертификат и как он выпускается.
• Используются ли CDN, WAF, антибот-защита.
• Есть ли интеграции: 1С, CRM, платёжные шлюзы, вебхуки, API.

Что важно уточнить у нового хостера

Формальное «подходит» новой площадки ещё ни о чём не говорит. Заранее проверьте, поддерживает ли она нужную версию PHP или другого runtime, требуемую редакцию MySQL/MariaDB/PostgreSQL, SSH-доступ, ручное управление DNS или внешний DNS, автоматический выпуск SSL, резервные копии, лимиты по CPU, RAM, inode, процессам и исходящему трафику, а также ограничения на отправку почты.

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

Оптимальная схема переноса без простоя

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

1. Подготовить новый сервер заранее

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

Не стоит «ставить как-нибудь» — повторяйте рабочую конфигурацию старого сервера. Даже минорное расхождение в версиях PHP или MySQL может проявиться только после переключения трафика, когда откатываться уже поздно. Проверьте, например, что модуль mod_rewrite включён, если сайт на Apache, или что Nginx корректно проксирует динамику.

2. Скопировать файлы сайта

Копируйте код, изображения, загружаемые файлы, шаблоны, логику CMS и статические ресурсы. Для небольших проектов хватит scp или SFTP-клиента. Для крупных сайтов удобнее rsync по SSH: он умеет передавать только изменения и не рвёт соединение на середине.

Если объём данных исчисляется гигабайтами, делайте копирование в два этапа: сначала основную массу файлов, затем — дельту, то есть то, что изменилось перед переключением. Так вы не держите сайт в долгом «окне тишины», а время финальной синхронизации сокращается до минут.

3. Перенести базу данных

База — самая чувствительная часть миграции. Если она продолжает меняться во время копирования, можно получить битые заказы, дубли или потерянные записи. Для маленьких сайтов подойдёт дамп через mysqldump для MySQL/MariaDB или pg_dump для PostgreSQL.

Для больших проектов лучше сделать дамп в непиковое время, временно перевести сайт в режим только чтения, если это возможно, либо сначала синхронизировать базу, а финальный дамп снять прямо перед переключением. Если объём большой, обратите внимание на опции --single-transaction у mysqldump или снятие снапшота у PostgreSQL — это позволяет не блокировать таблицы на время выгрузки.

4. Проверить сайт на новом сервере до переключения DNS

Ключевой этап, который часто пропускают. Новый хостинг должен быть протестирован до того, как туда пойдут реальные посетители. Проверяйте открытие главной страницы, работу внутренних страниц, авторизацию, формы, корзину и оформление заказа, загрузку изображений, отправку почты, генерацию sitemap и robots.txt, корректность HTTPS, редиректы и скорость ответа.

Удобный способ — прописать домен на своей машине в файле hosts или использовать временную техническую площадку, если её предоставляет хостер. Так вы увидите сайт на новом сервере ровно с тем же доменом, но без изменения публичных DNS.

5. Заморозить изменения на старом сервере

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

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

6. Сделать финальную синхронизацию

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

7. Переключить DNS с учетом TTL

Самый частый источник простоя — не перенос, а DNS. Если TTL высокий, часть пользователей ещё долго будет ходить на старый сервер. Если старый уже выключен, они увидят ошибку. Поэтому TTL снижают заранее, обычно за 24–48 часов до миграции, чтобы изменения распространились быстрее.

Практика по DNS

Если сайт использует CDN или прокси-платформу, переключение нужно делать там же, а не только на уровне доменной зоны. Например, в Cloudflare достаточно сменить origin IP, но не забыть обновить и A-запись, если она указывает напрямую.

Как не потерять почту при переезде

Почта — отдельная зона риска, о которой вспоминают, когда заявки перестают приходить. Многие переносят сайт, а MX-записи, SPF, DKIM и DMARC остаются на старом хостинге, который выключают через час после миграции.

Что проверить заранее

• Где реально обслуживается почта.
• Не меняется ли почтовый сервер при переносе.
• Совпадают ли MX-записи.
• Обновлены ли SPF и DKIM.
• Не привязаны ли формы сайта к локальной почте на старом сервере.

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

Типовая ошибка

Сайт уже открыт на новом хостинге, а письма из форм продолжают отправляться через старый SMTP, который выключили через час после миграции. В итоге пользователь видит «успешную отправку», а менеджер заявку не получает. Проверяйте настройки отправки в CMS и сторонних модулях: они могут хранить IP-адрес или hostname старого почтового сервера.

Пошаговый план переноса без простоя

Ниже — рабочая последовательность, которой удобно придерживаться. Она объединяет все предыдущие шаги в конкретный чек-лист.

Шаг 1. Снизить TTL за сутки-двое

Уменьшите TTL у основных DNS-записей до 300–600 секунд. Это не ускорит само переключение, но после изменения записи новые значения разойдутся по резолверам намного быстрее.

Шаг 2. Подготовить новый хостинг

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

Шаг 3. Перенести основную копию сайта

Скопируйте файлы и первичный дамп базы. Если сайт большой, используйте rsync и дамп в непиковое время.

Шаг 4. Проверить проект на новом сервере

Протестируйте вход, формы, корзину, страницы, HTTPS и почту. Не пропускайте этот этап даже ради экономии получаса.

Шаг 5. Заморозить изменения на старом сервере

Остановите любые операции, которые пишут данные. Это касается не только пользователей, но и фоновых задач, импортов, синхронизаций с CRM.

Шаг 6. Сделать финальный дамп и дельта-синхронизацию

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

Шаг 7. Переключить DNS

Измените A/AAAA/CNAME-записи или параметры у CDN/балансировщика. После этого начнётся период, когда разные пользователи могут видеть сайт на разных серверах.

Шаг 8. Контролировать оба сервера

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

Шаг 9. Не выключать старый хостинг сразу

Оставьте старый сервер активным хотя бы на 24–72 часа. Это даст запас на случай, если у какого-то провайдера DNS-кэш окажется особенно живучим.

Что проверить после переключения

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

Минимальный постпереездный чек-лист

• Открывается ли сайт по HTTP и HTTPS.
• Нет ли циклов редиректа.
• Корректно ли работает www и без www.
• Отправляются ли формы.
• Создаются ли заказы.
• Приходят ли письма.
• Нет ли битых изображений.
• Доступен ли /robots.txt.
• Отдается ли sitemap.xml.
• Не сломаны ли абсолютные ссылки и пути к файлам.
• Не выросло ли время ответа сервера.

Если сайт на CMS, отдельно проверьте админку, обновление кэша, работу модулей оплаты, работу интеграций и импорт/экспорт данных. Не поленитесь прогнать тестовый заказ с оплатой, если это возможно.

Частые ошибки при переносе сайта

1. Не снизили TTL заранее

Из-за этого часть трафика ещё долго идёт на старый сервер. Если старый выключен, пользователи видят ошибку, а вы — потерянные заявки.

2. Перенесли файлы, но забыли базу

Результат — пустые страницы, старый контент или неработающий личный кабинет. База — это мозг сайта, а не просто таблицы.

3. Не проверили версии PHP и расширения

Сайт может упасть из-за несовместимости даже при идеальной копии файлов. Например, модуль, работавший на PHP 7.4, откажется запускаться на PHP 8.2.

4. Не учли cron-задачи

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

5. Сломали почту

Неверные MX, SPF или SMTP — и сайт вроде работает, но заявки не доходят. Проверяйте почтовые записи отдельно, даже если кажется, что «всё осталось как было».

6. Отключили старый хостинг слишком рано

DNS-кэш у провайдеров живёт дольше, чем кажется. Даже при TTL 300 секунд некоторые резолверы игнорируют его и держат старый IP до суток.

7. Не проверили поиск и индексируемые страницы

После миграции могут появиться битые редиректы, дубли, 404 и просадка в SEO. Это не сразу заметно в админке, но бьёт по трафику через недели.

Как перенести сайт с минимальным риском для SEO

Если проект уже индексируется, важно не только не уронить доступность, но и сохранить структуру. Поисковики плохо реагируют на резкие изменения URL и массовые 404.

Что обязательно сохранить

• URL-структуру.
• Мета-теги, если они генерируются динамически.
• 301-редиректы.
• Canonical.
• Карту сайта.
• robots.txt.
• HTTPS-версию без смешанного контента.
• Код ответа страниц.

Что проверять в первую очередь

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

Когда нужен нулевой простой в буквальном смысле

Иногда «почти без простоя» недостаточно. Это касается магазинов с высокой дневной выручкой, систем бронирования, сервисов с круглосуточной загрузкой и проектов с постоянными транзакциями. Там даже минута недоступности — это реальные деньги.

В таких случаях используют более сложную схему: синхронизация данных в реальном времени, репликация базы, временный режим только на чтение, балансировка между площадками и постепенный cutover через CDN или reverse proxy. Для небольшого сайта такая архитектура избыточна, но для бизнес-критичного сервиса — нормальная практика. Например, можно поднять реплику базы на новом сервере, переключить запись на неё, а потом уже переносить приложение.

Короткий практический вывод

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

FAQ

Сколько времени занимает перенос сайта без простоя?

От нескольких часов до нескольких дней, в зависимости от объёма данных, количества интеграций и времени распространения DNS. Подготовка обычно занимает больше времени, чем сам перенос.

Можно ли перенести сайт ночью и не рисковать?

Да, но только если подготовка сделана заранее. Ночь удобна для финального переключения, но не заменяет тестирование на новом сервере и предварительное снижение TTL.

Нужно ли менять домен при переезде на новый хостинг?

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

Что важнее — файлы или база данных?

Для большинства сайтов важнее база данных. Именно в ней лежат заказы, пользователи, контент и настройки. Файлы можно восстановить из резервной копии, а потерянные записи — нет.

Можно ли просто скачать бэкап и восстановить его у нового хостера?

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

Когда можно выключать старый хостинг?

Только после того, как убедитесь, что DNS распространился, сайт стабильно открывается на новом сервере, а почта и формы работают без сбоев. Обычно старый сервер держат включённым 1–3 дня, чтобы переждать кэш у провайдеров и отловить отложенные проблемы.