Что делать после Google Core Update
Что делать после Google Core Update
Google несколько раз в год выпускает крупные core updates и постоянно вносит меньшие изменения в ranking systems.
Если трафик упал рядом с датой core update, это еще не доказывает, что именно update является причиной. Сначала нужно отделить алгоритмическое изменение от технического сбоя, сезонности, изменений спроса и проблем самого сайта.
Главное правило
Не начинать с массового переписывания сайта.
Нормальная последовательность:
зафиксировать период
↓
проверить технические проблемы
↓
сравнить Search Console до/после
↓
определить масштаб падения
↓
найти тип страниц/запросов, где изменилась видимость
↓
только затем искать содержательную причину
1. Проверить дату и статус update
Сначала откройте официальный Google Search Status Dashboard и проверьте:
- действительно ли в этот период шел core update;
- когда rollout начался;
- когда Google объявил его завершенным.
Не стоит сравнивать день внутри rollout с предыдущим днем: выдача еще может меняться.
Google рекомендует после завершения rollout дать данным стабилизироваться и затем сравнивать периоды.
2. Исключить техническую аварию
До анализа качества контента проверьте базовые вещи.
Индексация
noindex;- robots.txt;
- canonical;
- HTTP status;
- массовые redirects;
- ошибки sitemap;
- accidental staging rules;
- изменение шаблона.
Доступность
curl -I https://example.com/
Проверить несколько важных URL:
for url in \
https://example.com/ \
https://example.com/category/ \
https://example.com/important-page/
do
echo "=== $url"
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' "$url"
done
Search Console
Посмотрите:
- Page indexing;
- Manual actions;
- Security issues;
- Crawl stats;
- Performance.
Если одновременно с update сайт начал отдавать 5xx или потерял canonical/indexability, core update может быть просто совпадением по времени.
3. Сравнить корректные периоды
В Search Console используйте Compare.
Лучше сравнивать одинаковые по длине периоды:
7 дней после стабилизации
vs
7 дней до начала update
Для сезонного сайта полезно дополнительно сравнить год к году.
Не смешивайте сразу все Search types.
Разберите отдельно:
- Web;
- Images;
- Video;
- News, если применимо.
4. Определить: impressions, clicks или position
Четыре базовых сценария.
Impressions упали, position упал
Вероятно, страницы стали реже показываться на прежних позициях или потеряли запросы.
Impressions те же, clicks упали
Проверить:
- CTR;
- изменение SERP;
- AI Overviews/AI Mode;
- новые rich features;
- title/snippet;
- изменение интента.
Position примерно тот же, impressions упали
Возможны:
- сезонность;
- снижение спроса;
- изменение query mix.
Clicks выросли при меньшем числе impressions
Это не обязательно проблема: видимость могла стать более сфокусированной на релевантных запросах.
5. Малое и большое падение — разные стратегии
Google приводит характерный пример.
Небольшое падение вроде:
позиция 2 → 4
не является причиной срочно переписывать хорошо работающую страницу.
Сильное устойчивое падение вроде:
позиция 4 → 29
уже требует глубокой проверки сайта и контента.
6. Найти кластер проблемы
Не анализируйте только домен целиком.
Разбейте падение по:
- типу страницы;
- каталогу;
- шаблону;
- автору;
- дате публикации;
- интенту;
- стране;
- устройству;
- query class.
Пример:
/hosting/* -5%
/blog/* -7%
/reviews/* -48%
Тогда проблема, скорее всего, не «Google наказал весь сайт», а связана с конкретным типом контента.
7. Сравнить страницы и запросы до/после
В Search Console выгрузите URL и запросы.
Ищите:
- страницы с крупнейшей потерей clicks;
- страницы с крупнейшей потерей impressions;
- запросы, где position изменилась сильнее всего;
- новые страницы конкурентов;
- изменение типа результатов в SERP.
Не ограничивайтесь топ-10 страницами: иногда падение создают тысячи long-tail URL.
8. Проверить изменение интента
Даже хороший материал может потерять позиции, если Google стал иначе понимать запрос.
Например выдача могла измениться с:
информационные статьи
на:
категории магазинов / сервисы / видео / форумы
В таком случае бесконечное улучшение текста может не вернуть прежнюю позицию: формат страницы перестал соответствовать dominant intent.
9. Self-assessment контента
При большом устойчивом падении Google предлагает оценивать сайт целиком, а не пытаться найти одну «штрафную» строку.
Практические вопросы:
Оригинальность
- Есть ли собственные данные?
- Есть ли личный опыт?
- Есть ли тесты, измерения, скриншоты?
- Добавляет ли материал что-то сверх пересказа других источников?
Достоверность
- Есть ли первоисточники?
- Можно ли проверить утверждения?
- Отделены ли факты от предположений?
- Актуальна ли информация?
Полезность
- Решает ли страница задачу пользователя?
- Нет ли длинного вступления ради объема?
- Есть ли конкретный вывод/инструкция?
- Не создан ли текст только ради поискового запроса?
UX
- Нет ли агрессивной рекламы?
- Не закрывает ли popup основной контент?
- Удобна ли мобильная версия?
- Нет ли технических ошибок при взаимодействии?
10. AI-generated content — не отдельная причина автоматически
Наличие AI в процессе создания материала само по себе не означает нарушение.
Проблема возникает, если автоматизация приводит к масштабному созданию малоценного контента, манипуляции выдачей или другим нарушениям spam policies.
Поэтому вопрос должен быть не:
"этот текст написал AI?"
а:
"эта страница реально полезна, точна, оригинальна и создана для пользователя?"
11. Не искать «один фактор Core Update»
Core update — широкое изменение систем ранжирования, а не список вида:
+10 к E-E-A-T
-20 за AI
+5 за FAQ
Попытки найти одну магическую причину часто приводят к ненужным изменениям.
12. Не удалять массово контент без анализа
После падения иногда советуют:
- удалить половину сайта;
- noindex старых страниц;
- переписать все через другой AI;
- поменять даты публикаций;
- добавить тысячи слов.
Такие изменения опасны без сегментации данных.
Сначала определите, какие страницы действительно имеют проблему.
13. Малые core updates происходят постоянно
В 2026 году Google отдельно уточнил документацию: между публично объявленными крупными core updates происходят меньшие core changes.
Практическое следствие:
После реальных улучшений не обязательно ждать следующего объявленного major core update, чтобы увидеть изменение позиций.
Но нет гарантии ни срока, ни масштаба восстановления.
Google может переоценить часть сигналов раньше, часть позже.
14. Как оценивать изменения после исправлений
Не менять десять вещей каждый день.
Лучше вести журнал:
| Дата | Изменение | URL/раздел | Причина | Метрика до | Что проверить |
|---|---|---|---|---|---|
| 2026-08-01 | Обновлены источники | /guides/* | устарели данные | clicks | 28 дней |
| 2026-08-05 | Исправлен canonical | /catalog/* | duplicate cluster | indexed URL | 2 недели+ |
Так можно отличить эффект изменения от обычного шума.
15. Чего не делать
Не менять content только ради изменения
Google прямо предупреждает против радикальных изменений для страниц, которые и так работают хорошо.
Не обещать себе «recovery через X дней»
Переоценка не имеет фиксированного SLA.
Не ориентироваться только на сторонний visibility score
Сначала Search Console и реальный бизнес-трафик.
Не путать core update с manual action
Manual action отображается отдельно в Search Console.
Не верить спискам «200 факторов, которые изменились вчера» без источников
Официальный core update не сопровождается полным раскрытием ranking weights.
Быстрый алгоритм
1. Был ли официальный update?
↓
2. Rollout уже завершился?
↓
3. Нет ли 5xx/noindex/robots/canonical проблемы?
↓
4. Что упало: clicks/impressions/position?
↓
5. Какие page/query clusters пострадали?
↓
6. Изменился ли SERP intent?
↓
7. Малое падение или крупное устойчивое?
↓
8. Для крупного — site-wide content self-assessment
↓
9. Внести обоснованные изменения
↓
10. Измерять, а не продолжать хаотично переписывать
Чек-лист
- [ ] Проверить Search Status Dashboard.
- [ ] Зафиксировать даты rollout.
- [ ] Проверить 5xx, robots, noindex и canonical.
- [ ] Проверить Manual Actions и Security Issues.
- [ ] Сравнить одинаковые периоды Search Console.
- [ ] Разделить Web / Images / Video / News.
- [ ] Отдельно посмотреть clicks, impressions, CTR и position.
- [ ] Найти page clusters с максимальным изменением.
- [ ] Найти query clusters с максимальным изменением.
- [ ] Проверить изменение search intent и SERP features.
- [ ] Для крупного падения провести self-assessment всего сайта.
- [ ] Не менять хорошо работающие страницы без причины.
- [ ] Записывать внесенные изменения и дату.
- [ ] Проверять результат на достаточно длинном периоде.