Как перезапустить сайт без потери SEO, трафика и заявок

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

Полностью исключить колебания поисковых показателей нельзя: решение о сканировании и ранжировании принимает поисковая система. Зато можно контролировать полноту карты URL, корректность HTTP-ответов, перенос контента, работу бизнес-сценариев и скорость обнаружения ошибок.

Соберите базовую картину до разработки

Начните с перечня старых URL. Объедините данные обхода сайта, CMS, sitemap, Яндекс Вебмастера, Метрики и, если доступны, внешних ссылок. Для каждого адреса отметьте назначение, статус, поисковые показы и клики, органический трафик, заявки, новый адрес и решение: сохранить, перенести, объединить или удалить.

Сначала зафиксируйте ценность каждого адреса и решение по нему:

Старый URL	Ценность	Решение
Страница с трафиком и лидами	высокая	сохранить или перенести один к одному
Дубль	низкая	объединить
Устаревшая услуга	зависит от спроса	заменить релевантным разделом или удалить
Технический URL	отсутствует	исключить

Затем отдельно задайте целевой адрес и способ контроля:

Старый URL	Новый URL	Контроль
Страница с трафиком и лидами	конкретная релевантная страница	200 или один 301
Дубль	канонический аналог	301 и обновлённые ссылки
Устаревшая услуга	только смысловой аналог	301 либо честный 404/410
Технический URL	нет	корректный статус и отсутствие в ссылках

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

Подготовьте SEO-карту миграции

Яндекс рекомендует при изменении структуры настраивать 301-редирект со старого адреса на новый. Редирект на главную вместо релевантной страницы не сохраняет смысл запроса. Для каждого важного URL нужна постраничная связь.

Проверьте до запуска:

title, description, H1 и основной контент ключевых страниц;
внутренние ссылки и хлебные крошки;
rel="canonical" на production-адрес;
robots.txt, мета-robots и отсутствие случайного noindex;
production sitemap без тестовых URL;
структурированные данные, если они использовались;
доступность основного контента роботу, особенно на JS-интерфейсах;
единый протокол, домен, слеши и регистр URL.

Canonical не заменяет редирект. В документации Яндекса он описан как рекомендация, которую робот может не принять: правила канонического адреса. Sitemap также не гарантирует индексацию — он сообщает поисковой системе актуальную структуру: требования к Sitemap.

Перенесите аналитику и заявки как отдельный контур

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

Проведите end-to-end тесты на production-конфигурации:

Визит приходит с тестовыми UTM и yclid, если сценарий рекламный.
Метрика создаёт и передаёт ClientID.
Форма показывает успех только после фактического принятия данных.
CRM создаёт одну запись с источником и посадочной страницей.
Уведомление получает нужный сотрудник.
Звонок связан с визитом, если используется коллтрекинг.
Статус сделки или оплаты можно вернуть в аналитику.

Яндекс описывает передачу ClientID в CRM и связывание заказов с визитами в разделе о загрузке CRM-данных. Если эта связка сложная, сначала спроектируйте её отдельно: какие поля и идентификаторы нужны от сайта до продажи.

Зафиксируйте критерии допуска к запуску

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

Поиск

Ключевые URL отвечают 200, карта редиректов проходит тест, запреты индексации сняты, canonical и sitemap указывают на production.

Продажи

Формы и звонки проходят до CRM, источники сохраняются, дубли контролируются, уведомления доставляются.

Эксплуатация

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

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

Что проверить в момент переключения

Сразу после публикации пройдите по приоритетному списку, не по случайным страницам:

главная и основные посадочные отвечают 200;
старые важные URL дают один постоянный редирект на правильную цель;
на страницах нет тестового noindex и canonical на staging;
sitemap доступен и содержит production-адреса;
CSS, JavaScript, изображения и шрифты загружаются без системных ошибок;
формы и звонки создают реальные тестовые лиды;
счётчик аналитики работает на всех основных шаблонах;
мобильный сценарий позволяет выполнить ключевое действие;
журнал сервера не показывает массовые 4xx/5xx.

Яндекс различает постоянные 301/308 и временные 302/303/307 перенаправления: обработка редиректов роботом. Для постоянного переноса адреса используйте постоянный код.

Наблюдайте после запуска по группам URL

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

В первые дни проверяйте серверные ошибки, работу заявок и обнаруженные редиректы. По мере переобхода — статус важных страниц, показы, клики, CTR и позиции. В Яндекс Вебмастере можно добавить URL в мониторинг важных страниц и проверить ответ сервера для робота.

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

Когда нужен откат

Rollback нужен, если новая версия создала системную проблему, которую безопаснее убрать возвратом известной рабочей версии: массовые 5xx, глобальный запрет индексации, отсутствие ключевого контента, недоступные формы или критическая ошибка интеграций. Решение должно учитывать, что откат сам может снова изменить URL и данные.

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

Рабочий результат миграции

К запуску должны быть готовы: полный URL inventory, redirect map, таблица метаданных, проверенные правила robots/canonical/sitemap, карта аналитических событий, end-to-end тест заявок, список блокеров, мониторинг и план отката. Только вместе они защищают поисковый и коммерческий контур.

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

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