Cookie-баннеры и согласия: как не потерять позиции

Cookie-баннер — это единственный элемент сайта, который юрист требует поставить, дизайнер соглашается сделать «как у всех», а разработчик подключает готовым скриптом за пять минут. И ровно этот элемент способен обнулить работу по скорости, испортить первый экран на мобильных, добавить сайту полсекунды к загрузке и в отдельных случаях спрятать контент от робота. Требования 152-ФЗ выполнить нужно — вопрос только в том, какой ценой. В этой статье разбираем cookie-согласия так, как мы внедряем их на проектах SEO-продвижения: что закон реально требует, как баннер влияет на CLS, INP и поведенческие метрики, какие реализации безопасны, а какие стоят позиций, и как проверить свою на предмет скрытых потерь.

Что 152-ФЗ требует на самом деле — и чего не требует

Половина проблем с cookie-баннерами возникает из-за того, что российские сайты копируют европейские решения. GDPR построен на принципе предварительного согласия: до клика пользователя нельзя запускать ни аналитику, ни рекламные пиксели, ни функциональные скрипты. Отсюда родились тяжёлые CMP-платформы, которые блокируют исполнение сторонних тегов, держат реестр вендоров и грузят по сотне килобайт кода. В российском правовом поле такой конструкции не требуется.

Что действительно вытекает из 152-ФЗ «О персональных данных» и связанной практики Роскомнадзора:

• Публичная политика обработки персональных данных. Документ должен быть в свободном доступе, со ссылкой из любого места сайта — обычно из подвала. Это прямое требование к оператору: обеспечить неограниченный доступ к документу, определяющему политику обработки.
• Информирование о том, какие данные и зачем собираются. Cookie сами по себе не всегда персональные данные, но идентификаторы аналитических систем, связанные с профилем посетителя, трактуются как таковые. Формулировка «мы используем файлы cookie» без пояснения категорий — слабая позиция.
• Согласие на обработку. Для форм — отдельный чекбокс с ссылкой на политику и на согласие. Для cookie — фиксация факта, что пользователь был проинформирован и продолжил пользоваться сайтом либо нажал кнопку.
• Уведомление Роскомнадзора об обработке персональных данных. Для подавляющего большинства коммерческих сайтов оно обязательно, и подаётся оно один раз.
• Локализация баз данных на территории РФ. Требование, из-за которого нельзя бездумно ставить зарубежные сервисы аналитики и чатов.

Чего 152-ФЗ не требует: закрывать сайт непрозрачным оверлеем до клика, блокировать скроллинг, запрещать доступ при отказе, показывать модальное окно с двумя уровнями настроек и списком из шестидесяти вендоров. Все эти элементы пришли из чужого регулирования и на российском проекте создают только издержки — по скорости, по конверсии и по поведенческим метрикам.

Как баннер ломает Core Web Vitals

Три метрики Core Web Vitals — LCP, CLS и INP — реагируют на cookie-баннер по-разному, и понимать эту разницу критично: одна и та же плашка может не влиять ни на что либо испортить сразу две метрики, в зависимости от способа вставки.

CLS: главная жертва

Cumulative Layout Shift измеряет визуальную нестабильность: насколько сильно элементы прыгают после того, как пользователь уже видит страницу. Порог «хорошо» — 0,1, «требует улучшения» — до 0,25, дальше «плохо». Значение считается по сессионным окнам: серия сдвигов, разделённых паузами не более секунды и укладывающихся в пятисекундное окно, суммируется, а в итоговый показатель идёт максимальное окно.

Классический сценарий поломки выглядит так. Верстальщик делает баннер обычным блоком в потоке — например, сверху страницы или перед подвалом. Скрипт вставляет его в DOM через 300–800 мс после загрузки, когда пользователь уже видит контент. Блок высотой 120 пикселей на десктопе и 200 на мобильном сдвигает вниз весь документ. Один такой сдвиг на мобильном экране высотой 800 пикселей даёт вклад в CLS порядка 0,2 — то есть сам по себе выбрасывает страницу из зелёной зоны, даже если всё остальное на сайте идеально.

