Как перенести сайт на другой хостинг и сохранить работу почты

Разделите сайт, домен, DNS и почту

Регистратор хранит сведения об управлении доменом. DNS указывает, куда направляются обращения к разным именам. Хостинг обслуживает сайт. Почтовый провайдер принимает и хранит письма. Эти услуги могут находиться у разных компаний, даже если оплачивались одним счётом.

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

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

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

Подготовьте доступы и независимую копию

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

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

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

Сохраните исходные DNS-записи и значения TTL. Если планируете снизить TTL, сделайте это заранее: уже закешированные ответы сохраняют прежний срок. Заранее подготовленный план уменьшает задержку переключения, но не гарантирует одновременное обновление всех сетей.

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

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

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

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

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

Для WordPress изменение адресов требует аккуратности. Простая замена текста по всей базе может повредить сериализованные значения плагинов. При сохранении домена сначала выясните, требуется ли вообще изменение адресов. При работе с тестовым доменом используйте подходящий для CMS способ и сохраните исходную копию.

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

Пройдите рабочие сценарии

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

1. Посетитель. Главная, категории, карточки, поиск, фильтры, изображения, документы, мобильное меню.
2. Заявка. Отправка формы, загрузка файла, подтверждение, запись в базе и получение уведомления.
3. Клиент. Вход, восстановление доступа, история заказов, корзина и личные данные.
4. Покупка. Оформление в согласованном тестовом режиме, обработка обратного уведомления и отсутствие дублей.
5. Сотрудник. Изменение записи, загрузка медиа, импорт и выгрузка.
6. Автоматизация. Расписание, очереди, обмен с CRM и учётной системой без записи в рабочие данные во время испытания.
7. Техническая часть. Коды ответов, редиректы, HTTPS, CSS и JS, журналы ошибок.

При сохранении URL проверьте, что важные адреса не изменились, canonical указывает на рабочий домен, а в HTML нет тестового имени. Внешние сервисы могут разрешать обращения только с прежнего IP. Такие ограничения нужно согласовать и проверить заранее.

Реальный платёж для проверки выполняют только по согласованному сценарию. Для большинства предварительных проверок используйте предусмотренный тестовый режим. Не отправляйте покупателям письма и не списывайте деньги ради быстрой проверки копии.

Выберите момент последней синхронизации

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

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

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

Переключите DNS и сохраните почтовые записи

Меняйте только согласованные записи. A указывает IPv4, AAAA указывает IPv6, CNAME задаёт другое доменное имя. Если вы обновили только A, а старая AAAA осталась, часть обращений может продолжать идти по старому адресу IPv6. Проверьте основной домен, www и нужные поддомены.

Почтовая маршрутизация использует MX, а SPF, DKIM и DMARC обычно представлены TXT-записями. При смене NS новая DNS-зона должна заранее содержать нужные записи, включая почтовые и служебные. Замена всех NS без переноса зоны способна нарушить почту, хотя файлы сайта перенесены правильно.

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

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

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

Проверьте результат и план возврата

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

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

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

Для выбора площадки используйте каталог хостинга, подборку WordPress или подборку Битрикс. Если переезжаете на свой сервер, до переноса выполните первую настройку VPS.