Переезд сайта на новый хостинг без потерь

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

Зачем вообще переезжать и когда это оправдано

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

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

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

Инвентаризация: что на самом деле живёт на старом сервере

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

• Почта на домене. Ящики, пересылки, автоответчики, архивы писем. Если почта живёт на том же хостинге, её переезд — отдельная задача.
• Задания по расписанию (cron). Выгрузки товаров, обновление курсов, рассылки, очистка кэша. Их часто никто не помнит, пока они не перестанут работать.
• Поддомены и дополнительные сайты. Тестовая копия, старый промо-сайт, личный кабинет на отдельном поддомене.
• SSL-сертификаты и способ их продления.
• DNS-записи: не только A-запись сайта, но и MX, SPF, DKIM, TXT для подтверждения прав в «Вебмастере» и других сервисах.
• Настройки веб-сервера: перенаправления, правила в .htaccess или конфигурации nginx, ограничения доступа по IP.
• Интеграции, которые обращаются к сайту по IP-адресу: учётная система, платёжный шлюз, служба доставки, CRM.
• Версии ПО: PHP, база данных, расширения. Сайт, написанный под старую версию, может не запуститься на новой.

Подготовка нового сервера

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

1. Выберите тариф с запасом по ресурсам: при первом запуске кэш пуст, и нагрузка выше обычной.
2. Установите те же версии PHP и базы данных, что на старом сервере, и те же расширения.
3. Настройте резервное копирование сразу, а не «потом». Копии должны храниться вне основного сервера.
4. Заранее выпустите SSL-сертификат или подготовьте возможность его быстрого выпуска после смены DNS.
5. Оформите доступы на компанию, а не на конкретного человека, и сохраните их в надёжном месте.

Перенос и проверка до переключения DNS

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

Что проверяем на новом сервере

• Открываются все типы страниц: главная, разделы, карточки, статьи, служебные страницы, страница ошибки 404.
• Работает поиск по сайту, фильтры и сортировка.
• Формы отправляют письма, и письма доходят, а не падают в спам.
• Оформление заказа проходит до конца, включая тестовую оплату.
• Работает административная панель: вход, редактирование, загрузка файлов.
• Изображения и документы загружаются, нет битых путей.
• Время ответа сервера не хуже, чем на старой площадке.
• В журналах ошибок нет новых предупреждений.

Финальная синхронизация

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

Переключение DNS и почта

За сутки–двое до переезда стоит уменьшить время жизни (TTL) DNS-записей, чтобы изменения разошлись быстрее. После переключения часть пользователей ещё какое-то время будет попадать на старый сервер, поэтому он должен оставаться рабочим минимум несколько дней.

Отдельная история — почта. Если корпоративные ящики живут на старом хостинге и вы его закрываете, переносите их заранее и отдельно от сайта. Мы обычно рекомендуем вынести почту на специализированный почтовый сервис: тогда последующие переезды сайта перестают её затрагивать.

Как не потерять позиции в поиске

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

• Не меняйте одновременно хостинг, структуру адресов, дизайн и систему управления. Каждое изменение по отдельности контролируемо, все вместе — нет.
• Проверьте, что файл robots.txt на новом сервере тот же, что был, а не технический с запретом индексации.
• Убедитесь, что перенаправления с www на без www (или наоборот) и с http на https работают так же.
• Следите за отчётами в «Вебмастере» и в аналогичных инструментах Google первые две недели: ошибки сканирования, резкое падение числа страниц в индексе.
• Если сервер оказался в другой стране, это почти не влияет на ранжирование, но может повлиять на скорость для пользователей.

Если переезд совпадает со сменой домена, нужен отдельный план: постраничные 301-перенаправления, указание переезда в инструментах для вебмастеров, обновление ссылок в рекламе. Это задача для специалистов по SEO-продвижению, и экономить на ней не стоит.

Первые дни после переезда

Переезд не заканчивается на смене DNS. Мы оставляем проект под усиленным наблюдением на одну-две недели.

• Ежедневно проверяем журналы ошибок сервера и приложения.
• Сверяем количество заявок и заказов с обычным уровнем: резкое падение — сигнал, что где-то сломалась форма.
• Проверяем, что выполнились все задания по расписанию и обмены с внешними системами.
• Смотрим в «Яндекс Метрике», не выросла ли доля отказов и время загрузки.
• Только после стабильной работы отключаем старый сервер, предварительно сделав с него полную архивную копию.

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

Вывод

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