Google March 2026 Core Update: почему 43% сайтов теряют позиции из-за INP

В первых числах апреля один клиент написал мне в Telegram: "У меня Метрика показывает минус 40% трафика за неделю. Яндекс, кажется, стабильный. Что случилось?" Я открыл Google Search Console - клики провалились с 1200 в день до 600, начало просадки чётко 28 марта. Классический симптом Core Update. Сайт не наказали за плохой контент, его "переоценили" по новым правилам. И одним из решающих факторов оказался INP 340 мс на ключевых посадочных.

Таких историй за первую половину апреля я услышал три. Это не случайность - March 2026 Core Update стал самым волатильным за последний год.

Что сделал Core Update

Начался 27 марта 2026 в 12:00 по московскому времени, раскатывался 12 дней и 4 часа, завершился 8 апреля. Google официально подтвердил окончание.

Цифры по данным Semrush, Sistrix и мониторинговых сервисов:

Апдейт волатильнее декабрьского 2025. Если декабрь переставлял местами соседей в выдаче, март выбивал старые страницы целиком.

Три ключевых изменения, которые закодированы в этот апдейт.

Information Gain получил зубы. Google давно говорил, что оценивает "насколько эта страница вносит что-то новое по сравнению с уже ранжирующимися". Теперь этот фактор начал реально влиять. Страницы, которые перефразировали топ-10 без добавления свежих данных, примеров, авторской экспертизы - проваливаются. Коалиция технологий пишет об этом довольно жёстко: "бренды с собственными данными выигрывают, посредники - в глубоком минусе".

AI-контент под фильтром, но не запрещён. Google ударил не по "AI-ассистированным" материалам, а по "scaled content" - тысячам статей, написанных без человеческого надзора. Если вы используете AI как инструмент и редактируете результат - всё в порядке. Если генерируете автоматически по шаблону и публикуете без проверки - апдейт вас почистил.

E-E-A-T усилился для YMYL. Темы "деньги, здоровье, безопасность" теперь требуют максимальной прозрачности автора и источников. Анонимные статьи в финансовой и медицинской тематике массово потеряли позиции.

Почему именно INP убил половину сайтов

Core Web Vitals - три метрики, которыми Google измеряет качество пользовательского опыта. После мартовского апдейта их вес в ранжировании вырос заметно. По актуальным данным corewebvitals.io:

Чтобы сайт считался "прошедшим" Core Web Vitals, 75% визитов в CrUX-данных должны быть в зелёной зоне по всем трём метрикам. То есть не "в среднем хорошо", а "три четверти реальных пользователей видят быстрый сайт".

В 2026 только 47% сайтов проходят этот порог. А самая проблемная метрика - INP. 43% сайтов в ней проваливаются - это больше, чем по LCP и CLS вместе взятым.

Почему? INP заменил FID (First Input Delay) в марте 2024. Раньше мерили только первое взаимодействие - как быстро браузер отреагировал на первый клик. Сейчас измеряют худшее взаимодействие за весь визит. Для пользователя это честнее: вам неважно, как быстро открылось меню при первом клике, вам важно, как отреагировал сайт на клик "Оформить заказ" - именно этот клик формирует впечатление.

А "Оформить заказ" в реальной жизни - это JS, который обрабатывает валидацию формы, отправляет запрос, обновляет интерфейс. Если JS-поток занят долгой задачей, пользователь видит задержку. На мобильном - особенно.

Что реально убивает INP

Практика последних месяцев: на 9 из 10 сайтов с плохим INP причина - тяжёлый JavaScript, который блокирует основной поток браузера.

Long tasks. Любая задача JS длительнее 50 мс блокирует отклик на пользователя. Если у вас в React что-то рендерит 300 мс - все клики в это время "висят". У клиентов с WordPress вижу Elementor/Divi с 2-3 МБ JS на каждой странице. У клиентов на Next.js - плохо разделённый bundle, где хоум-страница тянет код всего приложения.

Сторонние скрипты. Чат-виджеты, счётчики, A/B-тесты, пиксели ретаргетинга - каждый добавляет 50-200 мс к INP. Типичный лендинг малого бизнеса в 2026 тянет 8-12 сторонних скриптов. Половина из них - неактивные настройки, про которые все забыли.

Синхронный JS в начале страницы. Каждый <script> без defer или async останавливает парсинг HTML, пока не загрузится и не выполнится. Если у вас в хедере подряд три jQuery-плагина - ждите плохой INP.

Тяжёлые обработчики событий. Клик вешает обработчик, который делает полный ререндер страницы. Скролл слушатель, который считает что-то на каждое движение. Input handler, который не дебаунсится и гонит запросы на каждый символ.

На Tilda и Bitrix из коробки - ситуация сложнее. Архитектура этих CMS предполагает много JS, и глубоко в неё не залезть. Но в статье про PageSpeed я показывал подходы, которые работают и на них.

Как чинить INP

Рецепт зависит от стека. Универсально - диагностика через Chrome DevTools (вкладка Performance, запись сеанса) или PageSpeed Insights (Field Data секция).

