Сайт уже открывается на новом сервере, но часть посетителей ещё попадает на старый. За это время там появилась заявка. Куда она попадёт после окончательного переключения? Именно такие детали отличают полноценную миграцию от простого копирования файлов.
В Гуси-Лебеди предлагаем разбирать переезд через понятные контрольные точки: что меняется, какие данные нужно сохранить, куда ведут старые ссылки и по каким признакам можно разрешить запуск. Ниже собрали последовательный план переноса сайта на другой хостинг, домен или CMS и проверки результата.
Что такое миграция сайта и что именно вы переносите
Миграция сайта означает изменение площадки, системы управления, домена или структуры адресов. Эти задачи могут сочетаться, но у каждой свои риски. При смене сервера нужно проверить среду и данные. При смене CMS добавляется перенос функций и модели содержания. Новый домен требует отдельной работы с адресами и поисковыми кабинетами.
| Изменение | Что проверить | Что не обязательно менять |
|---|---|---|
| Другой хостинг, прежние URL | Версии среды, файлы, базу, DNS, сертификаты и интеграции | Домен и адреса страниц |
| Другая CMS | Содержание, поля, шаблоны, права, функции и маршруты | Домен, если его смена не нужна |
| Другой домен | Соответствие страниц, перенаправления и оформление переезда в поиске | Дизайн и CMS |
| Другая структура URL | Карту адресов, внутренние ссылки и конечные страницы | Сервер |
Не объединяйте изменения автоматически. Если одновременно поменять домен, тексты, каталог и дизайн, найти источник проблемы станет сложнее. Когда общий запуск необходим, выделите отдельные проверки каждой части и сохраните исходное состояние.
До выбора инструмента переноса зафиксируйте состав работ и ответственных. Кто принимает решение о переключении? Кто проверяет заказы и заявки? Кто управляет DNS, поисковыми кабинетами и CRM? Доступы должны работать до начала переезда. Пароль, который оказался у бывшего подрядчика, способен остановить запуск даже при готовой новой версии.
Согласуйте допустимую паузу в работе и допустимую потерю данных. Это разные условия. Можно разрешить короткую остановку оформления заказа, но потребовать сохранения всех уже подтверждённых покупок. Срок и стоимость рассчитывайте по этому составу задач, объёму данных, сложности функций и длительности проверок. Универсальная цена за «перенос сайта» скрывает слишком разные работы.
Как собрать карту адресов и сохранить полезные страницы
Начните с перечня старых URL. Соберите его из CMS, Sitemap, обхода сайта, аналитики, поисковых кабинетов и журналов сервера. Меню не содержит весь проект: за его пределами могут остаться посадочные страницы, документы, изображения и материалы с внешними ссылками.
Для каждого важного адреса сохраните статус ответа, заголовок, содержание, canonical и ограничения индексирования. Отметьте страницы, которые приводят обращения, получают поисковые входы или нужны по действующим ссылкам. Приоритет должен опираться на данные вашего сайта.
Каждому изменяемому адресу назначьте решение: сохранить, перенаправить на соответствующую страницу, объединить с подходящим материалом или удалить без замены. Например, старую страницу аудита направляют на новую страницу аудита, а завершённую акцию без аналога не нужно выдавать за действующее предложение.
Редирект на главную для всех старых URL лишает посетителя нужного содержания. Проверяйте всю цепочку переходов и конечный ответ. В разборе 301-редиректов отдельно объясняем, как найти лишние переходы и ошибочные назначения.
У поисковиков есть различия в инструкциях. При одновременной смене домена и названий каталогов Яндекс описывает промежуточный переход через прежний путь на новом домене. Поэтому настройку сверяют с инструкцией Яндекса по переезду, а не с универсальным правилом для любого случая. Для смены путей внутри одного домена избегайте ненужных цепочек.
Обновите собственные ссылки, Sitemap и адреса ресурсов. Для Google у новых страниц проверяют canonical на актуальный URL; соответствующие рекомендации приведены в руководстве по миграции со сменой адресов. При языковых версиях также проверьте hreflang. Не переносите на рабочий сайт ссылки на тестовый домен.
Как перенести базу, файлы и изменения во время переезда
Состав копии шире каталога с кодом. Нужны база, загрузки пользователей, настройки приложения и сведения для восстановления среды. Отдельно учитывайте очереди, фоновые задания, почту, поиск, CRM и платёжные уведомления. Проверьте восстановление копии на отдельной площадке до переключения.
Для переноса WordPress, Битрикс и другой CMS выбирайте способ, совместимый с конкретной версией, объёмом данных и условиями лицензии. Плагин или встроенный архив может помочь с техническим копированием, но не подтверждает работоспособность форм, прав и интеграций. Особенности копий разбираем в статье о резервировании и тестовом восстановлении.
Главный вопрос: что произойдёт с записями, появившимися после первой копии? Пока старый сайт принимает обращения, его база продолжает изменяться. Копия недельной давности не содержит сегодняшних заявок, даже если изображения и главная страница выглядят правильно.
Выберите и опишите способ финальной синхронизации. Для небольшого проекта это может быть согласованная пауза записи и заключительный перенос. Для непрерывной работы потребуется подходящий механизм репликации или переноса изменений с проверкой конфликтов. Не предполагается, что один способ подходит любой базе.
Составьте перечень источников записи: посетители, менеджеры, CRM, платёжный сервис, очереди и задания по расписанию. Остановка формы не останавливает остальные источники. Укажите, кто принимает позднее уведомление об оплате и где оно будет обработано после запуска.
В учебном сценарии первая копия сделана в 10:00, а переключение назначено на 12:00. Все операции между этими моментами должны попасть на новую сторону. Сверка количества записей полезна, но её недостаточно: сравните идентификаторы, статусы и содержимое важных операций. Две базы могут содержать одинаковое число заказов и разные заказы.
Как проверить новую площадку до открытия для посетителей
Запустите репетицию на отдельной площадке. Проверьте версии языка и СУБД, расширения, права на файлы, кодировку, конфигурацию, загрузки и фоновые процессы. Затем пройдите реальные пользовательские сценарии, которые важны вашему бизнесу.
Тестовую копию защитите от случайного доступа и реальных внешних действий. Она не должна списывать деньги, отправлять клиентам письма или создавать настоящие сделки. Используйте предусмотренные сервисами тестовые режимы и отдельные подключения. Закрытый доступ надёжнее одного запрета индексирования для защиты самой тестовой среды.
| Сценарий | Что подтвердить | Ошибка, блокирующая запуск |
|---|---|---|
| Форма обращения | Запись сохранена, нужная система её получила | Есть «Спасибо», но обращения нет |
| Оформление заказа | Товары, стоимость и статус соответствуют операции | Потеря заказа или повторная обработка оплаты |
| Вход пользователя | Работают доступ и предусмотренные права | Чужие данные доступны другому пользователю |
| Важная страница | Ожидаемые содержание, URL и статус ответа | Ошибка вместо страницы или неверное назначение редиректа |
| Фоновое задание | Выполнено один раз в нужной среде | Дубли уведомлений или необработанная очередь |
Для заявки задайте контрольный идентификатор и найдите его в принимающей системе. Успешная отправка браузером не доказывает доставку в CRM. Проверка должна доходить до согласованного результата, включая подтверждение внешней стороны.
Отдельно подготовьте настройки публикации. На рабочей версии не должны остаться случайный noindex, запрет обхода, canonical на тестовую копию и недоступные ресурсы. Удалять ограничения нужно по плану запуска, сохраняя закрытые служебные разделы. Запишите замечания, результат повторной проверки и человека, который разрешил переход к переключению.
Как переключить DNS, сертификаты и обработку заявок
Перед запуском выполните финальную синхронизацию по согласованному плану. Определите площадку, которая принимает новые записи, и отключите дублирующие обработчики. Если инфраструктура требует сборки, окружений и управления выпуском, включите это в подготовку DevOps для переезда.
Проверьте A и AAAA, основное имя и www, сертификаты нужных хостов. Если меняете NS, перенесите необходимую DNS-зону целиком, включая почтовые MX и связанные TXT. Перенос веб-приложения не должен случайно изменить маршрутизацию почты.
DNS меняется не одновременно у всех посетителей. Уменьшение TTL заранее помогает управлять сроком кэширования, но не стирает ответы, которые уже сохранены. На переходный период опишите обслуживание старой площадки и обработку запросов к ней.
Не выключайте прежний сервер сразу после удачного открытия сайта у одного специалиста. Смотрите обращения к обеим площадкам и проверяйте, не продолжаются ли записи на старой стороне. При смене домена старое имя должно принимать HTTPS-соединение, чтобы браузер смог получить перенаправление.
При сохранении URL перенос хостинга отличается от переезда на другой домен. Google описывает эту ситуацию в инструкции по смене инфраструктуры. Не создавайте редиректы на другой адрес, если адрес страницы остаётся прежним.
После переключения повторите контрольные сценарии уже на публичном сайте. Убедитесь, что проверяется нужная площадка, а не старая копия из кэша. Проверьте содержание, изображения, форму, уведомления, запись в CRM и счётчик. Для каждого пункта сохраните результат, а не только отметку «посмотрели».
Как подготовить откат и принять миграцию
Возврат DNS не возвращает данные к прежнему состоянию. Если новая площадка уже приняла заказ, переключение на вчерашнюю базу может его потерять. Поэтому план отката должен различать возврат до открытия записи и возврат после появления новых операций.
До открытия записи можно вернуться на проверенную старую систему по подготовленному сценарию. После открытия сначала сохраните новые операции, при необходимости ограничьте приём, перенесите разницу и проверьте результат. Для сложной системы исправление текущей версии иногда предпочтительнее обратного переноса, но решение зависит от характера сбоя.
Определите признаки, при которых запуск останавливается: потеря обращений, некорректная оплата, нарушение доступа, недоступность критичных страниц. Назначьте человека, который принимает решение, и сохраните пошаговую инструкцию. Колебание поисковых позиций само по себе не объясняет техническую неисправность.
При смене домена оформите применимый переезд в поисковых кабинетах и следите за обходом и индексированием. Отправка заявки не означает, что обработка завершена. Яндекс прямо предупреждает, что сохранение позиций и посещаемости не гарантируется. Поэтому обещание «переезд без потери SEO» не заменяет проверяемый план.
После запуска сравнивайте сопоставимые группы страниц и периоды: услуги, категории, статьи, документы. Смотрите ошибки, поисковые входы и обращения. Общая посещаемость может скрыть проблему отдельного раздела. Для технических сценариев подключите проверки доступности и передачи заявок.
Принимайте результат по комплекту: карта URL, проверенное восстановление, сверка данных, отчёт по сценариям, настройки переезда и план реакции на сбой. Старую среду отключайте после согласованной проверки перехода. Если после запуска требуется сопровождение, заранее включите наблюдение за ошибками и исправления в поддержку перенесённого сайта.
Хорошая миграция заканчивается понятным состоянием проекта: известны рабочая площадка, судьба старых адресов, место хранения копий и порядок восстановления. Такой результат можно проверить и передать другой команде.