Редизайн — единственная работа по сайту, которая при ошибке обнуляет результат многолетнего продвижения за один вечер. При этом сам по себе новый дизайн позициям не вредит: поисковик оценивает адрес страницы, её содержимое и скорость, а не красоту макета. Вредит то, что делают заодно с дизайном — меняют адреса, перегенерируют мета по шаблону CMS, режут тексты ради «воздуха» и выкатывают релиз с тестовым robots.txt. Ниже — разбор того, что именно теряется, в каком порядке вести работы и по какому чек-листу сверяться до релиза, в день релиза и в первый месяц после.
Что теряют при редизайне и почему
Просадка после редизайна почти никогда не бывает одной большой причиной — это сумма из нескольких мелких, каждую из которых по отдельности легко не заметить. Разложим их по таблице: слева — что теряется, дальше — как это выглядит со стороны владельца и что на самом деле произошло.
| Что теряется | Как это выглядит | Почему происходит |
|---|---|---|
| Позиции по коммерческим запросам | Старые адреса недоступны, новые страницы могут ещё отсутствовать в поиске | Адреса страниц сменились, редиректов нет: для поисковика старые страницы удалены, а новые начинают историю с нуля |
| Title и description | В выдаче вместо проработанного сниппета — шаблон движка вида «Услуги | Компания» | Мета на новой CMS генерятся по общему шаблону, а старые значения никто не выгрузил постранично перед переносом |
| Текст посадочных страниц | Объём страницы падает в 2–5 раз, запросы длинного хвоста исчезают из отчёта «Запросы» в Вебмастере | Дизайнер режет «простыни» ради макета, и вместе с ними уходят абзацы, по которым страница ранжировалась |
| Внешний ссылочный вес | Страницы, на которые ссылались, отдают 404: вес внешних ссылок не доходит ни до одной страницы сайта | Карту редиректов построили по пунктам меню, а страницы-доноры лежали глубже — в блоге, кейсах и старых посадочных |
| Микроразметка и расширенные сниппеты | Из выдачи пропадают цены, хлебные крошки и раскрывающиеся вопросы — сниппет становится «голым» | Schema.org на старом сайте была вписана в шаблоны вручную, новые шаблоны собрали без неё |
| Скорость и Core Web Vitals | LCP уходит за 4 секунды, мобильная выдача проседает заметно сильнее десктопной | Новый дизайн тянет слайдеры, видеофоны, шрифты и сторонние скрипты, которых на прежнем сайте не было |
| Индексация части сайта | Через месяц в индексе остаётся половина прежнего числа адресов | В релиз уехал тестовый robots.txt с Disallow: / или noindex в шаблоне — самая частая и самая дорогая ошибка первого дня |
| Настроенная аналитика | Конверсии перестают считаться, сравнить «до» и «после» нечем | Счётчики и цели перенесли, а идентификаторы кнопок и форм поменялись вместе с вёрсткой |
Обратите внимание: в семи строках из восьми дизайн ни при чём. Именно поэтому редизайн без потери позиций — задача не дизайнера, а того, кто ведёт поисковую часть проекта: он определяет, что считать неприкосновенным, и принимает релиз по формальному чек-листу.
Порядок работ: 7 шагов редизайна без потери позиций
Последовательность здесь важнее содержания каждого шага. Половина неудачных редизайнов — это правильные работы в неправильном порядке: карту редиректов рисуют после того, как новая структура уже свёрстана, а снимок «до» снимают, когда старый сайт уже выключен и сравнивать не с чем.
- Снимок «до». До первой строки кода фиксируем состояние: позиции по ядру, трафик и конверсии по каждой странице за 6–12 месяцев, список страниц с внешними ссылками, текущие title и description, состояние индексации в Вебмастере и Search Console. Этот документ — единственная база, по которой потом можно доказать, что потерь не было.
- Разметка неприкосновенного. По снимку размечаем страницы-доноры: те, что дают трафик, позиции или внешние ссылки. Их адреса, заголовки, мета и смысловые абзацы уходят в новый сайт как есть — это условие проекта, а не предмет обсуждения с дизайнером.
- Решение по URL. Рабочие адреса сохраняем. Для изменяемых составляем карту соответствий до разработки; отдельно фиксируем страницы без подходящей замены.
- Прототипы и дизайн под сохранённую структуру. Макеты рисуются под уже утверждённый состав страниц и объём текста, а не наоборот. Так «воздух» в макете не съедает абзацы, которые ранжируются.
- Сборка и постраничный перенос. Тексты, заголовки, title, description, alt и разметка Schema.org переносятся не «на глаз», а по выгрузке: строка на страницу, с галочкой о переносе. Параллельно собирается карта 301-редиректов — на каждый изменённый адрес, а не на раздел.
- Релиз по чек-листу. Переключение — одно контролируемое действие: боевой robots.txt, включённые редиректы, живой sitemap.xml, self-canonical, работающие счётчики и цели. Проверка занимает меньше часа, а закрывает большую часть типовых потерь.
- Контроль 4 недели. Сверяем индексацию, позиции, обращения и ошибки со снимком до запуска. Учитываем сезонность, спрос и даты переобхода. Период работ не задаёт срок восстановления поисковых результатов.
Сроки при таком порядке: 3–6 недель на сам редизайн и ещё 4 недели контроля, которые входят в работу, а не продаются отдельно. Растянуть первый шаг дешевле, чем пропустить его: снимок «до» стоит один день работы, восстановление позиций после потери — месяцы.
Чек-лист переноса: до релиза
Первый блок чек-листа закрывается, пока старый сайт ещё работает. Если хотя бы один пункт не отмечен, релиз переносится — это дешевле, чем разбирать последствия.
- Снимок «до» снят и сохранён: позиции по ядру, трафик по страницам, конверсии, список внешних ссылок.
- Выгружены все адреса старого сайта из sitemap.xml, Вебмастера, Search Console и логов сервера — четыре источника, потому что ни один из них не полон.
- Составлена таблица соответствия «старый URL → новый URL» на каждый адрес, а не на раздел; строки без пары разобраны отдельно.
- Выгружены и перенесены постранично title, description, H1 и alt изображений.
- Проверено, что смысловые абзацы страниц-доноров переехали целиком, без «творческого сокращения».
- Schema.org собрана на новых шаблонах: организация, хлебные крошки, услуги или товары, FAQ.
- Тестовый контур закрыт от индексации и не совпадает по адресам с боевым.
- Счётчики аналитики и цели пересобраны на новой вёрстке и проверены тестовой заявкой.
- Скорость измерена на тестовом контуре: LCP и CLS в норме до релиза, а не после.
Чек-лист переноса: день релиза и первые сутки
Самые дорогие ошибки редизайна делаются не за недели работ, а за первый час после переключения. Этот блок проверяется сразу и полностью.
- robots.txt — боевой, без Disallow: / и без остатков тестовых правил.
- В шаблонах нет meta robots noindex, оставшегося с тестового контура.
- 301-редиректы включены и отвечают одним переходом, без цепочек и без «всё на главную».
- sitemap.xml отдаёт новые адреса и указан в robots.txt; старая карта не осталась висеть.
- Canonical на каждой странице указывает на саму себя.
- Главное зеркало, HTTPS и слеши на конце адресов совпадают с тем, что в sitemap и редиректах.
- Страница 404 отдаёт код 404, а не 200 — иначе поисковик проиндексирует пустые адреса.
- Формы отправляются, письма доходят, цели в аналитике срабатывают.
- Новый сайт отправлен на переобход в Вебмастере и Search Console, приоритетные страницы — вручную.
Чек-лист переноса: первые четыре недели
Дальше работает не ремонт, а наблюдение. Сравниваем со снимком «до» и отличаем нормальную переиндексацию от настоящей потери.
- Число страниц в индексе догоняет прежнее: смотрим динамику, а не разовый срез.
- В отчётах об ошибках нет всплеска 404 и 5xx — каждый новый адрес с ошибкой закрывается редиректом.
- Позиции по ядру сверяются еженедельно со снимком «до», отклонение разбирается по конкретной странице.
- Трафик сравнивается год к году и с предыдущим периодом — сезонность не путается с просадкой.
- Core Web Vitals по реальным пользователям не ушли в красную зону после появления боевого трафика.
- Страницы, потерявшие показы, проверяются первыми: адрес, мета, объём текста, редирект.
Изменение показов требует проверки конкретных URL: доступности, индексации, содержания, метаданных и поискового спроса. Причину нельзя определить по одному графику. Сохраняйте условия сравнения и не считайте любое падение следствием потерянного текста.
Менять URL или нет: короткий тест
Изменение URL — один из рисков редизайна. На результат также влияют перенос содержания, внутренние ссылки, настройки индексирования, скорость и пользовательские сценарии. Меняйте адреса, когда это обосновано структурой сайта, а не только новым оформлением.
- Структура отражает реальный спрос и понятна человеку — не меняем, даже если адреса некрасивые.
- Адреса содержат идентификаторы вида /index.php?id=274 и не масштабируются под новые разделы — меняем, но с полной картой редиректов.
- Разделы дублируют друг друга и конкурируют за одни запросы — меняем вместе со склейкой дублей, иначе редизайн законсервирует проблему.
- Сайт переезжает на другой домен — это уже не редизайн, а переезд: к чек-листу добавляется склейка зеркал и подтверждение прав на оба домена.
Разница в рисках ощутимая: редизайн с сохранением адресов поисковик видит как обновление страниц, а смену адресов — как появление нового сайта на месте старого, и на переиндексацию в этом случае уходит от двух недель до пары месяцев.
Как проверить методику и пример контроля
Порядок переноса URL и возможные колебания описаны в официальной документации Google.
Для самостоятельной проверки доступна сводка технического обхода aosa.ru: это фактическая проверка 906 URL, а не кейс роста трафика.
До редизайна нужен снимок работающих страниц и сценариев обращений. Без него сложно отличить ошибку переноса от изменения спроса или выдачи. Приёмка включает проверку адресов, содержания, форм и аналитики; выводы о поисковом результате опираются на сравнимые данные.
Владимир БогдановОснователь и руководитель AOSA · эксперт по SEO и AEO, 12+ лет в поисковой оптимизации