Второй, менее очевидный сценарий: баннер исчезает. Пользователь нажимает «Принять», блок удаляется из потока, контент прыгает вверх. Здесь спасает правило исключения: сдвиги, произошедшие в пределах 500 мс после пользовательского ввода, в CLS не засчитываются. Но правило работает, только если сдвиг действительно вызван кликом и уложился в полсекунды. Если после клика идёт запрос на сервер, а блок убирается по ответу через 900 мс — сдвиг засчитается полностью.

Третий сценарий, который находят реже всего: баннер меняет высоту. Текст загрузился, шрифт подменился, кнопки перенеслись на вторую строку — плашка выросла на 40 пикселей и толкнула контент. Особенно характерно для баннеров с кастомным шрифтом без корректного font-display и для длинных юридических формулировок на узких экранах.

LCP: косвенный, но реальный вклад

Largest Contentful Paint фиксирует момент отрисовки самого крупного элемента в области просмотра. Порог «хорошо» — 2,5 секунды. Сам баннер редко становится LCP-элементом, но он влияет на метрику двумя путями.

Первый — конкуренция за поток. Внешний скрипт CMP, подключённый без атрибутов async или defer, блокирует парсинг HTML. Пока браузер не скачал и не исполнил чужой файл, он не двигается дальше по документу — а значит, не обнаруживает картинку героя и не начинает её загрузку. Полсекунды блокировки в начале документа стоят ровно полсекунды LCP.

Второй — новые сетевые соединения. Сторонний CMP живёт на своём домене: браузеру нужен DNS-lookup, TCP-хендшейк, TLS-рукопожатие, и только потом загрузка. На мобильном соединении это 200–400 мс до первого байта чужого скрипта, причём в самый неудачный момент — на критическом пути отрисовки. Мы разбирали эту механику в материале про скорость загрузки сайта: каждый новый третьесторонний домен стоит дороже, чем кажется по весу файла.

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

INP: цена «умных» настроек

Interaction to Next Paint измеряет отзывчивость: сколько миллисекунд проходит от действия пользователя до следующей отрисовки. Порог «хорошо» — 200 мс. Простой баннер с двумя кнопками к INP отношения не имеет. Проблемы начинаются у многоуровневых CMP с экраном настроек: клик по «Настроить» запускает построение списка категорий, пересчёт состояния десятков чекбоксов, обращение к внешнему API за конфигурацией. Длинная задача в главном потоке — и вот интеракция стоит 400–600 мс.

Отдельно вредна практика «по клику на Принять инициализируем всё сразу»: в один тик подключаются счётчики, пиксели, карты, чаты. Браузер получает пачку синхронных задач, интерфейс замирает на секунду, а пользователь в этот момент уже тапает по меню и не получает отклика. Правильно — разносить инициализацию через requestIdleCallback или хотя бы через setTimeout с нулевой задержкой, чтобы отдать отрисовку раньше, чем начнётся тяжёлая работа.

Что видит поисковый робот

Самая опасная ошибка в этой теме — не медленный баннер, а баннер, который прячет контент от индексирующего робота. Здесь важно понимать один факт: роботы Яндекса и Google не хранят cookie между запросами. Каждый обход — это чистая сессия без истории. Соответственно, если ваш сайт показывает контент только после согласия, для поиска у вас нет контента.

Три сценария, каждый со своими последствиями

