Перенос сайта чаще всего планируют с мыслью “ну это же просто: скопировать файлы и базу”. Формально — да. На практике переезд ломается не на файлах. Он ломается на мелочах, которые всплывают в самый неудобный момент: письма перестают уходить, часть страниц отдаёт 404, сертификат не обновился, формы отправки не работают, а в админку внезапно не пускает из-за сессий или кеша.
Если сайт связан с бизнесом — переезд лучше делать как мини-проект: с подготовкой, контрольными точками и планом отката. Без фанатизма, но с дисциплиной. Ниже — рабочая схема, которая подходит и для небольших сайтов, и для магазинов, и для проектов с интеграциями.
Сначала определите тип переезда: “только хостинг” или “хостинг + домен + почта”
Есть три частых сценария:
- Вы меняете только сервер/хостинг, домен остаётся у того же регистратора, DNS там же.
- Вы меняете хостинг и DNS (например, переносите управление зонами на новую площадку).
- Вы переносите всё вместе: сайт, DNS, домен, почту, иногда ещё и CDN.
Самый спокойный вариант — когда вы сначала переносите сайт на новый хостинг, а DNS трогаете в самом конце. Сначала всё проверили — потом переключили трафик.
Шаг 1. Соберите “карту сайта”: что у вас вообще есть
Это звучит скучно, но это экономит часы.
- CMS и версия (WordPress, OpenCart, Joomla, самопис)
- версия PHP и важные расширения
- база данных (MySQL/MariaDB), размер базы
- крон-задачи (cron) — что запускается и как часто
- внешние интеграции: платежи, CRM, отправка писем, API, вебхуки
- куда уходят письма (SMTP, локальная отправка, сторонний сервис)
- где живут DNS-записи и кто ими управляет
Если вы видите список и вам кажется, что “ну у меня же простой сайт”, вы уже на правильном пути. Проблемы возникают, когда половину пунктов не помнят до момента сбоя.
Шаг 2. Снизьте риск: обновления и изменения — стоп за 24–48 часов до переезда
Самый частый саботаж миграции — “мы заодно обновим плагины/тему/движок”. Не надо. Переезд и обновление — это две разные операции, каждая со своими рисками.
Перед переносом лучше:
- временно заморозить изменения на сайте
- не ставить новые плагины/модули
- не менять структуру URL и редиректы
Если вы переносите магазин, подготовьте окно, когда можно остановить оформление заказов на короткое время (или хотя бы аккуратно отследить “последний заказ до переключения”).
Шаг 3. Сделайте резервные копии так, чтобы они реально спасли
Обычно говорят “сделайте бэкап”, и все кивают. Важно, чтобы он был полезным. Лучше сделать два набора:
- Файлы сайта (включая скрытые файлы, .htaccess, конфиги, .env, uploads)
- База данных отдельным дампом
Если сайт большой, проверьте, что архив скачался полностью и открывается. Звучит смешно, но “архив побился” — классика.
Ещё одна полезная привычка: сохранить список DNS-записей и текущих настроек почты (SPF/DKIM/DMARC). Это пригодится, если во время переноса вы случайно заденете зону.
Шаг 4. Подготовьте новое окружение “в один уровень” с текущим
Часть проблем возникает из-за несовпадений версии PHP, настроек сервера и модулей. Простой принцип: на новом хостинге сначала повторите среду максимально похоже, а потом уже улучшайте.
Проверьте заранее:
- версию PHP (и совместимость с вашей CMS)
- лимиты памяти и времени выполнения (memory_limit, max_execution_time)
- расширения, которые использует проект (curl, mbstring, gd/imagick, intl и т.п.)
- настройки загрузки файлов (upload_max_filesize, post_max_size)
Если вы переносите “самопис”, проверьте, нет ли жёстко прописанных путей, привязки к конкретной структуре каталогов или к версии сервера.
Шаг 5. Делайте тестовый запуск без смены DNS
Это ключ к спокойному переезду: вы должны увидеть, как сайт работает на новой площадке, ещё до того, как туда придут реальные пользователи.
Как это сделать без сложной магии:
- поднимите сайт на временном домене/поддомене
- или используйте hosts-файл у себя на компьютере (чтобы домен открывался на новом IP только у вас)
Дальше — проверка по чек-листу:
- главная, несколько внутренних страниц, поиск
- формы обратной связи (и что приходит на почту)
- вход в админку, сохранение настроек
- загрузка изображений/файлов
- корзина и оформление заказа (если это магазин)
- оплата в тестовом режиме (если можно)
- крон-задачи: запускаются ли, нет ли ошибок
Если на этом этапе вы ловите ошибки — отлично. Вы поймали их без потерь.
Шаг 6. Почта — отдельная зона риска
Перенос сайта часто случайно ломает письма. Причины бывают разные: смена IP, блокировка исходящей почты, неправильные DNS-записи, смена SMTP-настроек, ограничения на порты.
Перед переключением проверьте:
- как сайт отправляет письма (PHP mail, SMTP, внешний сервис)
- не завязана ли отправка на конкретный IP или доменную зону
- остались ли корректными SPF/DKIM/DMARC, если вы меняете DNS
Если письма важны (заказы, регистрации), удобнее сразу настроить отправку через SMTP или специализированный сервис. Тогда смена хостинга меньше влияет на доставку.
Шаг 7. SSL: не оставляйте на “после, когда переключим”
Сертификат лучше подготовить заранее. Если вы тестируете сайт на новом окружении по временному домену — там может быть отдельный сертификат. А для основного домена проверьте, что после переключения вы сможете быстро включить HTTPS без ручных приключений.
Что проверять:
- автоматическое получение/продление сертификата
- редирект HTTP → HTTPS
- смешанный контент (если картинки/скрипты тянутся по http)
Если HTTPS настроен криво, браузер может отпугнуть часть клиентов ещё до того, как сайт загрузится.
Шаг 8. DNS-переключение: уменьшите время “плавающих” запросов
Главная причина хаоса при переносе — когда часть пользователей попадает на старый сервер, часть — на новый. Это происходит из-за кеширования DNS. Полностью избежать нельзя, но можно сильно сократить окно.
Что помогает:
- за 24–48 часов до переключения снизить TTL у A/AAAA-записей (например, до 300 секунд)
- переключать домен в спокойное время (ночь/утро по вашей аудитории)
- если есть личные кабинеты/заказы — предусмотреть “режим обслуживания” на короткое время
Если проект принимает заказы, лучше на момент переключения остановить приём новых заказов на 15–30 минут, чем потом разбирать ситуацию “половина заказов улетела на старую базу”.
Шаг 9. План отката: держите “кнопку назад”
Откат — это не поражение. Это страховка.
Минимальный план отката выглядит так:
- старый хостинг не отключаете минимум 3–7 дней
- храните бэкап и дамп базы отдельно
- фиксируете, какие записи DNS меняли и какие были до
Если после переключения вы увидели критическую проблему, вы должны суметь быстро вернуться на старую площадку, а не “пытаться починить в продакшене”.
Шаг 10. Контроль после переноса: 24 часа наблюдения
Когда домен уже показывает на новый сервер, многие выдыхают и уходят спать. А потом утром прилетает: “не работает форма”, “оплата не проходит”, “в админке ошибки”.
Что лучше сделать сразу после переключения и в течение суток:
- проверить логи ошибок (PHP, веб-сервера)
- отследить отправку писем с сайта
- проверить оплату/вебхуки (если есть)
- проверить скорость и время ответа страниц
- убедиться, что бэкапы на новом хостинге включены
Это не “паранойя”. Это нормальная техника безопасности для любой миграции.
Когда проще привлечь помощь
Если проект связан с продажами, имеет личные кабинеты, интеграции, очередь задач, или вы просто не хотите рисковать — разумно попросить провайдера помочь с переносом. Хорошие команды делают миграции регулярно и знают типовые ловушки. На рынке часто встречается практика, когда провайдер помогает с переносом в рамках сервиса или за небольшую доплату. Иногда в этом контексте упоминают UkrLine — как вариант площадки, где миграции и сопровождение обсуждают нормально, а не “делайте сами”. Но в любом случае критерий простой: вам нужен понятный план и ответственность за результат.
Перенос сайта не обязан превращаться в стресс. Если вы заранее подготовите бэкапы, повторите окружение, протестируете на новом сервере до смены DNS и продумайте откат — вы пройдёте миграцию спокойно и без потерь.