Редизайн часто продают как картинку: обновим шапку, поменяем цвета, сделаем аккуратнее. На практике все шире. Меняется меню. Переезжает CMS. Переписываются тексты. Формы становятся другими. Где-то пропадает блок с ценами, где-то ломается разметка, где-то старый адрес внезапно отдает 404.
И вот тут начинается неприятная часть.
Для бизнеса в Минске и Беларуси, который получает обращения из Google и Яндекса, такой релиз нельзя делать вслепую. Если проект уже виден в поиске, у него есть история: URL, позиции, входы из органики, внешние ссылки, услуги, статьи, каталог, формы, телефоны, цели в аналитике. Это все стоит перенести без суеты.
Как не потерять SEO при редизайне? Сначала понять, что уже работает. Потом решить, что остается, что меняется и куда ведет каждый редирект. После релиза — смотреть не на ощущения, а на факты: обход, индекс, лиды, ошибки, поведение старых страниц.
Где обычно ломается трафик
Сам макет редко вредит поиску. Вредит то, что вместе с ним меняется без контроля.
Например, была посадочная услуги с нормальным описанием, отзывами, ценой, FAQ и формой. В новом дизайне ее превратили в короткий красивый экран: заголовок, три преимущества, кнопка. Визуально легче. Для пользователя — спорно. Для робота — часто беднее.
Другой сценарий: старый лендинг был в топе, а после публикации получил другой адрес. Редиректа нет. Или он ведет на главную. Человек не понимает, куда попал, робот тоже не видит точной замены.
Еще один частый случай — тестовая копия. Ее закрыли от индексации, как положено. Потом эти же запреты случайно уехали на боевой домен. Внешне все работает. Но нужные зоны выпадают из поиска.
Короче: опасен не сам редизайн, а хаос вокруг маршрутов, контента, robots.txt, canonical, скорости, мобильной версии и аналитики.
Три уровня риска
Если меняется только внешний слой, риск ниже. Пути те же, меню почти то же, контент и метатеги на месте. Все равно стоит пройтись по формам, телефону, мессенджерам, адаптиву, скорости и основным блокам.
Если меняется CMS, шаблон или логика навигации, разговор уже серьезнее. На другой платформе легко потерять title, description, H1, FAQ, хлебные крошки, микроразметку, canonical, noindex и цели. SEO при переносе проекта на новую CMS стоит планировать до верстки, а не вечером перед публикацией.
Если меняется домен или схема URL, это полноценная миграция. Тут нужна карта переноса, список старых страниц и целевых документов, 301, обновленный sitemap.xml, сверка внутренних ссылок и контроль в Google Search Console и Яндекс Вебмастере.
Что собрать до начала работ
Начните с простого списка. Не с дизайна. С фактов.
Нужны данные по органике: какие посадочные приводят людей, какие запросы дают показы, где приходят лиды и звонки, что уже занимало позиции в топ-10. Это нельзя удалять только потому, что в новой навигации хочется меньше пунктов.
Отдельно выгрузите все индексируемые документы. Источники обычные: CMS, sitemap.xml, краулер, Google Search Console, Яндекс Вебмастер, аналитика, ссылочные отчеты. Рядом удобно поставить решение: оставить как есть, перенести, объединить, закрыть, удалить.
Потом смотрите смысл. Title, description, H1, тексты, цены, отзывы, кейсы, FAQ, контакты, schema-разметка. Что помогает человеку принять решение? Что закрывает спрос? Что дает доверие? Это не всегда длинный текст. Иногда это таблица с тарифами, блок доставки, условия оплаты, примеры работ или нормальная форма.
Здесь полезен технический SEO-аудит перед редизайном: он показывает, что уже дает видимость, какие ошибки тянутся из старой версии и какие требования передать дизайнеру и разработчику.
Адреса и редиректы
URL лучше не трогать без причины. Да, иногда хочется сделать красивее. Но если старый адрес приносит трафик, лиды или ссылочный вес, спокойнее оставить его.
Когда адрес все-таки меняется, нужна карта переноса. Не абстрактная. Нормальная таблица: исходная строка, новая посадочная, статус, причина, приоритет.
Порядок такой:
- Выгрузить старые URL из всех источников.
- Отметить те, где есть трафик, лиды, позиции или внешние ссылки.
- Подобрать точную замену, а не «куда-нибудь рядом».
- Настроить 301 для постоянного переноса.
- Убрать цепочки, циклы и массовый перевод на главную.
- Прогнать правила на тестовой среде, потом еще раз после выкладки.
301 редирект при таком переносе нужен не для отчета. Он сохраняет маршрут. Категория должна вести на категорию, услуга — на услугу, статья — на близкую публикацию. Если аналога нет, лучше честно решить судьбу страницы, а не прятать проблему за главной.
Метатеги, тексты и доверие
Перенос метатегов — не копипаст ради галочки. Сначала стоит понять, почему документ получал переходы. Title мог хорошо совпадать с запросом. H1 мог точно объяснять тему. Description мог помогать клику в выдаче.
Можно переписать. Но осознанно.
С текстами та же история. При обновлении интерфейса часто хочется резать все, что «мешает воздуху». Режьте аккуратно. Описание услуги, вопросы клиентов, тарифы, отзывы, кейсы, гарантии и контакты часто работают лучше, чем еще одна красивая плашка.
Для проекта услуг это особенно заметно. Человек не просто смотрит дизайн. Он хочет понять, кто перед ним, сколько стоит работа, что входит в услугу, как связаться и можно ли доверять компании. Поэтому доверительные блоки стоит закладывать уже на этапе разработки корпоративного сайта.
Не забудьте про canonical. Он должен вести на боевой адрес, а не на тестовый домен или старую версию. Микроразметку FAQ, хлебных крошек, товара, организации и отзывов тоже стоит переносить. Визуально блок может остаться, а в коде разметки уже нет.
Навигация и внутренняя перелинковка
Раздел может существовать, но стать слабее. Просто потому, что на него больше не ведет меню, хлебные крошки, блок «похожие услуги» или ссылка из статьи.
Проверьте шапку, футер, карточки, тексты, каталог, блог. Если сильную посадочную спрятали на третий уровень, она почти всегда получает меньше веса и меньше переходов. Работа с поисковыми фразами помогает увидеть направления, которые нельзя сливать в один общий пункт.
Для интернет-магазина все жестче. Категории, карточки, фильтры, пагинация, сортировки, параметры, наличие товара, корзина, оплата, выгрузка из 1С — все это влияет на то, как каталог обходится и какие посадочные остаются полезными. При разработке интернет-магазина такие правила лучше закладывать заранее, пока каталог еще не собран на живую нитку.
Тестовая копия и индексация
Staging не должен попадать в выдачу. Закрывайте его паролем, IP-ограничением или базовой авторизацией. Просто robots.txt мало: он не всегда защищает от случайной индексации, если на тестовый домен где-то появилась ссылка.
Перед публикацией смотрите две вещи.
На тесте не должно быть мусора в индексе. На боевом домене не должно остаться тестовых запретов.
robots.txt после обновления не должен закрывать услуги, каталог, блог и другие коммерческие зоны. В meta robots и X-Robots-Tag не должно быть noindex или none там, где нужен поиск. Sitemap.xml после релиза должен содержать актуальные URL, а не смесь старого и нового.
Что сверить перед релизом
Список короткий, но скучно не будет:
- ценные страницы открываются с кодом 200 или ведут через релевантный 301;
- старые адреса не дают массовых 404;
- title, description и H1 перенесены или переписаны по смыслу;
- контент, FAQ, цены, отзывы, формы и контакты не исчезли случайно;
- canonical ведет на рабочую версию;
- sitemap.xml содержит только индексируемые документы;
- меню, хлебные крошки и внутренние ссылки работают;
- мобильная версия не беднее старой по смыслу;
- скорость не просела из-за тяжелых изображений, видео и скриптов;
- цели, телефоны, формы, email, мессенджеры, callback и квизы передают события.
Если проект еще в разработке, требования к поиску лучше передать заранее. Это относится и к разработке сайта с учетом SEO, и к доработке текущей платформы. Поля, шаблоны и правила проще заложить сразу, чем чинить их после выкладки.
Первые недели после релиза
Релиз прошел. Это не финиш.
Проверка индексации после редизайна показывает, что доступно роботам, что попало в поиск, где появились ошибки и как быстро система принимает изменения.
В Google Search Console смотрите 404, исключения, статус Sitemap, клики, показы, запросы и проблемы обхода. Если Google дает заметную долю заявок, дальнейшие работы можно сверить со страницей про продвижение сайта в Google.
В Яндекс Вебмастере смотрите сообщения, обработку Sitemap, региональность, исключения, контакты, коммерческие факторы и сниппеты. Для Беларуси это не формальность: часть аудитории ищет подрядчика именно там. Дополнительно можно посмотреть направление продвижение сайта в Яндексе.
Материал WEBCORE про проверку индексации сайта можно использовать как памятку после выкладки.
И еще проверьте аналитику. Обязательно. Иногда «просели заявки» означает не падение спроса, а сломанную отправку формы или потерянное событие в аналитике.
Если после публикации нужна не разовая сверка, а нормальная работа со структурой, контентом, сниппетами и коммерческими блоками, логично переходить к комплексному SEO-продвижению.
Просадка: нормальная или нет
После крупного перезапуска позиции могут дергаться. Роботам надо переобойти документы, обработать редиректы, обновить сигналы. Несколько дней или недель динамика бывает нервной.
Но не все можно списать на «подождем».
Нормальная турбулентность выглядит так: ценные страницы открываются, редиректы ведут на релевантные аналоги, sitemap обновлен, запреты не мешают обходу, документы постепенно возвращаются в индекс.
Плохие признаки другие: много 404, noindex на коммерческих зонах, robots.txt закрывает нужные направления, canonical ведет на тестовый домен, H1 пропали, карточки пустые, формы не отправляются. Тут ждать месяцами странно. Надо разбирать.
Если трафик уже упал
Не стоит сразу откатывать дизайн. И переписывать весь контент тоже не стоит.
Сначала диагностика:
- Зафиксируйте дату релиза и дату просадки.
- Сравните точки входа до и после публикации.
- Посмотрите старые адреса, коды ответа и редиректы.
- Сверьте robots.txt, meta robots, X-Robots-Tag и canonical.
- Проверьте title, H1, тексты, FAQ, цены, формы и контакты.
- Оцените внутренние ссылки, адаптив и скорость, включая LCP, INP и CLS.
- Убедитесь, что аналитика считает заявки, звонки и клики.
Так обычно становится понятно, почему упали позиции после релиза: потеряли маршруты, закрыли от обхода, удалили полезный контент, сломали фильтры, сбили canonical или просто перестали корректно считать лиды.
Когда подключать сопровождение
Лучший момент — до дизайна и разработки. Пока еще можно менять каркас посадочных, шаблоны, требования к CMS и аналитику.
Минимум — до публикации. Хотя бы сверить карту переноса, индексацию, метаданные, редиректы, формы и события.
SEO-сопровождение редизайна сайта особенно нужно, если проект уже получает органический трафик и заявки, меняется CMS или домен, есть каталог с фильтрами, либо новая версия уже вышла и видимость просела.
Если вы планируете перезапуск проекта, не ждите дня публикации. Оставьте ссылку на сайт — WEBCORE посмотрит текущие страницы, трафик, индексацию, архитектуру и подскажет, что сохранить, перенести или настроить, чтобы не потерять позиции и заявки.
FAQ
Можно ли сделать редизайн сайта без потери позиций?
Да, риск можно сильно снизить. Нужно сохранить сильные посадочные, подготовить редиректы, перенести метаданные и полезный контент, сверить индексацию, скорость, мобильную версию и аналитику. Но обещать нулевые колебания нельзя.
Как не потерять позиции при редизайне сайта?
Зафиксируйте точки входа, органику, запросы, внешние ссылки и конверсии. Потом проверьте целевые документы, 301, robots.txt, sitemap.xml, canonical, title, H1, контент и мониторинг после релиза.
Нужно ли сохранять старые URL?
Если старый адрес приносит переходы, заявки, ссылки или видимость, лучше оставить его. Если маршрут меняется, ставьте релевантный 301 на близкий аналог, а не общий перевод на главную.
Почему после обновления мог упасть трафик?
Часто причина простая: старые документы стали 404, редиректы не настроены, коммерческие зоны закрыты от обхода, canonical указывает не туда, контент урезали или аналитика сломалась.
Что смотреть в Google Search Console и Яндекс Вебмастере после релиза?
Статусы старых и новых документов, sitemap, ошибки обхода, исключения, клики, показы и запросы. В Яндексе еще региональность, сообщения Вебмастера и коммерческие сигналы.
Когда подключать специалиста?
До начала дизайна и разработки. Тогда еще реально изменить архитектуру, шаблоны и требования к CMS. Если проект почти готов, подключайте до публикации, а не после просадки.
