Манисайты вылетели после Google Core/Spam Update: как понять, лечится это или нет

Прилетел апдейт, манисайты исчезли из выдачи, в чатах коллеги пожимают плечами и советуют «ждать». Через месяц ничего не изменилось, через два — тоже. 

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

Разберем по порядку: 

• чем core-апдейт отличается от спам-апдейта, 
• как за минуту понять, есть ли санкция, 
• где искать причину, если ее нет,
• что реально делать в каждом случае, 
• и — главное — как отличить ситуацию, когда «сайт еще можно спасти», и когда «сайту хана». 

Официальную часть берем из документации Google, грей-практику — из разбора выдачи от Affiliate.FM и выводов автора канала «Эйн».

грей-практику — из канала «Эйн».

Что делают Core- и Spam-апдейты

Первое, что стоит знать: Google нигде официально не сравнивает эти два типа апдейтов между собой. Все формулировки вроде «core оценивает качество, spam ловит нарушения» — реконструкция SEO-сообщества, а не позиция поисковика. Разницу приходится собирать из двух отдельных документов, и вот что в них есть.

Core update — широкая переоценка выдачи. Google подчеркивает, что такие апдейты «broad in nature, and don’t target specific sites or individual web pages» — то есть не направлены против конкретного сайта. Официальная метафора: падение не значит, что вы плохие, — просто «другие рестораны попали в ваш топ-20».

Spam update — работа системы, которую Google называет SpamBrain и описывает как «our AI-based spam-prevention system». Здесь логика другая: не переоценка качества, а срабатывание на нарушение спам-политик.

Разница видна в том, как Google описывает восстановление:

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

А для ссылочного спама есть отдельная оговорка:

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

Как это проявляется

На практике к официальной картине добавляется еще сценарий. Кроме просадки позиций и полного исчезновения из выдачи, бывает «мигание» — сайт то появляется, то пропадает по одним и тем же запросам. 

1. Если сайт живет в цепочке переклеек — доменов, связанных каноническими тегами или редиректами, — мигание обычно значит, что поисковик пересчитывает эти связи. 
2. Для одиночного сайта мигание во время раскатки — норм. 

И в обоих случаях это не говорит о том, что вы что-то починили.

Диагностика просадки после апдейта Google

Порядок диагностики:

1. Отчет о ручных мерах в консоли вебмастера. Это главная развилка, и она занимает минуту. О ручной санкции Google сообщает в отчете о мерах, принятых вручную, и в сообщениях Search Console. Алгоритмическое понижение не сопровождается никаким уведомлением. 

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

Если санкция есть — вы увидите ее тип. В списке 16 типов, для грея актуальны «Маскировка и/или скрытая переадресация», «Искусственные ссылки на ваш сайт», «Правила в отношении злоупотребления репутацией сайта», «Бесполезный контент», «Серьезные проблемы со спамом».

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

Для ориентира — вот что происходило за последние полтора года:

Здесь важны два наблюдения:

• апдейты участились — за 2025 год их было 4 (3 core-апдейта и 1 спам-апдейт), а в 2026-м, который еще не закончился, — уже 6 (2 core-апдейта и 4 спам-апдейта); 
• спам-апдейты теперь раскатываются уже за дни, а не за недели — в 2025 году было 27 дней, в 2026-м — от 20 часов до трех суток. Окно короткое — и сопоставить просадку с датой апдейта стало проще.

