Сайт просел после релиза: разбор кейса

Примечание редакции: это учебный составной кейс, собранный из типовых ошибок при изменении структуры сайта. Он не описывает конкретного клиента и не содержит придуманных коммерческих результатов. Его задача — показать ход расследования. Для публикации настоящего клиентского кейса нужны реальные даты, графики и подтверждённые цифры.

Интернет-магазин обновил каталог: категории получили короткие адреса, меню стало удобнее, дизайн — современнее. Релиз прошёл без заметных ошибок, заказы оформлялись. Через несколько дней органический трафик на категории начал снижаться, а важные запросы потеряли позиции.

Первая гипотеза команды: обновился поисковый алгоритм. Вторая: новый текст категорий оказался хуже. Обе звучали правдоподобно — и обе появились до проверки фактов.

Разберём, как из симптома «SEO упало» прийти к проверяемой технической причине.

Исходная ситуация

До релиза категории имели адреса:

https://example.ru/catalog/office-chairs/
https://example.ru/catalog/desks/

После релиза:

https://example.ru/office-chairs/
https://example.ru/desks/

Контент и ассортимент в основном сохранились. Для старых URL разработчики настроили 301-редиректы. На поверхностном уровне всё выглядело правильно: старый адрес открывал новую категорию, новый отвечал кодом 200.

Симптомы:

• главная страница и блог почти не изменились;
• сильнее всего просели запросы категорий;
• часть карточек продолжала получать трафик;
• в результатах проверки периодически появлялись старые URL;
• платный трафик и прямые заходы работали нормально.

Уже эта картина говорила: вероятнее локальная проблема шаблона или миграции, а не наказание всего домена.

Шаг 1. Зафиксировали момент и масштаб

До любых исправлений команда записала:

• точное время релиза;
• затронутые шаблоны;
• старые и новые URL;
• динамику кликов, показов и конверсий;
• позиции по группам запросов;
• изменения в robots.txt, sitemap и аналитике.

Затем данные разделили по типам страниц. Это важно: общий график магазина смешивает категории, товары, статьи и брендовый спрос. После сегментации стало видно, что основное отклонение связано с категориями, адреса которых изменились.

Первый вывод:

Ищем причину в миграции категорий. Глобальные гипотезы откладываем, пока локальная не опровергнута.

Шаг 2. Проверили, что проблема не в измерении

Перед техническим расследованием нужно исключить поломку аналитики.

Команда проверила:

• загружается ли счётчик на новых шаблонах;
• не изменился ли идентификатор свойства;
• работают ли цели и электронная коммерция;
• не появился ли двойной счётчик;
• совпадает ли снижение аналитики с кликами в панелях вебмастеров;
• изменились ли позиции в независимом замере.

Клики и позиции тоже снизились. Значит, проблема не ограничивалась потерянным счётчиком.

Практическое правило:

• трафик упал только в аналитике → сначала проверяем измерение;
• клики в вебмастере тоже упали → исследуем поиск и страницы;
• позиции стабильны, а кликов меньше → проверяем спрос, сниппеты и элементы выдачи;
• позиции и клики снизились в одном разделе после релиза → проверяем изменённый шаблон.

Рекомендуем инструмент ITSEO

Инструмент сравнения текстов и кода (Diff Checker)

Сравните код страницы или текст до и после релиза, чтобы мгновенно найти удалённые теги, canonical или слетевшие стили.

Сравнить версии страниц

Шаг 3. Повторили съём позиций по тем же настройкам

В проверке позиций ITSEO использовали тот же проект, регион, устройство и набор запросов, что до запуска.

Важным оказался не только минус в позиции, но и колонка релевантного URL:

• часть запросов показывала новый адрес;
• часть — старый;
• по некоторым запросам URL менялся между проверками.

Это типичный сигнал конфликтующих страниц или сигналов канонизации. Если бы релевантный URL оставался стабильным, расследование сильнее сместилось бы в сторону контента и выдачи.

Шаг 4. Проверили редиректы

Старые адреса прогнали через проверку редиректов ITSEO.

Базовая схема была корректной:

старый URL → 301 → новый URL → 200

Цепочек и циклов не нашли. Это исключило очевидную ошибку, но не доказало, что миграция настроена полностью. Редирект — только один из сигналов.

Проверили также варианты:

• HTTP и HTTPS;
• www и без www;
• слеш и отсутствие слеша;
• URL с рекламными параметрами;
• вложенные страницы пагинации;
• карточки товаров внутри старых категорий.

Несколько технических вариантов давали лишний промежуточный переход, но он не объяснял основное падение. Эти цепочки записали в задачи, не подменяя ими корневую причину.

Шаг 5. Проверили новые URL как отдельные страницы

Для новых категорий последовательно посмотрели:

1. HTTP-код — 200.
2. robots.txt — обход разрешён.
3. meta robots — index, follow.
4. основной контент — присутствует в серверном HTML.
5. canonical — и здесь обнаружился конфликт.

Новый шаблон продолжал генерировать canonical по старой структуре:

<!-- На новой странице /office-chairs/ -->
<link rel="canonical" href="https://example.ru/catalog/office-chairs/">

Получилась противоречивая схема:

старый URL --301--> новый URL
новый URL --canonical--> старый URL

Редирект говорил: «постоянный адрес теперь новый». Canonical на новой странице говорил: «основной адрес — старый». Старый при этом уже не отдавал самостоятельный контент.

Один неверный шаблон затронул все изменённые категории и хорошо объяснял масштаб проблемы.

Шаг 6. Проверили остальные источники URL

