Потеря трафика после редизайна не означает автоматически санкции или «непонравившийся дизайн». Релиз одновременно меняет аналитику, адреса, шаблоны, внутренние ссылки, метаданные, скорость и содержимое. Диагностика нужна, чтобы найти слой, где возник разрыв: измерение, обход, индексирование, соответствие страницы запросу или конверсия после клика.
Начните с сохранения текущего состояния и списка изменений. Не откатывайте весь сайт до проверки: откат может вернуть старые ошибки, оборвать новые редиректы и уничтожить данные для расследования. Если есть критическая недоступность, случайный запрет индексации или массовые ошибки сервера, исправляйте их сразу; остальные гипотезы проверяйте последовательно.
Google предупреждает, что при переносе с изменением URL видимость может временно колебаться, а скорость обработки зависит от размера сайта и возможностей сервера. Это не повод ждать при явной технической ошибке и не обещание восстановления к фиксированной дате.
Первую проверку проводите на фактической опубликованной версии, а не только на макетах или тестовом стенде.
Шаг 1. Убедитесь, что упал именно поисковый трафик#
Сравните данные минимум в двух независимых источниках: системе веб-аналитики и панели поисковой системы. В аналитике проверьте органический канал и посадочные страницы. В Яндекс Вебмастере или Search Console — показы и клики из поиска.
Если панели показывают прежнее число кликов, а аналитика — падение сессий, вероятна проблема счётчика, согласия, редиректа или атрибуции. Если снизились показы и клики в поисковой панели, исследуйте видимость и индексирование. Если показы стабильны, клики снизились, смотрите позицию и сниппет.
Зафиксируйте:
- точное время релиза и последующих исправлений;
- изменённые домены, протоколы, поддомены и пути;
- устройство, регион и разделы, где началось снижение;
- поисковые системы и брендовые/небрендовые сегменты;
- сезонность и внешние кампании;
- изменения счётчика, cookie-баннера и тег-менеджера.
Сравнивайте одинаковые дни недели и сопоставимые периоды. Но не ждите конца месяца, если с минуты релиза все старые URL возвращают 404.
Шаг 2. Постройте карту потерь по URL#
Выгрузите посадочные страницы органического трафика до редизайна и текущие URL. Соедините таблицы по старому адресу и запланированному новому. Для каждой строки добавьте код ответа, конечный URL, canonical, состояние индексации, число внутренних ссылок и изменение показов.
| Старый URL | Новый URL | Ответ старого | Конечный ответ | Canonical нового | Внутренние ссылки | Статус |
|---|---|---|---|---|---|---|
/old-a | /new-a | 301 | 200 | /new-a | 5 | проверить контент |
/old-b | — | 404 | — | — | 0 | решить: восстановить, объединить или удалить |
/old-c | /new-c | 302 | 200 | /old-c | 2 | исправить сигналы |
Строки условны. В реальном расследовании сначала сортируйте по потерянным кликам или ценности, чтобы не тратить одинаковое время на все адреса.
Если редизайн не должен был менять URL, любое массовое отличие — отдельный инцидент. Если смена планировалась, карта соответствий должна существовать до релиза. Создавать её задним числом можно по аналитике, sitemap, логам, резервной копии и внешним ссылкам.
Шаг 3. Проверьте доступность и ответы сервера#
Пройдите список старых и новых страниц краулером или скриптом. Ищите:
4xxна адресах, которые должны жить или перенаправляться;5xx, тайм-ауты и нестабильные ответы;- временные редиректы там, где перенос постоянный;
- цепочки и циклы редиректов;
- массовое перенаправление разных страниц на главную;
- ответы
200с текстом ошибки или пустым шаблоном; - разные результаты для робота и обычного браузера.
Google рекомендует направлять старый URL на релевантный новый и не сводить множество несвязанных страниц на главную: такие переходы могут восприниматься как soft 404. Если подходящей замены нет, корректный 404 или 410 честнее.
Проверьте конечный адрес в каждой цепочке. Успешный первый 301 не помогает, если он приводит на 404, закрытый URL или ещё три перенаправления.
Шаг 4. Найдите случайные запреты и конфликтующие сигналы#
На тестовом стенде часто включают noindex или запрет обхода, а при релизе забывают снять. Проверьте HTML, HTTP-заголовки и robots.txt. Важно различать обход и индексирование: закрытый в robots.txt URL робот может не прочитать и, следовательно, не увидеть noindex внутри.
Для каждого нового URL согласуйте:
- серверный ответ
200; - разрешение на обход необходимых ресурсов;
- отсутствие случайного
noindex; - самоссылочный canonical или обоснованный канонический адрес;
- включение канонического URL в sitemap;
- внутренние ссылки непосредственно на конечный адрес.
Конфликт возникает, когда редирект ведёт на новый URL, canonical указывает на старый, sitemap содержит оба, а меню продолжает ссылаться на старый. Поисковику приходится выбирать между сигналами. Google называет редиректы и rel="canonical" сильными сигналами канонизации, а включение в sitemap — более слабым; согласованность нескольких методов повышает вероятность нужного выбора.
Шаг 5. Сравните содержимое до и после#
Редизайн часто незаметно сокращает контент. В новый шаблон не переносятся таблицы, FAQ, подписи, отзывы, хлебные крошки, описания категорий или данные, загружавшиеся на сервере. Страница сохраняет адрес и красивый вид, но перестаёт отвечать на прежние запросы.
Сравните старую и новую версии по смысловым элементам:
| Элемент | До | После | Риск |
|---|---|---|---|
| Основной ответ | был в первом экране | спрятан во вкладке | пользователь и робот могут получить менее ясный ответ |
| Таблица характеристик | серверный HTML | загружается после действия | содержимое может быть недоступно или неудобно |
| H1 | уникальный | общий для раздела | страницы хуже различаются |
| Title | конкретный | шаблонный | меняется обещание в выдаче |
| Внутренние ссылки | контекстные | только меню | ослабевает тематическая связь |
| Дата и автор | видны | удалены | сложнее оценить актуальность и ответственность |
Не возвращайте старый текст целиком только потому, что он был длиннее. Восстановите полезные функции и подтверждённые ответы. Если интент изменился, проектируйте актуальный формат по инструкции выбора страницы.
Шаг 6. Проверьте рендеринг и производительность#
Если новый сайт стал клиентским JavaScript-приложением, откройте исходный HTML и отрендеренную версию. Убедитесь, что основной текст, ссылки, title, canonical и структурированные данные доступны и не появляются только после клика, прокрутки или ошибки API.
Проверьте мобильный экран на реальном устройстве и нестабильной сети. Большая обложка, баннер согласия или скрипт могут перекрывать ответ. Ошибки загрузки не всегда снижают показы сразу, но способны ухудшить использование и конверсию.
Скорость оценивайте по шаблонам и реальным полевым данным, если они накоплены. Не сводите расследование к одному лабораторному баллу: критичнее увидеть, загружается ли содержание и можно ли выполнить действие.
Шаг 7. Восстановите внутреннюю архитектуру#
Новый дизайн часто меняет меню, пагинацию и карточки рекомендаций. В результате важные страницы становятся сиротами или уходят глубже. Сравните число и источники внутренних ссылок до и после.
Приоритет:
- Вернуть ссылки на основные разделы из глобальной навигации, если они действительно нужны пользователю.
- Связать хабы с дочерними материалами обычными HTML-ссылками.
- Обновить все ссылки со старых адресов на конечные новые, чтобы не гонять пользователя через редирект.
- Восстановить хлебные крошки и пагинацию.
- Найти URL без входящих ссылок.
Google в инструкции по переносу прямо рекомендует обновлять внутренние ссылки по карте старых и новых адресов. Перелинковка — не косметика: она помогает обнаружению и объясняет структуру.
Шаг 8. Проверьте sitemap и панели поисковых систем#
Сгенерируйте sitemap из фактических канонических индексируемых URL. Уберите старые адреса после запуска корректных редиректов и добавьте новые. Отправьте карту в панели и отслеживайте ошибки.
В панели смотрите не только общее число страниц, но и примеры исключённых URL, выбранный canonical, динамику обхода и запросы по пострадавшим разделам. Для нескольких наиболее ценных страниц выполните адресную проверку. Не отправляйте на переобход тысячи URL как замену исправлению шаблона.
Как расставить приоритеты исправлений#
| Приоритет | Проблема | Почему |
|---|---|---|
| P0 | сайт закрыт, массовые 5xx, потерян домен или DNS | страницы недоступны пользователю и роботу |
| P1 | важные URL дают 404, неверные редиректы, noindex, canonical на чужой адрес | теряются или конфликтуют сигналы |
| P2 | пропали контент, метаданные и внутренние ссылки | меняется релевантность и обнаружение |
| P3 | ухудшилась скорость, разметка, отдельные элементы сниппета | влияет на опыт и представление, но не всегда объясняет массовую потерю |
| P4 | косметические отличия | исправлять после причин потери |
Сначала чините шаблонный дефект, затем отдельные страницы. Один исправленный компонент может восстановить тысячи URL.
План восстановления и контроль#
Ведите журнал релизов: проблема, список URL, изменение, время, ответственный и проверка. После каждого пакета перепройдите затронутые адреса и убедитесь, что не появился новый конфликт.
Оценку делите на уровни:
- технический: правильные ответы, canonical, индексация;
- поисковый: показы, запросы, позиции и клики по URL;
- продуктовый: вовлечение и целевые действия;
- финансовый: лиды и продажи при корректной атрибуции.
Восстановление индексации предшествует восстановлению показов, а показы — кликам. Не требуйте от последней ступени мгновенного ответа, если первая ещё не обработана.
Как подготовить следующий редизайн#
До релиза заморозьте карту URL и снимок ключевых метрик. Разверните тестовый стенд, закрытый от публичной индексации, но доступный команде. Выполните полный обход старой и новой версии, сравните адреса, метаданные, канонические ссылки, H1, контент и внутренние ссылки. Проверьте редиректы до переключения домена.
В день релиза контролируйте серверные ошибки, счётчик, robots.txt, sitemap и набор ключевых URL. Не объединяйте смену домена, CMS, структуры, дизайна и содержания без необходимости: чем больше одновременных изменений, тем труднее установить причину.
Полная техническая база проверки есть в аудите сайта, а правила работы с дублями — в материале о канонических адресах.
Официальные источники#
- Google: перенос сайта с изменением URL
- Google: канонические URL и сигналы канонизации
- Google: обзор сканирования и индексирования
- Яндекс Вебмастер: файлы Sitemap
Вопросы и ответы#
Нужно ли сразу откатывать редизайн?
Только при критической недоступности или если безопасное точечное исправление невозможно. В остальных случаях сначала локализуйте причину и сохраните доказательства.
Сколько ждать восстановления трафика?
Фиксированного срока нет. Он зависит от типа ошибки, масштаба сайта, повторного обхода и обработки сигналов. Контролируйте прохождение ступеней, а не обещанную дату.
Можно ли перенаправить все старые статьи на раздел?
Только если раздел действительно является релевантной заменой каждой страницы, что бывает редко. Несвязанные редиректы на главную или общий раздел бесполезны пользователю и могут обрабатываться как soft 404.