Как читать Search Console во время core update Google

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

Панель статуса Google Search указывает, что core update ноября 2026 года началось 10 ноября и всё ещё разворачивалось, когда я выгружал данные. Сам Google советует после завершения core update подождать минимум полную неделю перед анализом и сравнивать с периодом до его начала. Я так и делаю, и вот точная процедура.

Шаг 1: зафиксируйте базовую линию, прежде чем смотреть на обновление

Откройте отчёт «Эффективность» в Search Console и выставьте диапазон на 14 дней до даты начала обновления. Выгрузите клики, показы, CTR и среднюю позицию по дням. Этот файл и есть ваша базовая линия, и вы сохраняете его до того, как прочтёте хоть одну цифру после обновления.

Вот моя, из Search Console моего собственного сайта:

Разброс от 228 до 393 без всякого обновления — вот цифра, которая важна. Если вы не знаете собственного разброса, вы не отличите core update от обычного вторника.

Шаг 2: запишите, что ещё изменилось

На core update списывают то, чего она не делала. Прежде чем что-либо сравнивать, перечислите, что изменилось с вашей стороны за тот же период: миграция, смена шаблона, пачка новых страниц, правка robots или noindex, правило редиректа. Если список не пуст, обновление — не единственный подозреваемый.

Проверьте и то, не искажает ли общую линию одна страница. 28 октября мои суммарные показы за день выросли с 24 498 до 131 686, потому что одну страницу показывали намного чаще. Этот случай я разбирал в материале что я проверяю, когда показы взлетают, а CTR падает. У среднего по сайту во время core update та же слабость.

Шаг 3: дождитесь конца развёртывания, потом ещё неделю

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

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

Шаг 4: сравнивайте равные периоды и режьте четырьмя способами

Когда сработает напоминание, сравните 14 дней после завершения с замороженной 14-дневной базой. Та же длина, те же дни недели. Затем разложите разницу:

1. По страницам. Выгрузите вкладку «Страницы» для обоих периодов. Отсортируйте по изменению кликов. В большинстве просадок, которые я разбирал, основную часть объясняют пять-десять страниц.
2. По запросам. Для каждой такой страницы посмотрите, по каким запросам ушли клики и дело в позиции или в CTR. Падение с 4-й позиции на 9-ю — это изменение ранжирования. Стабильная позиция при падающем CTR — проблема сниппета или элементов выдачи, о ней в материале почему ваши лучшие по позициям страницы не получают кликов.
3. По странам. Core update может сильнее ударить по одному рынку, чем по другому, особенно на мультиязычных сайтах.
4. По устройствам. Потеря только на мобильных указывает на удобство страницы, а не на релевантность.

Если изменение укладывается в ваш обычный разброс из шага 1, объяснять нечего: эффекта обновления нет. Остановитесь и продолжайте публиковать.

Шаг 5: только теперь решайте, что менять

Подберите исправление под тип потери:

• Потеря позиций у нескольких страниц: сравните их со страницами, которые теперь выше вас. Они отвечают на запрос быстрее, с более конкретными деталями, из первых рук? Перепишите свою так же. Не раздувайте её.
• Потеря позиций везде: это оценка качества на уровне сайта, и она меняется медленно. Удалите или объедините страницы, которые не заслуживают места, и улучшите те, что заслуживают. Ждите месяцы, а не дни. Google говорил, что улучшения могут проявляться со временем, а для более значительного восстановления может понадобиться следующее core update.
• Прирост позиций: запишите, какие страницы и почему. Это ваш шаблон того, что Google сейчас поощряет на вашем сайте.

Для страниц, которые съехали на вторую страницу, а не рухнули, подходит процедура из как вытащить страницы, застрявшие на второй странице. Если потеря видна и в GA4, вторую половину закрывает как диагностировать падение трафика в Google Analytics.

Промпт, который я вставляю в Claude или ChatGPT

Выгрузите вкладку «Страницы» для базового периода и для периода после обновления в два CSV и вставьте оба:

Вот две выгрузки Google Search Console по страницам. Файл A — 14 дней до
начала core update Google. Файл B — 14 дней после окончания развёртывания.
Та же длина, те же дни недели.

1. Перечисли 15 страниц с наибольшим изменением кликов, вверх или вниз, с
   изменением в абсолютных кликах и в процентах.
2. Скажи, какую долю общего изменения кликов объясняют эти 15 страниц.
3. Отметь любую страницу, где клики изменились, а показы нет, потому что
   это указывает на CTR, а не на ранжирование.
Покажи арифметику. Если числа нет в данных, так и скажи, а не оценивай.
Пока не предлагай изменений контента.

Проверьте одну строку вручную, прежде чем доверять остальному. Эти модели уверенно округляют и иногда ошибаются в доле.

Если не хочется выгружать CSV для каждого клиента, я сделал SiteWide, чтобы подтягивать Search Console и GA4 в Claude именно для такого сравнения. В любом случае дисциплина одна: сначала база, потом терпение, изменения в последнюю очередь. Для шага с промптом я использую Claude.

Мои цифры взяты из моего собственного ресурса Search Console за период с 15 октября по 11 ноября 2026 года: 7 472 клика и 1 108 401 показ за 28 дней. Слишком рано говорить, помогло обновление этому сайту или навредило, и я узнаю это, только когда развёртывание завершится и пройдёт неделя ожидания.