1. Баннер как визуальный слой поверх готового HTML. Контент отрисован, в DOM присутствует полностью, плашка просто лежит сверху. Робот получает документ целиком, индексация не страдает. Это единственный безопасный вариант, и именно к нему нужно приводить любую реализацию.
2. Cookie-wall с редиректом. Пользователь без согласия отправляется на /consent/ или /cookie-policy/. Робот при обходе любого URL получает 302 на служебную страницу. Результат — из индекса начинают выпадать целые разделы, а в отчётах об индексации появляется вал «недостаточно качественная» и «неканоническая». Схема встречается редко, но когда встречается — обходится дороже всего.
3. Отложенный рендеринг контента. Сценарий для SPA: приложение инициализируется, проверяет согласие, и только потом монтирует основной компонент. Для робота страница остаётся пустым каркасом. Это частный случай общей проблемы JavaScript-SEO, но с дополнительным нюансом: разработчик обычно уверен, что «всё рендерится», потому что в своём браузере cookie согласия у него давно стоит.

Порядок элементов в DOM и сниппет

Ещё один недооценённый момент. Если разметка баннера физически стоит в начале <body>, до заголовка H1 и основного текста, то в текстовом слепке страницы первым идёт юридическая формулировка про файлы cookie. На большинстве запросов это ни на что не влияет, но на страницах с бедным контентом поисковик может собрать описание сниппета именно из этого текста. Простое решение: держать разметку баннера последним элементом перед закрывающим тегом body и позиционировать его фиксированно. Визуально ничего не меняется, семантически документ становится чище.

Часть специалистов дополнительно оборачивает текст баннера в <!--noindex--> для Яндекса. Вреда от этого нет, ощутимой пользы — тоже, если баннер и так стоит в конце документа. Гораздо важнее не запрещать в robots.txt файлы CSS и JS, отвечающие за баннер: робот рендерит страницу и должен видеть, что плашка компактна и не перекрывает контент. Закрытый от индексации стиль превращает аккуратную полоску внизу в глазах робота в неизвестный блок — а Google явно оценивает навязчивость межстраничных элементов на мобильных.

Мобильные экраны и навязчивые интерстишалы

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

Практические ориентиры, от которых мы отталкиваемся при мобильной оптимизации:

• Высота плашки — не более 20–25% высоты вьюпорта. На экране 800 пикселей это 160–200 пикселей: хватает на два предложения текста и две кнопки.
• Никакого затемняющего фона на весь экран. Backdrop уместен для оформления заказа, но не для уведомления.
• Скроллинг не блокируется. overflow: hidden на body в момент показа баннера — прямой путь к отказам.
• Кнопка закрытия (или «Принять») — минимум 44×44 пикселя, в зоне досягаемости большого пальца, не в дальнем верхнем углу.
• Учитывайте безопасную зону iPhone: padding-bottom: env(safe-area-inset-bottom), иначе кнопка уедет под системную полосу.
• Проверьте конфликт z-index с фиксированной панелью заказа, кнопкой «Наверх» и виджетом чата. Типичная ситуация: баннер перекрывает кнопку «Купить» на карточке товара — и весь мобильный трафик неделю не может оформить заказ.

Поведенческие метрики: где именно теряются деньги

Для Яндекса поведенческие факторы остаются одним из ключевых блоков ранжирования, и cookie-баннер попадает в них напрямую — потому что стоит между посетителем и контентом в самый чувствительный момент, в первые секунды визита.

Механика простая. В Яндекс.Метрике отказом считается визит с одним просмотром страницы длительностью менее 15 секунд. Пользователь пришёл из выдачи, увидел вместо ответа модальное окно с юридическим текстом, не понял, куда нажимать, вернулся назад. Это одновременно: отказ в Метрике, короткая сессия и возврат в выдачу — то есть худший из возможных сигналов. Один такой посетитель погоды не делает, но если реализация раздражает 20–30% мобильной аудитории, разница видна на уровне раздела.

Что мы видим на проектах при разборе связки «баннер — поведение»:

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

Аналитика и согласие: как не ослепнуть

Тонкий вопрос: запускать ли счётчик Яндекс.Метрики до получения согласия. Радикальный подход «ничего не грузим до клика» выглядит юридически безупречно, но имеет цену, которую редко считают заранее.

