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

Почему после красивого редизайна сайт может потерять трафик

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

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

Шаг 1. Зафиксировать исходную точку до первого макета

Соберите снимок текущего сайта минимум за сопоставимый период: URL из sitemap и обхода сайта, страницы входа из аналитики, показы и клики из поисковых консолей, конверсии, внешние ссылки, метатеги, canonical, статус индексации и коды ответа. Для сезонного бизнеса сравнивайте не только последние недели, но и аналогичный период прошлого года.

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

• выгрузка всех доступных URL и их кодов ответа;
• органические входы, запросы, клики и целевые действия по странице;
• внешние и важные внутренние ссылки;
• title, description, H1, canonical, robots и структурированные данные;
• скорость, мобильные ошибки и текущие значения Core Web Vitals;
• события форм, звонков, корзины, оплаты и других бизнес-конверсий.

Шаг 2. Сделать карту URL и контента

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

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

Шаг 3. Проектировать дизайн вокруг спроса и сценариев

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

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

Шаг 4. Подготовить технический контур до переключения

На тестовой среде проверьте коды ответа, canonical, hreflang для языковых версий, robots, sitemap, микроразметку, внутренние ссылки и правила редиректов. Все формы должны создавать реальное тестовое обращение и передавать источник в аналитику или CRM. Счётчики, consent-механика и рекламные пиксели сверяются по согласованной карте событий.

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

• таблица 301-редиректов проверена автоматически и вручную на ключевых страницах;
• в sitemap входят только канонические индексируемые URL;
• тестовые запреты noindex и блокировки robots не попадут в production;
• формы, телефоны, почта, корзина и оплата проверены на реальных устройствах;
• аналитика различает просмотр, начало формы, успешную отправку и ошибку;
• есть резервная копия, план отката и окно запуска с низким риском.

Шаг 5. Запускать по чек-листу, а не по ощущению готовности

В момент запуска команда повторно проверяет доменные варианты, HTTPS, основные шаблоны, редиректы, robots.txt и sitemap. Если меняется домен, Google рекомендует использовать Change of Address в Search Console после настройки перенаправлений. Для множества изменённых страниц новый sitemap помогает поисковой системе обнаружить адреса, но сам по себе не гарантирует индексацию.

Сразу после переключения пройдите путь клиента от входной страницы до заявки, включая письмо или запись в CRM. Визуальное совпадение с макетом — только один критерий. Главный сигнал запуска: человек может найти ответ, выполнить действие, а команда видит результат в данных.

Что контролировать первые четыре недели

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

Core Web Vitals измеряют реальный опыт загрузки, отзывчивости и визуальной стабильности. Google указывает ориентиры LCP до 2,5 секунды, INP менее 200 мс и CLS менее 0,1 для хорошего опыта. Но техническая скорость не заменяет бизнес-проверку: быстрый экран с неработающей формой всё равно провалит запуск.

Как связать редизайн с продуктом, а не только с оболочкой

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

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

Итоговый чек-лист владельца сайта

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

• зафиксированы трафик, запросы, конверсии и техническое состояние до изменений;
• для каждого старого URL принято и проверено решение;
• ценный контент сохранён или улучшен, а не заменён декором;
• аналитика и CRM проверены сквозным тестовым обращением;
• редиректы, canonical, robots, sitemap и языковые версии прошли контроль;
• назначены даты ежедневного и еженедельного мониторинга после запуска.