3. Техника и безопасность. Отчеты о сканировании, индексировании и проблемах безопасности. Взломанный сайт с подсаженным редиректом выглядит как «упал после апдейта», хотя апдейт ни при чем.
4. Сезонность. Откройте в GoogleSearch Console график за 16 месяцев — это вся история, что там есть. А потом сравните последние три месяца с предыдущими или с тем же периодом год назад: так видно, не повторяется ли падение каждый год. Плюс проверьте, упали вы одни или вся ниша. Просели все сразу — сначала смотрите спрос в Google Trends: если он упал, дело в сезонности, а если спрос на месте, а трафик ушел у всех, виноват апдейт. 
5. Что именно вылетело. Весь домен, отдельные папки или поддомены? Если какие-то отдельные разделы — возможно, причина в них: тонкие страницы, чужой контент на поддомене (злоупотребление репутацией сайта) или же клоака на одной папке. Если ушел домен целиком — это либо санкция на весь сайт, либо конец цикла переклеек. В отчете о ручных мерах, кстати, прямо видно, на весь сайт это мера или на часть страниц.

Что арбитражнику делать после Core Update 

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

Дальше Google предлагает рамку самопроверки контента, и она сводится к трем вопросам: Who, How, Why — очевидно ли читателю, кто автор; раскрываете ли вы, как использовалась автоматизация и генерация; и главный вопрос — зачем этот контент существует. Google называет последний «perhaps the most important question»: контент должен служить людям, а не манипулировать ранжированием.

В E-E-A-T приоритет официально отдан доверию: «trust is most important. The others contribute to trust, but content doesn’t necessarily have to demonstrate all of them».

Что из этого применимо к грей-проекту: 

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

Что делать после core-апдейта, по порядку:М

1. Проверить, не техническая ли причина (это лечится быстро и дешево).
2. Оценить, просели все страницы или конкретные кластеры — если кластеры, то это чаще указывает на проблему с интентом, а не с сайтом
3. Переработать контент там, где он действительно поверхностный.

И не трогать ссылочное резкими движениями.

Что арбитражнику делать после Spam Update

Здесь логика противоположная: не надо «улучшать сайт вообще», здесь нужно искать конкретное нарушение. 

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

Спам-апдейт — это алгоритм, SpamBrain: ручных мер он не выписывает, их ставят люди и присылают отдельно, с уведомлением. Поэтому сценариев два.

Если ручной меры нет — это алгоритмическое понижение:

1. Определить, какое именно нарушение вероятно. Но без абстрактных «мы серые», а с конкретикой: ссылки, подмена контента или качество страниц.
2. Исправлять на всех затронутых страницах. Не выборочно — это провальная стратегия здесь.
3. Закрывать нарушающие страницы через noindex, а не через robots.txt. Это отдельно прописано в документации: заблокированную в robots страницу поисковик не сможет переобойти и увидеть, что вы поставили noindex.
4. Ждать и верить, потому что заявку подавать некуда: по словам Google, системам нужны месяцы, чтобы убедиться, что сайт соблюдает политики.

Если пришла ручная мера (тип проблемы называют прямо):

1. Исправлять на всех затронутых страницах. Google предупреждает: «Частичное исправление не приведет к тому, что отдельные страницы снова будут появляться в результатах поиска».
2. Подавать заявку на пересмотр. Со слов гугла же, рассмотрение «обычно занимает несколько дней или недель», а по ссылочным — дольше. Повторно не подавать, пока не пришло решение.

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

Чего НЕ делать

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

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

Не сносить контент пачками. Удаление страниц «на всякий случай» уничтожает в том числе и то, что работает нормально. Если и удалять — то сначала перепроверив данные и не доверяя одним лишь ощущениям.

Не верить цифрам из блогов. Отдельный пункт, потому что вокруг восстановления после апдейтов сложился целый жанр. В выдаче массово гуляют утверждения: «50–80% трафика возвращается за 3–6 месяцев», «полное восстановление занимает 6–12 месяцев», «декабрьский апдейт заметно сдвинул позиции 40–60% сайтов».

Не искать «волшебное восстановление за три шага». Google прямо пишет: «нет никаких гарантий, что изменения на вашем сайте заметно отразятся на результатах поиска».

Сроки и реалистичные ожидания

Официальная позиция стоит на двух китах:

1. Ждать следующего апдейта необязательно — «чтобы увидеть эффект улучшений, необязательно дожидаться крупного core-апдейта. Мы постоянно обновляем поисковые алгоритмы, в том числе выпускаем небольшие core-апдейты».
2. «Если прошло несколько месяцев, а эффекта все еще нет, возможно, придется ждать следующего core-апдейта».

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

А теперь грей-реальность

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

По данным Affiliate.FM, который с 2016 года собирает выдачу Google по казино-запросам рунета, долго в топе живут не домены, а проекты — цепочки переклеек, и новые цепочки при том живут все меньше. По запросу «казино онлайн» топ-10 держат цепочки, которые впервые зашли в выдачу в среднем больше четырех лет назад. За год до разбора только двум доменам без истории переклеек удалось попасть в топ-10 — и продержались они всего лишь 27 и 10 дней, причем оба были брендовыми сайтами, которые поисковик закинул в ротацию на волне хайпа вокруг бренда. 

Верхушка выдачи занята «старичками» 2020–2021 годов, которые переклеиваются каждые 4–15 дней. У нынешнего лидера, который в выдаче с 2021 года, сейчас около тысячи дней и сотни переклеек. Новичкам с 2023 года в топ-1 не пролезить — максимум 3–5-е место. За 2025 год, например, ни одна свежая цепочка не прожила там и 90 дней, а половина из них так вообще умирает быстрее чем за месяц. По «топ казино» картина мягче: там в 2025-м одна свежая цепочка все-таки продержалась 97 дней.

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

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

Как выглядит короткий цикл, видно на Нидерланском кейсе, который репостнул и откомментировал «Эйн»: покупается сильный дроп, за месяц-два его заливают спам-ссылками под нужную тематику, затем на страницах дропа ставят rel=canonical, указывающий на свежий домен. И накопленный вес уходит туда. 

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

Практический вывод

Если ваш сайт работал по такой модели, «восстановление» — неправильная рамка. Он не сломался, а грубо говоря, просто закончился по расписанию, и чинить в нем просто-напросто нечего. Правильнее тут будет спросить себя не «как вернуть сайт», а «сколько стоит следующий заход и окупается ли модель целиком». Соответственно и планировать надо не восстановление, а окупаемость портфеля и запас доменов.

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

Чек-лист действий после апдейта

Пока идет раскатка — только диагностика

1. Открыть отчет о ручных мерах. Пусто — падение алгоритмическое, заявку подать нельзя.
2. Сверить дату просадки с официальным дашбордом апдейтов.
3. Проверить технику: сканирование, индексирование, безопасность.
4. Проверить, упали вы одни или вся ниша.
5. Ничего не менять.

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

1. Оценить масштаб: весь домен, отдельные папки, отдельные кластеры запросов.
2. Определить тип апдейта — core или spam — и работать по соответствующему сценарию.
3. При ручной санкции — прочитать ее тип, он называет проблему.

Работа по core

1. Найти действительно слабые страницы, а не резать наугад.
2. Проверить соответствие контента интенту запросов, по которым просели.
3. Не трогать ссылочное резко.

Работа по spam

1. Сверить сайт со списком спам-политик, найти конкретное нарушение.
2. Исправить на всех затронутых страницах, не выборочно.
3. Нарушающие страницы закрывать через noindex, не через robots.txt.
4. Если ручной меры нет — ждать месяцы, заявку подавать некуда. Если есть, тогда заявка на пересмотр, повторно ее до решения подавать не надо.

Стратегическая развилка

1. Ответить честно: сайт строился вдолгую или это цикловой проект?
2. Если цикловой — считать не восстановление, а стоимость следующего захода.
3. Если вдолгую — заложить месяцы и отсутствие гарантий.

Куда двигаться дальше

• Апдейты Google в 2025 году — что менялось в алгоритмах.
• Что такое линкбилдинг — база по ссылочному профилю.
• Сервисы индексации 2026 — переобход после правок.