ВЕБ ШТУРМ
Обсудитьв MAX
Версия:

Видимость в Яндексе, стабильный LCP и SEO-мониторинг: три связанных фикса

Веб Штурм
  • SEO
  • Core Web Vitals
  • Yandex
  • аналитика
  • мониторинг
  • performance
  • 152-ФЗ

Три, казалось бы, разных задачи — «Вебмастер не видит Метрику», «PageSpeed упал с 97 до 87», «как не пропустить просадку позиций» — на деле одна тема: видимость сайта в поиске и контроль над ней. Ниже — как мы их связали и закрыли.

Симптом: Яндекс.Вебмастер «не видел» счётчик Метрики. Но корень оказался не в привязке, а в том, что счётчик стоял за двойным гейтом:

  1. Cookie-consent — metrika-init.js грузился только если в localStorage было согласие на аналитику.
  2. Lazy-load — отложенная загрузка ради Core Web Vitals.

Поисковый бот Яндекса не нажимает «согласен» и не взаимодействует со страницей. Значит, для него счётчик не инициализировался вообще — и сайт не накапливал поведенческие факторы, один из сильнейших сигналов ранжирования в Рунете.

Решение: Метрика как технически необходимая

Cookie-гейт для Метрики — это была перестраховка, а не требование. Метрика — российский сервис: оператор ПДн — Яндекс, данные в РФ. В slim-режиме (webvisor и clickmap выключены) она собирает только обезличенную посещаемость, не действия пользователя.

Мы отнесли Метрику к категории «Необходимые» и грузим её безусловно (но всё ещё lazy — чтобы не вредить скорости):

// metrika-init.js — безусловная, но отложенная загрузка
var DELAY_DESKTOP = 2000, DELAY_MOBILE = 2500;
var DELAY = matchMedia('(max-width: 767px)').matches ? DELAY_MOBILE : DELAY_DESKTOP;
// init по первому из: interaction | requestIdleCallback | setTimeout(DELAY)

152-ФЗ соблюдён: cookie-баннер и privacy переписаны (Метрика → «Необходимые, обезличенная статистика, оператор Яндекс/РФ»), webvisor/clickmap выключены. А привязка Вебмастер↔Метрика, как выяснилось, вообще работает на уровне аккаунтов Яндекса — не зависит от того, видит ли бот счётчик в DOM.

2. PageSpeed «упал» — но виновата не Метрика

После включения безусловной Метрики mobile-PageSpeed показал 87 вместо 97. Логичное подозрение — тяжёлый сторонний скрипт. Но диагностика через PageSpeed API (мы написали свой скрипт-обёртку) показала иное:

  • TBT (Total Blocking Time) — стабильно 0–20ms. Значит lazy-Метрика главный поток не блокирует. Она не виновата.
  • LCP прыгал 1.9 ↔ 3.7s между идентичными прогонами → score 87 ↔ 100. Это вариативность lab-замера.
  • Speed Index стабильно высокий.

Один прогон PageSpeed — не диагноз. После 3-4 замеров стало ясно: проблема не в Метрике, а в коде первого экрана.

Корень: entrance-анимация на LCP-элементе

У hero-блока стояла анимация появления:

<div class="animate-in fade-in slide-in-from-bottom-4 duration-700">
  <h1>Сложное ПО. Без воды.</h1>   <!-- это и есть LCP-элемент -->

LCP фиксируется по достижении финального вида элемента. Заголовок «въезжал» снизу с затуханием за 700ms → LCP откладывался на эти 700ms и прыгал в зависимости от таймингов lab. Speed Index страдал по той же причине — above-the-fold контент проявлялся постепенно.

Убрали entrance-анимации с обеих колонок hero. Результат — LCP детерминированно 1.7s (три прогона подряд), score стабильно 94–100.

Правило: не вешайте entrance-анимации (fade/slide/translate) на above-the-fold LCP-элементы. Анимации входа — только ниже сгиба.

3. От pull-дашборда к push-мониторингу

У нас уже есть серверная аналитика (/admin/analytics): воронка «Обсудить → лид» по аудиториям, без cookie. Плюс Я.Метрика и Я.Вебмастер. Но всё это pull — надо зайти и посмотреть. Обвал замечают постфактум: один из наших сайтов потерял 68% поисковых кликов за неделю, и это увидели только при ручной проверке.

Мы спроектировали push-мониторинг поверх существующей инфраструктуры (фоновый воркер + Hatchet cron + Telegram-дайджесты):

  • Еженедельный дайджест — сводка по сайтам: PageSpeed, трафик (Метрика), органика и позиции (Вебмастер), воронка (своя аналитика), со стрелками дельты неделя/неделю.
  • Ежедневные алерты — молчат в норме, пишут только при пробитии порога: трафик −40%, клики −30%, средняя позиция +1.5, PageSpeed mobile < 85, сайт не отвечает 200.

Три источника сшиваются в одну воронку: позиции → трафик → конверсия. Пороги — параметрами, не в коде. Снимок каждого прогона пишется в таблицу seo_snapshots — это и история тренда, и основа для графиков.

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

Что в сумме

  • Метрика видна Яндексу → поведенческие факторы работают на ранжирование (152-ФЗ соблюдён через slim-режим).
  • mobile-LCP стабилен 1.7s, PageSpeed 94–100 — за счёт снятия анимаций с первого экрана, а не урезания аналитики.
  • Дизайн мониторинга, который превращает «узнали об обвале постфактум» в «получили алерт за день».

Ссылки

Часто задаваемые вопросы

Почему Яндекс.Метрику стоит грузить без cookie-согласия (в РФ)?
Метрика — российский сервис, оператор персональных данных — Яндекс, данные хранятся в РФ. В slim-режиме (webvisor и clickmap выключены) счётчик собирает только обезличенную посещаемость, не действия конкретного пользователя. Если же прятать его за cookie-гейтом, поисковый бот Яндекса (который не нажимает «согласен») счётчик не видит — и сайт теряет поведенческие факторы, один из сильнейших сигналов ранжирования в Рунете. Решение — отнести Метрику к технически необходимым и грузить всегда, сохранив 152-ФЗ-соответствие за счёт slim-настроек.
Почему PageSpeed mobile прыгает между прогонами?
Лабораторный замер PageSpeed (Lighthouse на эмулированном throttled-устройстве) выполняется на нагруженных серверах Google и сильно вариативен: LCP одного и того же URL может показывать то 1.9s, то 3.7s, давая score от 87 до 100. Поэтому один прогон — не диагноз: нужно 2-3 замера. Стабильную картину даёт CrUX field data — реальные пользователи за 28 дней, — но для неё нужен трафик.
Как entrance-анимация ломает LCP?
LCP (Largest Contentful Paint) фиксируется в момент, когда самый крупный элемент достигает финального вида. Если на него навешена анимация появления (fade-in + slide-in за 700ms), браузер считает элемент «дорисованным» только после её окончания — LCP откладывается на длительность анимации и начинает прыгать в зависимости от таймингов. Лечение: не вешать entrance-анимации на above-the-fold LCP-элементы (заголовок, hero-картинку). Анимации входа — только ниже сгиба.
Зачем нужен push-мониторинг, если есть дашборд аналитики?
Дашборд — это pull: нужно зайти и посмотреть. Обвал замечают постфактум. Один из наших сайтов потерял 68% поисковых кликов за неделю, и это увидели только при ручной проверке. Push-мониторинг (еженедельный дайджест + ежедневные алерты на аномалии в Telegram) ловит дельту позиций и трафика до того, как обвал станет заметным по выручке.