Редизайн роняет трафик не потому, что новый дизайн хуже старого. Он роняет трафик потому, что вместе с дизайном обычно меняют всё остальное: адреса, тексты, заголовки, структуру меню, движок. После запуска позиции проседают, и понять, что именно из двадцати изменений сработало против сайта, уже невозможно. Дальше — месяцы гадания.
Разбираю по порядку: что снять до работ, что менять можно смело, что нельзя трогать одновременно и как выглядит первая неделя после переключения.
Слепок «до» — без него разбираться будет не в чем
Это единственный этап, который нельзя отложить: после переключения старую версию уже не посмотреть. Минимальный набор, который снимаем всегда:
- Полный краул старого сайта — Screaming Frog, экспорт internal_html: адрес, код ответа, title, description, H1, количество слов, canonical, глубина вложенности
- Выгрузка «Страницы в поиске» из Яндекс.Вебмастера — Индексирование → Страницы в поиске → «Все страницы»: именно этот список показывает, какие адреса Яндекс держит в индексе, а не какие есть на сайте
- Запросы с показами из Вебмастера и Search Console за 3–6 месяцев, сгруппированные по странице входа
- Позиции в системе съёма на дату перед работами
- Страницы входа из Метрики за квартал: отчёт по поисковым системам с группировкой по странице входа, только органика
Дальше любой разговор «трафик упал» превращается в конкретное: упал на таких-то страницах, по таким-то запросам, с такой-то даты.
Просадка после редизайна почти всегда локальная: страдают те страницы, которые задели сильнее всего. Без слепка «до» это выглядит как общее падение сайта, и лечить начинают не то.
Что меняется безопасно
Визуальный слой поисковые системы не ранжируют напрямую. Пока адрес, заголовки и текст на месте, можно переделывать что угодно: сетку, шрифты, цвета, иллюстрации, карточки товаров и услуг; хедер и подвал — при условии, что ссылки из них никуда не исчезли; шаблоны блоков, аккордеоны, табы, галереи; формы заявки и модалки. Это та часть редизайна, которую можно катить одним релизом и не бояться.
Что нельзя менять одновременно
Дальше начинается зона, где каждое изменение само по себе переживаемо, а вместе они дают эффект, который уже не разложить на составляющие.
Адреса и содержимое. Самая частая связка. Меняют структуру URL — и в том же релизе переписывают тексты. Поиск видит: старый адрес отдаёт 301, новый адрес содержит незнакомый документ. Переиндексация идёт медленнее, а склейка сигналов между старым и новым URL хуже, чем при переносе документа один в один. Правильный порядок: сначала новый шаблон на тех же адресах с теми же текстами, через две-четыре недели после стабилизации — работа над содержимым. Если URL менять всё-таки надо, это отдельный релиз, где кроме адресов не меняется ничего.
Движок и структура разделов. Переезд с WordPress на 1С-Битрикс или обратно сам по себе тянет новые правила формирования адресов, новую пагинацию, новые параметры фильтров. Если одновременно перекроить каталог — слить два раздела в один, вынести подкатегории на уровень выше, — на выходе получается сайт, у которого не совпадает с прежним ни одна посадочная. Как это делается отдельным этапом, разобрано в статье про переезд сайта.
Заголовки и шаблоны метатегов. Title и H1 — то, по чему поиск понимает, о чём страница. Новый шаблон метатегов почти всегда «красивее» старого: короче, без перечислений, без города. И почти всегда теряет вхождения, на которых страница ранжировалась. Меняйте шаблон отдельным шагом и только после того, как посмотрите, по каким формулировкам страница получает показы.
Объём текста. Типовая история: было четыре тысячи знаков описания раздела, стало девятьсот — «чтобы не было простыни». Для коммерческой выдачи полнота текста работает как фактор, и уменьшать объём на редизайне не нужно. Если текст правда плохой, его переписывают, сохраняя объём, а не вырезают.
Внутренние ссылки. Новое меню обычно короче старого. Вместе с ним исчезают ссылки на десятки страниц второго уровня, которые раньше были в одном клике от главной. Формально страницы живы, фактически ушли на глубину четыре-пять и потеряли вес. Сверяйте глубину вложенности по краулу «до» и «после» — в Screaming Frog это колонка Crawl Depth.
Карта 301: как её делать, чтобы она работала
Если адреса всё-таки меняются, редиректы — это не «поставим маску и всё поймётся».
- Один к одному: каждый старый адрес из выгрузки «Страницы в поиске» ведёт на страницу с тем же смыслом. Массовый редирект всего каталога на его корень для поиска равен удалению страниц
- Без цепочек: старый URL → новый URL, одним шагом, код 301. Цепочка из двух-трёх переходов тратит краулинговый бюджет и передаёт меньше сигналов
- Со слэшем и без: если сайт живёт на адресах со слэшем на конце, нормализация должна стоять раньше карты редиректов, иначе половина правил не сработает
- Не удалять старые правила через месяц: редкие страницы обходятся раз в несколько месяцев, карта 301 живёт минимум год
- Не терять query: utm-метки из рекламы после редиректа обязаны доезжать, иначе весь платный трафик слипнется в «переходы напрямую»
Проверяется вся карта в один проход: curl -sIL https://site.ru/staryj-adres/ и смотрим цепочку заголовков HTTP и Location. Отдельно — директива Clean-param в robots.txt для параметров, которые не меняют содержимое: Clean-param: utm_source&utm_medium&utm_campaign&yclid /. Это подсказка именно для Яндекса, Google её не учитывает.
Стейджинг закрывают паролем, а не robots.txt
Тестовый сайт на поддомене вида new. или test., закрытый строкой Disallow: /, — классическая мина. Во-первых, Disallow запрещает не индексацию, а обход: адрес всё равно может попасть в индекс, если на него есть внешняя ссылка. Во-вторых, при переключении в продакшен этот robots.txt регулярно уезжает вместе с кодом — и живой сайт оказывается закрыт целиком.
Как надо: HTTP Basic Auth на весь поддомен плюс заголовок X-Robots-Tag: noindex, nofollow на уровне сервера. И отдельный пункт в чек-листе релиза: проверить robots.txt и отсутствие noindex в шаблоне боевого сайта.
Скорость: новый сайт обычно тяжелее старого
Свежая вёрстка почти всегда приносит больше шрифтов, больше JS и больше картинок. Если до редизайна LCP был около двух секунд, а стал вдвое больше, часть просадки объясняется этим, а не структурой. Замерьте PageSpeed по пяти-семи типовым страницам до работ и по тем же страницам после; при расхождении разбирайтесь со скоростью отдельно, до того как списывать всё на редизайн. Что и в каком порядке чинить в каталоге, разобрано в статье про Core Web Vitals.
Первая неделя после переключения
- Коды ответа по всему списку старых URL: прогон выгрузки из Вебмастера через краулер в режиме списка — ждём 301 на живой адрес, ловим 404 и 200 там, где их быть не должно
- Логи на 404: awk по коду ответа в access.log показывает, какие адреса реально ломаются у посетителей и роботов, а не в теории
- sitemap.xml пересобрать — только адреса с кодом 200 и настоящий lastmod; 301 и 404 внутри карты сайта означают, что карта не поддерживается
- Переобход в Вебмастере для двух-трёх десятков важнейших страниц плюс IndexNow на весь изменившийся список
- Микроразметка: проверить, что Organization, BreadcrumbList, Service и Offer, FAQPage и Article не потерялись в новом шаблоне
- Цели в Метрике: новые формы означают новые селекторы, и цели, настроенные на старые классы, молча перестают срабатывать
Последний пункт стоит отдельного внимания. Через месяц выясняется, что заявок нет не потому, что их нет, а потому что их не считают. Что именно проверить в счётчике, мы разбирали в статье про цели в Метрике.
Дальше — две-три недели наблюдения без правок. Колебания позиций в этот период нормальны: поиск переобходит документы и пересчитывает сигналы. Массово что-то докручивать, пока индекс не устоялся, — значит снова смешать переменные.
Когда просадка есть, а причина не ясна
Всё сходится к тем же данным. Берём страницы, у которых упали показы, и сверяем с краулом «до»: изменился URL? изменился title? стало меньше текста? выросла глубина? пропала из меню? В подавляющем большинстве случаев ответ находится в одной из этих пяти колонок. Если нет — дело либо в скорости, либо в том, что вообще не относится к редизайну: сезонность, апдейт алгоритма, новый конкурент в выдаче.
Отдельный технический аудит после редизайна имеет смысл заказывать не через неделю, а через месяц — раньше данных просто нет, и любой вывод будет гаданием.
Менять по одному слою за релиз: сначала оформление на прежних адресах и текстах, потом адреса, потом содержимое, потом метатеги. Это скучный порядок, но только он позволяет через месяц ответить на вопрос «почему упало» строкой из таблицы, а не предположением.
Мы делаем редизайн именно так: снимаем слепок, переносим документ один в один, разносим изменения по релизам и держим карту редиректов. Как устроены работы и что входит в этап — на странице редизайна и доработки. Если сайт уже переключили и трафик просел, начинать нужно не с правок, а с разбора: что именно изменилось у пострадавших страниц — это первая часть работ по продвижению.