Цена такая. Часть посетителей закрывает страницу быстрее, чем нажимает кнопку. Часть игнорирует баннер и продолжает читать. Эти визиты в статистику не попадут вообще — счётчик не инициализирован. В результате вы теряете не «немного данных», а именно самые короткие визиты, то есть систематически искажаете картину: средняя длительность сессии выглядит лучше реальной, доля отказов — ниже, источники трафика перекошены в пользу лояльной аудитории. Хуже того, разрыв возникает между двумя окнами наблюдения — до внедрения баннера и после, и весь исторический ряд перестаёт быть сопоставимым.

Практическая схема, которую мы считаем разумным компромиссом:

• Счётчик веб-аналитики инициализируется сразу, обработка описана в политике, баннер информирует об этом при первом визите. Российское регулирование не требует предварительной блокировки в европейском смысле.
• Вебвизор, карты скроллинга и запись форм — по согласию. Это запись поведения конкретного человека, и здесь осторожность оправдана. Технически отключается параметрами инициализации счётчика.
• Рекламные пиксели и ремаркетинг — строго по согласию на маркетинговые cookie. Одновременно это разгружает первую загрузку: пиксели подключаются после взаимодействия, а не на критическом пути.
• Внешние виджеты (карты, видео, чаты) — по клику на плейсхолдер. Приём даёт двойной эффект: и требование выполнено, и с первой загрузки уходят сотни килобайт стороннего кода.

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

Сравнение вариантов реализации

Ниже — типы баннеров, которые встречаются на российских коммерческих сайтах, и их поведение по ключевым параметрам. Столбец «Риск CLS» относится к типовой, а не идеальной реализации.

Про плагины отдельно. На WordPress популярные решения для согласий тянут собственные библиотеки, иногда jQuery, свой CSS и админский интерфейс с десятками опций. Реальная функциональность, которая нужна российскому сайту, — показать плашку, запомнить решение, дать возможность передумать — укладывается в несколько килобайт. Если проект уже борется за десятые доли секунды LCP, замена плагина на собственный код часто оказывается самой дешёвой оптимизацией из возможных.

Правильная реализация: пошагово

Типовые ошибки: проблема, причина, решение

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

Как измерить реальный эффект

Главная методическая ошибка при проверке cookie-баннера — тестировать его в лаборатории. В своём браузере у вас cookie согласия давно проставлена, и баннер не показывается. В Lighthouse при холодном прогоне он показывается, но часто уже после того, как замер завершён. В итоге инструмент рапортует «всё зелёное», а реальные пользователи получают сдвиг макета.

Порядок корректной проверки

1. Инкогнито + троттлинг. Открыть страницу в приватном окне с эмуляцией мобильного устройства и медленной сети (Slow 4G, CPU 4× slowdown). Именно в этих условиях баннер прилетает с ощутимой задержкой.
2. Панель Performance в DevTools. Записать загрузку, найти на треке события Layout Shift, включить подсветку регионов сдвига (Rendering → Layout Shift Regions). Каждый сдвиг подсвечивается синим — вы буквально увидите, что и куда прыгнуло.
3. Полевые данные. Отчёт «Скорость сайта» в Яндекс.Вебмастере (строится на данных Метрики от реальных посетителей) и CrUX-часть PageSpeed Insights. Обновление полевых данных занимает недели, поэтому сравнивать «до и после» имеет смысл не раньше чем через 28 дней.
4. Сегменты в Метрике. Сравнить долю отказов и глубину просмотра на мобильных до и после внедрения, отдельно по посадочным страницам из поиска. Разница по типу устройства обычно нагляднее, чем общая цифра.
5. Отрендеренный HTML глазами робота. «Проверка ответа сервера» в Вебмастере и «Проверка URL» в Search Console — убедиться, что весь контент на месте и никакого редиректа на страницу согласия нет.
6. Скан краулером. Прогнать сайт Screaming Frog и посмотреть, не появились ли URL с параметрами согласия и не изменились ли коды ответа на посадочных.

