Как переехать со старого сайта на новый и снизить риск потери трафика, заявок и данных

Новый сайт часто принимают по главной странице: дизайн нравится, кнопки нажимаются, каталог открывается. Затем старые адреса пропадают из поиска, рекламные кампании ведут в никуда, форма не отправляет заявку в CRM, а поддержка узнаёт о проблеме из звонка клиента.

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

Новый сайт готов не тогда, когда открывается главная, а когда воспроизводит критичные сценарии старого контура.

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

Соберите единый реестр. В него должны попасть:

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

Для каждой значимой старой страницы нужно решить судьбу: она переносится на новый URL, получает ближайший релевантный эквивалент, объединяется с другой страницей или осознанно снимается.

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

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

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

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

Попросите пройти с представителями маркетинга, продаж и операций:

Контрольная заявка должна пройти весь путь. Открытая форма ещё не доказывает, что данные дошли в CRM, назначились ответственному и не потеряли источник. Проверяйте timestamp, идентификатор, поля, UTM, статус и уведомление, а не только экран «спасибо».

Хороший план релиза делит работу на короткие проверяемые окна. До переключения команда подтверждает готовность по реестру. В момент переключения не добавляет «заодно» новый контент, новый рекламный кабинет и непроверенное расширение. После переключения сначала проходит smoke test критичных сценариев, затем открывает трафик и только после этого занимается второстепенными правками.

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

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

После релиза назначьте ритм, а не бесконечное наблюдение. В день запуска — критичные сценарии и ошибки. В конце первой недели — 404, редиректы, индексация, рекламные посадочные, события и CRM. В конце первого месяца — сравнение с baseline по трафику, заявкам и качеству обращений с поправкой на сезонность и цикл сделки.

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

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

Проверьте DNS и сертификат, robots.txt, правила индексации, canonical, sitemap, HTTP-ответы, редиректы, аналитику, цели, формы и интеграции. Убедитесь, что старый контур не выключают до момента, когда есть доступ к резервной копии, реестру URL и возможности отката.

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

Релиз без владельцев и триггеров отката — это не быстрый запуск, а перенос риска на клиентов и отдел продаж.

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

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

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

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

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

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

Цели аналитики должны соответствовать бизнес-событию. Нажатие кнопки, успешная отправка формы, создание обращения в CRM и квалифицированный лид — разные события. В migration register укажите прежнее определение, новое определение, место срабатывания, идентификатор и способ сверки. Если определение меняется, отчёт после запуска должен отмечать разрыв ряда, а не рисовать иллюзию улучшения или падения.

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

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

Сравните выборку ключевых страниц старого и нового сайта: адрес, код ответа, canonical, заголовок, robots, метаданные, основной контент, изображения и внутренние ссылки. Для каталога отдельно проверяют карточки, категории, фильтры и страницы без товара; для контентного сайта — статьи, архивы и документы. Цель не в том, чтобы законсервировать старые ошибки, а в том, чтобы осознанно отличить улучшение от непреднамеренной потери.

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

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

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

Перед запуском запросите:

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

Заказчику полезно связать этапы с артефактами: до разработки — утверждённый реестр; перед релизом — подписанные результаты приёмки; после запуска — журнал проверок и список открытых рисков. Это даёт основание обсуждать готовность предметно, а не по ощущению «вроде всё сделали».

Разделите не только работу, но и приёмку. SEO-специалист подтверждает карту важных URL и поисковые сигналы, разработчик — технические ответы и интеграции, маркетинг — цели и посадочные, продажи — доставку контрольных лидов, владелец проекта — общее решение go/no-go. Никто из них не видит весь риск в одиночку.

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

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

Если часть проверок не прошла, не прячьте её в список «после запуска». Укажите влияние, владельца, срок и решение: блокирует ли это переключение, допускается ли временная мера или нужен откат. Так риск остаётся управляемым.

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

Проверку целей и событий удобнее вести по логике, описанной в Яндекс Метрике; выбор технологической основы до переезда разбирается в статье «CMS или собственная разработка».