Кейс: трафик упал на 38% — разбор инцидента по часам

Что известно и что можно рассказать

Компания среднего размера с каталогом услуг и работ, региональное присутствие в нескольких городах. По условиям соглашения не раскрываем отрасль, домен и город — приводим только хронологию и цифры динамики, согласованные к публикации.

Обратились с формулировкой «поисковый трафик падает третью неделю, подрядчик разводит руками». К моменту обращения органика просела на 38% относительно среднего значения предыдущих трёх месяцев. Реклама работала штатно, поэтому общая посещаемость упала не так драматично, и проблему заметили не сразу.

День первый: ложный след

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

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

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

День второй: отчёт, который расставил всё по местам

Пошли в отчёт «Страницы в поиске» Яндекс Вебмастера, раздел исключённых страниц. Картина стала очевидной: около 1 900 страниц каталога помечены как «запрещены к обходу файлом robots.txt». Дата массового исключения совпадала с началом падения.

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

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

Почему восстановление заняло пять недель

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

Выпадение из индекса происходит быстро. Робот увидел запрет, применил его ко всему разделу за несколько обходов — три дня, и раздел исключён.

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

Полное восстановление позиций по части высокочастотных запросов заняло дольше — около двух месяцев, и несколько позиций не вернулись на прежние места вовсе: их за это время заняли конкуренты.

Во что обошлась ошибка

Считать убыток в деньгах клиент попросил не публиковать. Приведём то, что можно: за три недели до обращения и пять недель восстановления суммарно потеряно около 40% органического трафика за период. Часть спроса ушла к конкурентам и не вернулась автоматически.

Отдельная цена — доверие внутри компании: маркетинг три недели объяснял руководству падение, не понимая причины, и это выглядело как некомпетентность там, где была чужая техническая ошибка.

Что теперь делаем в первый день любого проекта

• Мониторинг robots.txt. Ежедневная проверка доступности файла и его содержимого, уведомление при любом изменении. Настраивается за 10 минут, стоит ноль.
• Контроль числа страниц в индексе. Резкое изменение — сигнал раньше, чем упадёт трафик.
• Чек-лист после любого переноса. robots.txt, карта сайта, коды ответа, редиректы, счётчики — проверяются отдельно, а не «открыли главную, вроде работает».
• Уведомления Вебмастера на рабочую почту тех, кто действительно их читает.

Технические причины подобных падений разбираем отдельно в материале про техническое состояние сайта.

Алгоритм поиска причины: по какому порядку идти

Мы пошли по ложному следу, потому что начали с гипотезы вместо проверки фактов. Порядок, который экономит дни:

1. Индекс (10 минут). Панель вебмастера, раздел со страницами в поиске. Сравните число страниц в индексе неделю назад и сейчас. Если оно упало — трафик потерян из-за исчезновения страниц, и дальше искать нужно причину исключения, а не проблемы с позициями.

2. Причины исключения (10 минут). Там же указано, почему страницы выпали: запрет в robots.txt, ошибка сервера, дубль, метатег noindex. Эта строка обычно и содержит ответ, но её пропускают, потому что смотрят на графики, а не на таблицы.

3. Доступность (5 минут). Проверьте главные страницы инструментом проверки ответа сервера. Код 200 и текст в ответе — норма. Код 5xx или пустой ответ означает проблему хостинга, а не продвижения.

4. История изменений на сайте (20 минут). Спросите разработчиков: что выкладывалось за последние две недели? Дата выкладки почти всегда совпадает с началом падения на графике — это самая быстрая проверка гипотезы.

5. И только потом — внешние причины. Обновление алгоритмов, сезонность, конкуренты. Мы начали именно с них и потеряли день.

Практический смысл порядка: сначала проверяется то, что зависит от вас и проверяется за минуты, и лишь затем — то, на что вы не влияете.

Чек-лист перед выкладкой, который закрыл бы эту проблему

Инцидент стоил пяти недель восстановления. Предотвратить его можно было списком из семи пунктов, который проходится за 15 минут.

Ключевая деталь: проверка делается на боевом сайте после выкладки, а не на тестовом до неё. Запрет индексации был правильным на тестовой площадке — ошибкой стало то, что он уехал вместе с остальными файлами и никто не посмотрел итог.

Второй момент — кто проверяет. Если это тот же человек, который выкладывал, он смотрит на свою работу и видит то, что ожидает увидеть. Список должен проходить кто-то другой, пусть даже по формальным пунктам.

Как узнавать о таком за час, а не за неделю

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

Оповещение о падении трафика. В системе аналитики настраивается уведомление: если визиты за сутки упали больше чем на 20% к среднему за две недели — письмо. Настраивается один раз, ловит не только этот сценарий, но и упавший сервер, и слетевший счётчик.

Слежение за файлом robots.txt. Простейший вариант — бесплатный сервис проверки доступности с проверкой содержимого страницы: раз в час запрашивает файл и сообщает, если текст изменился. Второй вариант — уведомления в панели вебмастера, они приходят с задержкой, но приходят.

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

Стоимость всей этой обвязки — ноль рублей и час настройки. На фоне пяти недель потерянного трафика соотношение очевидное, но занимаются этим обычно уже после первого инцидента.

#!/bin/bash
# Запускать после выкладки. Ловит ошибку, которая в этом кейсе
# стоила пяти недель восстановления.
SITE="https://example.ru"

echo "— robots.txt —"
curl -s "$SITE/robots.txt" | grep -E "^Disallow: /$" \
  && echo "ТРЕВОГА: закрыт весь сайт" || echo "ок"

echo "— noindex на главной —"
curl -s "$SITE/" | grep -qi "noindex" \
  && echo "ТРЕВОГА: запрет индексации в коде" || echo "ок"

echo "— ответы ключевых страниц —"
for URL in "/" "/catalog/" "/contacts/"; do
  CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE$URL")
  echo "$URL → $CODE"
done

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

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

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