Переезд сайта на другой хостинг: как сохранить страницы, заявки и заказы

Новая площадка готова до переключения посетителей

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

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

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

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

Доступы и зависимые сервисы перечислены

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

• Домен. Компания знает, у кого зарегистрирован адрес и кто вправе менять его настройки.
• Хостинг. Доступны старое размещение, новое размещение и резервные копии.
• Приложение. Названы файлы, база, загружаемые документы и служебные задачи.
• Внешние подключения. Учтены почта, CRM, оплата, доставка и ограничения доступа, если они используются.
• Секреты. Пароли и ключи передаются защищённо, отдельно от общего списка работ.

Чужой личный аккаунт — слабое место. Компания рискует потерять управление, если единственный доступ принадлежит бывшему исполнителю.

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

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

Копия восстанавливается, а новые заказы учтены

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

• Снимок датирован. Известно, какие данные и на какой момент включены в резервную копию.
• Восстановление показано. Копия открывается, нужные записи находятся, вложения доступны.
• Последние изменения перенесены. Есть способ забрать заявки и заказы, появившиеся после первого копирования.
• Запись данных управляется. Определено, какая площадка принимает новые обращения в момент перехода.

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

Копию испытывают с теми же действиями покупателя

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

Испытания повторяют с правами покупателя. Администратор способен открыть то, что останется закрыто покупателю. Лучше пройти небольшой набор важнейших действий полностью, чем быстро просмотреть множество страниц, потому что форма может выглядеть исправной, но не сохранять обращение, а кабинет — открываться только для учётной записи исполнителя. Замечания привязывают к адресу и действию. «Всё тормозит» трудно воспроизвести, а описание загрузки конкретной карточки и перехода к оформлению даёт специалисту материал для разбора. До переключения закрывают дефекты, мешающие клиенту получить услугу или передать данные.

DNS переводит трафик постепенно

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

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

TTL — не секундомер переезда. Локальные кэши могут обновляться иначе, поэтому обещание «ровно через пять минут все увидят новый сайт» неоправданно. В Cloudflare значение Auto для проксируемых записей равно 300 секундам, но документация прямо предупреждает, что фактическое наблюдение изменения может занять больше времени. Это свойство конкретного сервиса, а не срок для любого хостинга. Исполнитель смотрит действующие значения домена и выбирает время подготовки на их основе. Старое размещение лучше держать доступным до подтверждения перехода, чем выключать сразу после изменения DNS, потому что часть покупателей ещё может обращаться к прежнему адресу сервера и получать ошибку вместо рабочего сайта.

Почта и HTTPS проверяются отдельно

Почту испытывают отдельно от открытия страниц. При переносе можно случайно изменить записи домена, которые обслуживают другой сервис. В DNS записи A и AAAA связывают имя с IP-адресами, CNAME указывает на другое имя, а MX задаёт почтовый сервер для домена. Типы описаны в справке Cloudflare. Заказчику не требуется менять их самостоятельно.

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

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

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

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

Адреса страниц и служебные ограничения сохранились правильно

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

• Список важных URL открыт. Внутренние страницы, документы и изображения доступны по прежним ссылкам.
• Служебная защита тестовой копии снята там, где нужно. Опубликованный сайт не сохраняет случайный запрет индексирования.
• Подтверждения владения перенесены. Если используется файл для Search Console, он есть в новой копии.
• Тестовая копия не стала отдельной публичной версией. Её доступ и дальнейшая судьба определены.

Забытый noindex мешает поиску. В руководстве Google снятие временных ограничений выделено как действие перед запуском.

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

Возврат учитывает то, что появилось после запуска

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

• Причины возврата названы. Критичный дефект отличается от замечания, которое можно исправить на новой площадке.
• Решение принимает конкретный человек. Известно, кто оценивает влияние ошибки на клиентов и разрешает действие.
• Новые записи сохраняются. Исполнитель объясняет, как перенесёт заказы и обращения, появившиеся после переключения.
• Повторное испытание назначено. После возврата сотрудники подтверждают работу критичных действий.

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

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

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

Когда можно завершить переезд и закрыть старый хостинг

Старую площадку отключают после подтверждения, что пользователи получают рабочий сайт с новой, а новые данные учтены. Такой порядок завершения есть в руководстве Google. Для компании к техническому наблюдению добавляется приёмка сотрудниками: заявки находятся, заказы обрабатываются, почта и внешние сервисы работают.

• Сверка закончена. Последние обращения и изменения не остались только на прежнем сервере.
• Рабочие действия повторены после переключения. Результат совпадает с тем, который принимали на копии.
• Резервное копирование включено на новой площадке. Известны место хранения и ответственный за восстановление.
• Доступы и обслуживание переданы. Компания может продолжить сопровождение без поиска прежних личных аккаунтов.
• Удаление старого размещения назначено отдельно. Сначала подтверждается завершение, потом прекращается услуга.

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

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