Редизайн — вторая по частоте причина обвала органического трафика после санкций поисковиков. Сайт становится красивее, а заявок — меньше: вместе со старой вёрсткой команда случайно выбрасывает URL, мета-теги, тексты и разметку, на которых держались позиции. При этом сама по себе миграция не опасна — опасна миграция без инвентаризации и карты редиректов. Ниже — полный чек-лист, который закрывает риски на каждом этапе: до, во время и после переезда.
В этой статье 7
Почему трафик падает после редизайна
Позиции сайта держатся на конкретных страницах: у каждой — свой URL, свой title, свой контент, своя накопленная история и внешние ссылки. Поисковик ранжирует не «сайт вообще», а эти самые документы. Редизайн или смена платформы почти всегда что-то из этого меняет: URL перестраиваются под новый движок, тексты сокращаются «ради воздуха в макете», мета-теги генерируются заново, Schema-разметка теряется вместе со старыми шаблонами. Для поисковика это выглядит как исчезновение проверенных страниц и появление незнакомых — и он честно отправляет новые страницы зарабатывать доверие заново.
Отсюда главный принцип безопасной миграции: всё, что можно сохранить, — сохраняется; всё, что нельзя сохранить, — переадресуется по правилу 1:1. Каждый шаг чек-листа ниже обслуживает этот принцип.
Шаг 1. Инвентаризация: зафиксируйте, что у вас есть
До того как тронуть хоть одну страницу, соберите полный список URL старого сайта — из выгрузки CMS, краулера (Screaming Frog или аналог), XML-карты, Метрики и Search Console. Источников нужно несколько: краулер не увидит страницы без внутренних ссылок, а аналитика покажет URL, которые реально приводят людей.
- Полный список URL со статусами ответа (200, 301, 404).
- По каждому URL — органический трафик за 6–12 месяцев из Метрики.
- Страницы с внешними ссылками (по данным Вебмастера, Search Console или ссылочных сервисов).
- Выгрузка title, description и h1 всех страниц.
- Снимок позиций по ядру запросов — база для сравнения «до/после».
Шаг 2. Карта редиректов 1:1
Если URL меняются, для каждого старого адреса назначается 301-редирект на максимально соответствующий новый: карточка — на ту же карточку, статья — на ту же статью, категория — на ту же категорию. Это табличная работа: колонка «старый URL», колонка «новый URL», без пропусков. Редирект «всё на главную» — худшее из возможных решений: поисковики трактуют его как мягкую 404, вес страниц не передаётся, позиции сгорают.
- Постройте таблицу соответствий для 100% URL из инвентаризации.
- Правило: один старый URL → один релевантный новый. Нет точного аналога — редирект на ближайшую родительскую категорию, а не на главную.
- Исключите цепочки (старый → промежуточный → новый) и петли: редирект должен быть одношаговым.
- Сохраните существующие старые редиректы: обновите их цели на новые URL напрямую.
- Проверьте карту на тестовом стенде краулером до запуска, а не после.
Шаг 2. Карта редиректов 1:1
- Постройте таблицу соответствий для 100% URL из инвентаризации.
- Да
- Правило: один старый URL → один релевантный новый. Нет точного аналога — редирект на ближайшую родительскую категорию, а не на главную.
- Да
- Исключите цепочки (старый → промежуточный → новый) и петли: редирект должен быть одношаговым.
- Да
- Сохраните существующие старые редиректы: обновите их цели на новые URL напрямую.
- Да
- Проверьте карту на тестовом стенде краулером до запуска, а не после.
- Да
Текст схемы и все данные
Шаг 2. Карта редиректов 1:1
- Постройте таблицу соответствий для 100% URL из инвентаризации.
- Да
- Правило: один старый URL → один релевантный новый. Нет точного аналога — редирект на ближайшую родительскую категорию, а не на главную.
- Да
- Исключите цепочки (старый → промежуточный → новый) и петли: редирект должен быть одношаговым.
- Да
- Сохраните существующие старые редиректы: обновите их цели на новые URL напрямую.
- Да
- Проверьте карту на тестовом стенде краулером до запуска, а не после.
- Да
Лучший редирект — тот, который не понадобился. Если структура адресов не мешает новой платформе, сохраняйте URL как есть: это самый надёжный способ ничего не потерять. Меняйте адреса только там, где есть внятная причина.
Шаг 3. Перенос мета-тегов, структуры и разметки
Новый дизайн — не повод для новых title. Заголовки, description, h1, тексты страниц и структура подзаголовков переносятся на новые шаблоны без «творческого улучшения»: они уже проверены выдачей. То же касается технического слоя: JSON-LD разметка, canonical, пагинация, внутренняя перелинковка — всё воспроизводится на новой платформе и сверяется постранично. Переписывать тексты и менять мета-теги можно — но отдельным этапом после миграции, когда трафик стабилизировался и эффект каждого изменения можно измерить.
Что обязательно сверить на тестовом стенде до запуска
- Элемент: Title, description, h1
- Риск при потере: Просадка по всем запросам страницы
- Как проверить: Пошаблонная выгрузка «старое vs новое»
- Элемент: Тексты страниц
- Риск при потере: Потеря релевантности и длинного хвоста
- Как проверить: Сравнение объёма и вхождений по ключевым страницам
- Элемент: JSON-LD / Schema
- Риск при потере: Потеря расширенных сниппетов и цитируемости в нейроответах
- Как проверить: Валидатор разметки на каждом типе страниц
- Элемент: Внутренние ссылки
- Риск при потере: Перекос веса, страницы-сироты
- Как проверить: Краулинг стенда: глубина и входящие ссылки
- Элемент: robots.txt и sitemap
- Риск при потере: Случайный запрет индексации
- Как проверить: Ручная проверка + краулер
- Элемент: Скорость и CWV
- Риск при потере: Ухудшение поведенческих сигналов
- Как проверить: PageSpeed по шаблонам страниц
Текст схемы и все данные
Что обязательно сверить на тестовом стенде до запуска
- Элемент: Title, description, h1
- Риск при потере: Просадка по всем запросам страницы
- Как проверить: Пошаблонная выгрузка «старое vs новое»
- Элемент: Тексты страниц
- Риск при потере: Потеря релевантности и длинного хвоста
- Как проверить: Сравнение объёма и вхождений по ключевым страницам
- Элемент: JSON-LD / Schema
- Риск при потере: Потеря расширенных сниппетов и цитируемости в нейроответах
- Как проверить: Валидатор разметки на каждом типе страниц
- Элемент: Внутренние ссылки
- Риск при потере: Перекос веса, страницы-сироты
- Как проверить: Краулинг стенда: глубина и входящие ссылки
- Элемент: robots.txt и sitemap
- Риск при потере: Случайный запрет индексации
- Как проверить: Ручная проверка + краулер
- Элемент: Скорость и CWV
- Риск при потере: Ухудшение поведенческих сигналов
- Как проверить: PageSpeed по шаблонам страниц
| Элемент | Риск при потере | Как проверить |
|---|---|---|
| Title, description, h1 | Просадка по всем запросам страницы | Пошаблонная выгрузка «старое vs новое» |
| Тексты страниц | Потеря релевантности и длинного хвоста | Сравнение объёма и вхождений по ключевым страницам |
| JSON-LD / Schema | Потеря расширенных сниппетов и цитируемости в нейроответах | Валидатор разметки на каждом типе страниц |
| Внутренние ссылки | Перекос веса, страницы-сироты | Краулинг стенда: глубина и входящие ссылки |
| robots.txt и sitemap | Случайный запрет индексации | Ручная проверка + краулер |
| Скорость и CWV | Ухудшение поведенческих сигналов | PageSpeed по шаблонам страниц |
Отдельная строка чек-листа — скорость. Миграция имеет смысл только если новая платформа не медленнее старой; в идеале переезд используют как повод пересобрать сайт на быстром стеке. Почему это напрямую влияет на позиции — мы разбирали в статье как технологии сайта влияют на SEO.
Шаг 4. Запуск: день X
- Запускайте в период минимального трафика (ночь, выходные) и целиком, а не по частям.
- Сразу проверьте robots.txt: запрет индексации с тестового стенда — классическая катастрофа запуска.
- Включите все редиректы одновременно с релизом и прогоните краулером старый список URL: каждый должен отвечать 301 в один шаг.
- Обновите и отправьте sitemap в Вебмастер и Search Console.
- Пройдите руками по топ-20 страниц по трафику: контент, мета, разметка, формы.
- Проверьте, что Метрика и цели работают на новых шаблонах.
Шаг 4. Запуск: день X
- Запускайте в период минимального трафика (ночь, выходные) и целиком, а не по частям.
- Да
- Сразу проверьте robots.txt: запрет индексации с тестового стенда — классическая катастрофа запуска.
- Да
- Включите все редиректы одновременно с релизом и прогоните краулером старый список URL: каждый должен отвечать 301 в один шаг.
- Да
- Обновите и отправьте sitemap в Вебмастер и Search Console.
- Да
- Пройдите руками по топ-20 страниц по трафику: контент, мета, разметка, формы.
- Да
- Проверьте, что Метрика и цели работают на новых шаблонах.
- Да
Текст схемы и все данные
Шаг 4. Запуск: день X
- Запускайте в период минимального трафика (ночь, выходные) и целиком, а не по частям.
- Да
- Сразу проверьте robots.txt: запрет индексации с тестового стенда — классическая катастрофа запуска.
- Да
- Включите все редиректы одновременно с релизом и прогоните краулером старый список URL: каждый должен отвечать 301 в один шаг.
- Да
- Обновите и отправьте sitemap в Вебмастер и Search Console.
- Да
- Пройдите руками по топ-20 страниц по трафику: контент, мета, разметка, формы.
- Да
- Проверьте, что Метрика и цели работают на новых шаблонах.
- Да
Шаг 5. Мониторинг после переезда
Миграция заканчивается не в день релиза, а через 4–8 недель, когда поисковики переобойдут сайт и трафик стабилизируется. Первые две недели смотрите ежедневно: ошибки краулинга и всплеск 404 в Вебмастере и Search Console, скорость переиндексации, полевые Core Web Vitals. Далее — еженедельные срезы позиций по ядру и сравнение органики со снимком «до». Умеренная просадка в первые недели нормальна: поисковик переклеивает сигналы на новые адреса. Тревожный сигнал — когда отдельные страницы не восстанавливаются дольше 6–8 недель: тогда точечно проверяют редирект, полноту контента и внутренние ссылки на страницу.
Пример условный, для иллюстрации порядка работ. Сайт услуг на устаревшей CMS переезжает на быструю платформу с редизайном. Две недели уходит на инвентаризацию и карту редиректов, неделя — на сверку мета и разметки на стенде, запуск — в ночь на субботу. В первые две недели органика проседает на небольшую долю и к шестой неделе возвращается к исходному уровню, а дальше начинает расти за счёт ускорившихся страниц. Ключ — не героизм после запуска, а скучная табличная работа до него.
Собирательный пример на основе типовых проектов — не реальный клиент.
Типичные ошибки-катастрофы
- Запуск без инвентаризации: никто не знает, какие страницы приносили трафик, и потери замечают через месяц.
- Редирект всех старых URL на главную вместо карты 1:1.
- Забытый noindex или запрет в robots.txt с тестового стенда.
- «Заодно перепишем все тексты и title» — одновременная смена адресов и контента, после которой невозможно понять, что именно уронило позиции.
- Потеря мобильной версии или резкое утяжеление страниц новым дизайном.
- Отключение старых редиректов через пару месяцев — их держат минимум год.
- Смена домена одновременно с редизайном: двойной риск; если домен тоже меняется, читайте отдельный гайд про переезд на новый домен.
В миграциях правило одно: за один релиз — одно большое изменение. Меняете платформу — сохраняйте URL и тексты. Меняете структуру — не трогайте домен и контент. Каждое совмещение «заодно» умножает риск и лишает вас диагностики: когда после запуска просело всё сразу, откатывать приходится вслепую. И второе: миграцию должен вести тот, кто отвечает за трафик после неё. Когда разработчик сдаёт релиз актом, а последствия в выдаче — «не его зона», чек-лист выполняется ровно наполовину. Поэтому мы в АОСА делаем редизайн и дальнейшую поддержку одной командой с SEO — ответственность за позиции не разрывается на стыке.
Владимир БогдановОснователь и руководитель AOSA · эксперт по SEO и AEO, 12+ лет в поисковой оптимизации