Найдя одну причину, опасно сразу заканчивать расследование. Один и тот же генератор старых адресов мог использоваться в других местах.

Аудит сайта ITSEO и выборочная ручная проверка показали ещё два связанных дефекта:

• новый sitemap содержал смесь старых и новых категорий;
• часть ссылок в мобильном меню всё ещё вела на старые адреса.

В десктопном меню ссылки уже были обновлены. Это объясняло, почему мобильный срез выглядел хуже: робот и пользователи чаще проходили через старые URL и дополнительный редирект.

Получилась не одна «магическая ошибка», а единый класс проблемы: источник URL обновили не во всех компонентах.

Шаг 7. Сформулировали исправление до внесения правок

Команда записала ожидаемое состояние:

• каждый старый URL делает один 301-переход на соответствующий новый;
• каждый новый URL отвечает 200;
• canonical нового URL указывает на него самого;
• sitemap содержит только новые канонические страницы;
• desktop- и mobile-навигация ведут сразу на новые адреса;
• структурированные данные и Open Graph используют новый URL;
• старые адреса отсутствуют в новых внутренних ссылках.

Такой список важнее формулировки «починить canonical», потому что позволяет тестировать результат.

Шаг 8. Исправили источник, а не отдельные страницы

Canonical исправили в общем шаблоне категории. Генератор sitemap и компонент мобильного меню перевели на единый источник маршрутов. Старые URL оставили только в таблице редиректов.

Не стали:

• переписывать тексты категорий;
• добавлять ключевые слова;
• массово менять title;
• отправлять сотни URL на переобход до исправления;
• откатывать весь дизайн.

Эти действия не соответствовали найденной причине и добавили бы новые переменные.

Шаг 9. Проверили релиз исправления

После выкладки команда протестировала выборку каждого типа:

Для сравнения HTML до и после удобно использовать Diff checker ITSEO: он помогает убедиться, что исправился нужный фрагмент, а соседние элементы шаблона не изменились случайно.

Шаг 10. Дождались повторного обхода и наблюдали

Исправление на сервере не означает мгновенное восстановление поиска. Робот должен повторно посетить старые и новые страницы, обработать редиректы и согласовать канонические адреса.

После релиза исправления:

• отправили новый sitemap;
• запросили переобход ограниченной выборки важных категорий;
• ежедневно проверяли небольшое контрольное ядро;
• следили за индексированием старых и новых URL;
• не вносили несвязанных массовых изменений.

Ожидаемый признак восстановления — не одна удачная позиция, а последовательная картина: новые URL выбираются как релевантные, старые постепенно исчезают, показы и позиции категорий стабилизируются.

В настоящем кейсе сюда нужно добавить реальный график и период восстановления. В учебном разборе намеренно нет процентов и обещаний срока: скорость переобхода зависит от размера сайта, частоты обхода и состояния проекта.

Почему первоначальные гипотезы были слабее

«Это обновление алгоритма»

Не объясняло точное совпадение с релизом и локальность по одному изменённому шаблону.

«Новый дизайн хуже»

Возможно, но требовало данных поведения и конверсии. Не объясняло появление старых релевантных URL.

«Нужно больше текста»

Контент почти не менялся, а технические сигналы противоречили друг другу. Увеличение объёма не исправляет canonical.

«301 настроен, значит переезд сделан»

Редирект был верным, но sitemap, внутренние ссылки и canonical не были согласованы.

Универсальный алгоритм после релиза

Этот порядок дополняет еженедельный регламент мониторинга. Если релиз связан со сменой адресов, до запуска также нужен полный чек-лист переезда сайта.

1. Отметьте дату изменения на графиках.
2. Проверьте аналитику и реальные пользовательские сценарии.
3. Определите масштаб: сайт, раздел, шаблон, поисковик, устройство.
4. Сравните позиции и релевантные URL по неизменным настройкам.
5. Проверьте HTTP-коды и редиректы.
6. Проверьте robots, noindex, canonical и серверный HTML.
7. Сверьте sitemap и внутренние ссылки.
8. Найдите одно изменение, которое объясняет весь паттерн.
9. Запишите ожидаемое состояние и исправьте источник дефекта.
10. Протестируйте выборку и наблюдайте до повторного обхода.

Что добавить в процесс разработки

Чтобы такой инцидент не повторился, включите в приёмку релиза автоматические или ручные проверки:

• canonical на каждом ключевом шаблоне;
• отсутствие production-noindex;
• карта старых и новых URL;
• один переход до финального адреса;
• только канонические URL в sitemap;
• отсутствие старого домена и путей во внутренних ссылках;
• сравнение HTML контрольных страниц;
• базовый замер позиций и индексации до релиза.

SEO-контроль должен происходить до переключения, а не после первого падения.

Главный вывод

Просадка после релиза — не диагноз. Диагнозом становится проверенная связь между изменением и наблюдаемым паттерном.

В этом учебном кейсе ключевой уликой была смена релевантных URL. Она привела к проверке canonical, а затем — к sitemap и мобильному меню. Команда исправила общий источник адресов, не стала хаотично переписывать контент и получила измеримый план проверки.

Если проблема появилась после обновления, начните с съёма позиций и URL, затем проверьте редиректы, индексацию и шаблон через аудит сайта. Чем точнее локализован симптом, тем меньше ненужных изменений придётся сделать.

Источники и полезные материалы

• Google: диагностика падения поискового трафика
• Google: перенос сайта с изменением URL
• Яндекс: решение проблем с позициями сайта
• Яндекс: canonical