После редизайна упал поисковый трафик: что проверить и как восстановиться
После падения органического трафика не откатывайте сайт по одной кривой Метрики. Сначала подтвердите, что просел именно поиск, затем локализуйте проблему по URL и разделите три сценария: ошибка аналитики, проблема обхода/индексации или изменение видимости и CTR.
Зафиксируйте точное время релиза и прекратите несвязанные изменения. Чем больше правок команда внесёт во время инцидента, тем сложнее будет понять причину и безопасно восстановить систему.
Сначала исключите ошибку аналитики
Сравните органические сессии в Метрике с показами и кликами в Яндекс Вебмастере. Если Вебмастер не показывает резкого снижения, а сессии пропали в момент релиза, сначала проверьте счётчик и отчёт.
| Наблюдение | Вероятное направление |
|---|---|
| Сессии упали, показы и клики стабильны | счётчик, SPA-pageview, фильтры, атрибуция |
| Показов стало меньше, важные URL исчезли | обход, индексация, статусы, запреты |
| URL индексируются, позиции снизились | контент, внутренняя перелинковка, рендеринг, регион |
| Позиции стабильны, CTR снизился | сниппет, title/description, состав выдачи, запросный микс |
| Трафик стабилен, заявок меньше | формы, CRM, телефония, предложение |
Проверьте установку Метрики на всех новых шаблонах, отправку pageview в SPA, домен счётчика, цели и сегмент отчёта. Не сравнивайте периоды с разными фильтрами и моделями атрибуции.
Что проверить немедленно
Откройте список ключевых страниц, которые до редизайна получали показы, клики и заявки. Для каждой проверьте:
- Какой HTTP-код получает пользователь и YandexBot.
- Не закрыт ли URL в
robots.txt. - Нет ли
noindexв HTML или HTTP-заголовке. - Какой адрес указан в
rel="canonical". - Присутствует ли основной контент в отрендеренной версии.
- Куда ведёт старый URL и сколько редиректов в цепочке.
- Работают ли форма, телефон и следующий шаг.
Вебмастер предоставляет инструмент проверки ответа сервера. Canonical является рекомендацией, а не гарантированной командой: как Яндекс обрабатывает канонический адрес.
Системный noindex, массовые 5xx, недоступный контент или неправильный canonical на тестовый домен требуют немедленного исправления и могут стать основанием для отката.
Проверьте карту старых и новых URL
Выгрузите адреса старой и новой версии и соедините их в таблице. Сначала разберите страницы с органическим трафиком, внешними ссылками и заявками.
Сначала проверьте соответствие адресов и требуемое действие:
| Старый URL | Новый URL | Действие |
|---|---|---|
| сохранён | тот же | наблюдать |
| изменён | релевантный новый | проверить индексацию |
| ведёт на главную | нет соответствия | найти релевантную цель |
| исчез | нет | подтвердить решение |
| цепочка | промежуточные адреса | сократить до одной цели |
Затем сопоставьте технический ответ и содержимое каждого сценария:
| Сценарий | HTTP | Canonical | Контент |
|---|---|---|---|
| сохранён | 200 | на себя | сопоставим |
| изменён | 301 → 200 | новый на себя | перенесён |
| ведёт на главную | 301 | главная | другой |
| исчез | 404/410 | нет | направление закрыто |
| цепочка | несколько 3xx | разный | неизвестно |
При изменении структуры Яндекс рекомендует 301 со старой страницы на соответствующую новую. Массовый редирект всех адресов на главную теряет соответствие запросу и не должен быть способом скрыть отсутствие миграционной карты.
Проверьте запреты, sitemap и рендеринг
Сравните старый и новый robots.txt. Частая ошибка — перенос тестового запрета на production. Помните: если робот не может открыть URL из-за robots, он может не увидеть директиву внутри страницы.
Проверьте sitemap: он должен быть доступен, содержать конечные production-URL с кодом 200 и не включать тестовые, редиректные или закрытые страницы. Сам sitemap не гарантирует индексацию; Яндекс описывает его как способ сообщить структуру сайта: правила Sitemap.
Для JavaScript-интерфейса сравните HTML-ответ и отрендеренный контент робота. Если значимый текст, ссылки или карточки появляются только после неподдержанного сценария выполнения, страница может формально отвечать 200, но не передавать нужный смысл поиску.
Сравните содержимое и внутренние связи
Если URL доступны и индексируются, сравните до и после:
-
title, description и H1; - основной текст и ответы на коммерческие вопросы;
- категории, фильтры и страницы спроса;
- внутренние ссылки и хлебные крошки;
- содержание ссылок и число переходов до важной страницы;
- структурированные данные;
- региональные признаки и контактную информацию;
- мобильную доступность основного контента.
Редизайн часто сокращает «лишний текст», объединяет разные услуги или прячет ссылки за интерактивными элементами. Не возвращайте всё механически. Определите, какой удалённый элемент отвечал конкретному запросу или обеспечивал путь робота, и восстановите его функцию.
Что делать в первые сутки и после переобхода
Сразу
Зафиксировать релиз, проверить аналитику, ключевые коды, robots, noindex, canonical, редиректы, формы и системные ошибки.
В первые сутки
Собрать URL diff, проверить sitemap, контент, внутренние ссылки, JS-рендеринг, метаданные и страницы с прежним трафиком.
После переобхода
Смотреть статус важных URL, показы, клики, позиции и CTR по группам, а не только общую кривую.
Добавьте приоритетные адреса в мониторинг важных страниц. Ведите журнал: проблема, доказательство, исправление, время выпуска и наблюдение после него.
Когда нужен rollback
Откат оправдан, если релиз создал системный дефект, а возврат проверенной версии быстрее и безопаснее локального ремонта. Примеры: массовые 5xx, глобальный noindex, отсутствие основного контента, неработающие продажи или конфигурация редиректов, которую нельзя оперативно исправить.
Не откатывайте только из-за краткосрочной смены позиций. Возврат может снова изменить URL, контент и аналитику, создав второй инцидент. До решения ответьте: что именно сломано, что вернёт старая версия, какие данные появились после запуска и как не потерять их при откате.
Почему нельзя назвать универсальный срок восстановления
Срок зависит от причины, масштаба изменений, частоты обхода, ценности страниц и конкуренции. Исправление счётчика видно после выпуска; возвращение страниц в поиск зависит от повторного обхода и обработки поисковой системой. Редирект и canonical также учитываются не мгновенно.
Подрядчик может отвечать за корректность кода, карту URL, тесты, мониторинг и скорость реакции. Он не может честно гарантировать прежние позиции к фиксированной дате.
Как закрыть инцидент
Инцидент закрыт не тогда, когда общая линия пошла вверх, а когда известна причина, исправлены затронутые URL и бизнес-сценарии, подтверждён мониторинг и обновлён процесс запуска. Добавьте найденную ошибку в обязательный checklist следующих миграций.
Для нового перезапуска используйте полный план сохранения SEO, аналитики и заявок. Если падение уже произошло и нужна независимая локализация причины, обсудите технический и SEO-аудит с BTD.TEAM.
