Не начинайте с исправлений
Первое желание после просадки — переписать тексты, закрыть страницы или быстро изменить robots. Это делает диагностику сложнее: команда одновременно меняет данные, по которым пытается понять причину. Рабочий первый шаг — сохранить исходный срез и зафиксировать дату, на которой началось изменение.
В отчёте Performance Search Console доступны клики, показы, CTR и средняя позиция, а также срезы по запросу, странице, стране, устройству и типу поиска. Сравнивать стоит завершённые сопоставимые периоды: свежие дни могут быть предварительными, а недельная или месячная агрегация помогает не принять обычную сезонность за инцидент.
Разложите изменение на сегменты
| Срез | Вопрос | Что это даёт |
|---|---|---|
| Страницы | Какие URL или разделы изменились сильнее остальных? | Отделяет проблему одного шаблона, каталога или раздела от изменения по всему сайту. |
| Запросы | Исчезли ли темы, бренды, типы спроса или только отдельные формулировки? | Помогает не путать изменение спроса с технической ошибкой. |
| Устройства и страны | Повторяется ли сдвиг на mobile и desktop, во всех нужных регионах? | Указывает, где искать: в шаблоне, доступности, локальном спросе или разметке. |
| Тип поиска | Изменились Web, Image, Video или Discover? | Не смешивает разные поверхности Google в одну «среднюю» проблему. |
| Дата | Что менялось на сайте, сервере или в данных около начала сдвига? | Формирует проверяемые гипотезы вместо списка случайных правок. |
Четыре группы проверяемых причин
- Данные и спрос. Убедитесь, что сравниваются одинаковые типы поиска и завершённые периоды. Сезонность, новости, изменение спроса и различия в методике метрик могут дать заметный сдвиг без поломки сайта.
- Индексирование и доступность. Для затронутых URL проверяются код ответа, рендеримый контент, `robots`, canonical, sitemap, важные ресурсы и ошибки сервера. Полезная страница, которая для робота выглядит пустой или ошибочной, требует другой работы, чем страница с изменившимся спросом.
- Релизы и структура. Проверяются даты миграций, изменения шаблонов, URL, внутренних ссылок, навигации, контента и серверной конфигурации. Факт совпадения даты — повод проверить гипотезу, но не доказательство причины.
- Изменения выдачи. Google прямо отмечает, что алгоритмические обновления и другие изменения ранжирования могут менять результаты. Это не означает, что нужно немедленно «оптимизировать под апдейт»: сначала нужно увидеть, какие страницы и интенты реально затронуты.
Как оформить результат, чтобы по нему можно было принять решение
Вместо вывода «сделаем SEO и всё вернётся» полезен список наблюдений: какой период сравнили, какие сегменты затронуты, какие URL проверены, что доказано, что остаётся гипотезой и какие данные ещё нужны. Для каждого предлагаемого изменения отдельно нужны preview, оценка риска, стоимость и сценарий rollback.
Например, обнаруженный некорректный status code или цепочка редиректов — это конкретная техническая гипотеза с проверкой. А снижение показов по широким небрендовым запросам без технической аномалии — не повод автоматически удалять страницы. Здесь сначала анализируют соответствие интенту, фактическое качество документа, конкурентную поверхность и спрос.
Безопасный порядок работы
- Сохранить baseline и сформулировать период сравнения.
- Выделить затронутые сегменты и приоритетные URL.
- Проверить технические факты и историю релизов без изменения production.
- Собрать список гипотез с доказательствами и неопределённостями.
- Показать владельцу preview каждого действия, риск, стоимость и rollback.
- Вносить только явно согласованные изменения и после них повторить тот же срез.
Чего диагностика не обещает
- она не гарантирует возврат позиций, трафика, лидов или сроков переобхода;
- она не даёт право автоматически менять контент, redirects, canonical, robots, DNS, SSL, CMS или сервер;
- она не подменяет проверяемую причину совпадением даты с внешней новостью или обновлением поиска;
- она не собирает доступы и персональные данные в чате — их вводят только в защищённые формы после согласования.
С чего начать
Если изменение уже видно в данных, подходит диагностика и восстановление видимости: она начинается с доказательного среза и плана, а не с автоматических правок. Если проблема связана с готовящимся переездом, сначала нужен контур SEO-сопровождения миграции. Любое изменение сайта требует отдельного подтверждения владельца.
Первичные источники
- Google: Debugging drops in Google Search traffic — порядок исследования падения и возможные классы причин.
- Google Search Console: Performance report — метрики и разрезы отчёта.
- Google Search Console: advanced filtering and comparison — правила сравнений и ограничения интерпретации.
- Google: troubleshooting crawling errors — статусы, soft 404 и проверка фактического ответа страницы.
Частые вопросы
Как понять, что падение действительно произошло?
Сначала сравнивают сопоставимые завершённые периоды в Search Console и разбивают изменение по страницам, запросам, устройствам и странам. Один неполный день или одна средняя позиция не доказывают проблему: в свежих данных возможны предварительные значения, а агрегированные метрики имеют ограничения.
Нужно ли сразу переписывать страницы?
Нет. До изменения нужно подтвердить, какой именно сегмент изменился и что произошло около даты сдвига: релиз, ошибка доступности, изменение индексации, спроса или представления в поиске. Сначала формулируется проверяемая гипотеза, затем готовится preview изменения, оценка риска и rollback.
Можно ли гарантировать восстановление видимости?
Нет. Диагностика уменьшает неопределённость и позволяет устранить подтверждённые управляемые проблемы, но не гарантирует позиции, трафик, сроки переобхода или решение поисковой системы.