Разбейте long tasks. Если задача занимает больше 50 мс - её нужно разделить. В 2026 появился нативный способ: scheduler.yield(). Поставьте его в середину тяжёлой операции, и браузер получит шанс обработать клики в промежутке. Для старых браузеров работает setTimeout(fn, 0).

Уберите мусор из третьих-сторонних скриптов. Откройте Google Tag Manager, посмотрите что реально выстреливает. Откройте Wappalyzer на своём сайте - часто оказывается, что активен трекер, который вы не ставили вручную (остался от подрядчика год назад). Каждый лишний скрипт - 50-100 мс к INP. Принципиально: оставляйте только те скрипты, которые приносят измеримый бизнес-результат.

Оптимизируйте React/Next.js. Если сайт на Next.js - используйте Server Components (RSC). Эксперимент Frigade показал -62% JS-бандла и 3x ускорение при переходе на RSC. React 19 Compiler автомемоизирует компоненты, уменьшая лишние рендеры. useTransition для некритичных обновлений, чтобы React мог их прерывать при новом взаимодействии пользователя.

Отложите всё, что не нужно сразу. Видео, карты, калькуляторы, сложные формы - подгружайте через loading="lazy" или по клику. Пользователь не должен ждать загрузки виджета, с которым он не собирается взаимодействовать.

Замерьте до и после. Без замеров вы не знаете, что сработало. Используйте web-vitals библиотеку (import { onINP } from 'web-vitals') и пишите реальные метрики в Яндекс.Метрику или Google Analytics. Через 2-3 недели увидите, двигаются цифры или нет.

Кстати, на мобильных INP почти всегда хуже десктопного в 2-3 раза. Это реальность слабых процессоров и медленного 3G/4G. Если тестировать только на своём MacBook - обманетесь. Chrome DevTools имеет throttling - включите "Mobile 3G" и посмотрите правду.

План восстановления позиций

После Core Update быстрого возврата не ждите. Google не возвращает позиции мгновенно, даже если вы исправите все проблемы. Система должна увидеть устойчивые улучшения, и обычно значимое восстановление происходит с следующим Core Update (раз в 3-6 месяцев).

Но время между апдейтами - это не "сидим и ждём". Это окно для работы.

Первое - диагностика. В Google Search Console откройте отчёт "Эффективность" и сравните период 1-26 марта с периодом 28 марта - 20 апреля. По каким запросам просадка? Какие страницы потеряли позиции? Иногда оказывается, что упал не весь сайт, а одна категория - это важная информация.

Второе - технический аудит Core Web Vitals. Идите в PageSpeed Insights, проверьте топ-10 посадочных. Смотрите на "Field Data" (реальные данные пользователей), не на "Lab Data" (лабораторные тесты). Если INP в красной зоне - начинайте с этого.

Третье - контентная работа. Пройдитесь по страницам, которые проседли сильнее всего. Вопросы: есть ли на странице информация, которой нет у конкурентов в топе? Есть ли имя автора, био, ссылки на его экспертизу? Свежая ли дата dateModified? Ссылается ли материал на первоисточники? Если на любой вопрос "нет" - переписывайте.

Четвёртое - E-E-A-T и авторство. Google всё жёстче оценивает сигналы авторства. На любую YMYL-страницу добавьте имя автора, его должность, ссылку на страницу автора (author.url в schema), подтверждение квалификации. Если писал AI - пусть редактор тоже расписан как автор.

Пятое - не бойтесь удалять страницы. Если у вас 200 статей и половина - низкого качества, лучше оставить 100 сильных. Google не любит "тонкие" сайты, а массовый посредственный контент - теперь прямой фактор ранжирования, с минусом.

Финальная мысль

Core Update марта 2026 - не катастрофа для всех. Кто-то провалился, кто-то вырос. Выросли те, у кого сайт был технически быстрым, контент - с реальной экспертизой и первичными данными, авторство - прозрачным. Провалились те, кто жил на посредственности.

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

Частые вопросы

Что такое INP и почему он важнее FID?

INP измеряет худшую задержку за весь визит, FID измерял только первую. Пользователь помнит не первый клик, а тот, после которого сайт завис. Порог "good" - 200 мс. 43% сайтов его не проходят.

У меня Tilda / Bitrix / WordPress, я могу что-то сделать?

Меньше, чем на собственной разработке, но можно. Убрать тяжёлые плагины, заменить PNG на WebP, включить lazy loading, поставить модуль кэширования. Из "poor" в "needs improvement" - реально.

Сколько времени нужно на восстановление после Core Update?

От недель до нескольких месяцев. Значимое восстановление обычно приходит с следующим Core Update. Быстрых побед не ждите.

AI-контент теперь запрещён?

Нет. Запрещён только "scaled content" без человеческого участия. AI как инструмент + редактура + собственные данные = норма.

Как понять, пострадал ли сайт от Core Update?

Google Search Console, период с 27 марта по 8 апреля. Если резкая просадка кликов и impressions в этом окне - да. Если плавная - другая причина.