Особые случаи

Сайт за CDN и полностраничный кэш

Если перед сайтом стоит кэширующий слой, любая серверная логика показа баннера превращается в проблему: либо кэш отдаёт всем один и тот же вариант (и часть посетителей видит плашку повторно), либо вы выключаете кэш и теряете сотни миллисекунд TTFB. Единственно верное решение — состояние на клиенте: HTML одинаков для всех, а решение о показе принимает инлайновый скрипт, читающий cookie до первой отрисовки. Тонкости кэширования и заголовков Vary разбирали в материале про CDN и SEO.

Мультирегиональные проекты и поддомены

Если у компании сеть поддоменов по городам, согласие логично хранить на общем домене второго уровня: cookie с domain=.example.ru читается всеми поддоменами, и посетитель не увидит баннер заново при переходе из Москвы в Екатеринбург. Обратная ситуация — когда поддомены юридически принадлежат разным лицам: тогда согласия разделяют, и это уже вопрос к юристу, а не к разработчику.

Международные версии

Для проектов с европейской аудиторией российская облегчённая схема не годится: там нужен полноценный предварительный контроль над скриптами. Разумная архитектура — определять регион на CDN и отдавать разным аудиториям разные конфигурации согласия, сохраняя лёгкий вариант для российского трафика. Разделять при этом надо не URL, а поведение: плодить отдельные адреса вида /ru/consent/ и /eu/consent/ не нужно, они только засоряют индекс.

Интернет-магазины

Для e-commerce критичен конфликт баннера с интерфейсом покупки: фиксированная панель «Добавить в корзину», плавающая корзина, всплывающие уведомления о добавлении товара. Перед внедрением проверьте на реальных устройствах весь путь: карточка — корзина — оформление. Отдельно проследите, чтобы отказ от аналитических cookie не ломал работу самой корзины: если технические cookie завязаны на ту же логику согласия, отказ приводит к пустой корзине и потерянному заказу. Технические cookie согласия не требуют — они относятся к обеспечению работоспособности сервиса.

Что даёт правильная реализация в сумме

Если свести всё сказанное к практическому результату, грамотный cookie-баннер — это:

• Нулевой вклад в CLS. Метрика остаётся такой же, какой была до внедрения, — а значит, вся предыдущая работа по стабильности макета не обнуляется.
• 3–6 КБ вместо 40–150. Один домен вместо двух, отсутствие блокирующих запросов на критическом пути.
• Полная доступность контента роботу. Ни редиректов, ни отложенного рендеринга, ни закрытых от индексации стилей.
• Отсутствие мусорных URL. Согласие не порождает адресов с параметрами, которые робот начнёт обходить и индексировать.
• Ровные поведенческие. Плашка не перекрывает ответ на запрос пользователя и не провоцирует возврат в выдачу в первые секунды.
• Выполненное требование закона. С логом согласий, версионированием политики и возможностью отзыва.

Ни один из этих пунктов сам по себе не выводит сайт в ТОП. Но каждый из них — из категории «легко потерять и дорого вернуть». Cookie-баннер относится к тому классу правок, где грамотная реализация не даёт прироста, а безграмотная отнимает уже достигнутое, и именно поэтому мы включаем его проверку в базовый технический аудит наравне с robots.txt и картой сайта. Примеры проектов, где технические правки такого рода дали ощутимый эффект, собраны в нашем портфолио, а состав работ и стоимость сопровождения — на странице цен на продвижение.

И последнее. Cookie-баннер — часть общего впечатления от сайта, которое поисковик оценивает через коммерческие факторы: прозрачные документы, понятные условия, аккуратный интерфейс. Сайт, где политика обработки данных написана человеческим языком, а уведомление не мешает читать, выигрывает не только у робота. Это тот случай, когда «сделать по-человечески» и «сделать правильно для SEO» — одно и то же действие.

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