Модалки и поп-апы на сайте: что говорит Яндекс и Google

Поп-ап сам по себе не вызывает автоматическую санкцию. Риск появляется, когда окно перекрывает основной материал, возникает до того, как посетитель понял содержание страницы, мешает закрытию или делает контент недоступным роботу. Google прямо рекомендует избегать навязчивых interstitial и dialog, а Яндекс требует давать пользователю прямой доступ к материалу без завес из рекламы и всплывающих окон. У обеих поисковых систем нет опубликованного универсального правила «покажите через N секунд» или «занимайте не больше X% экрана».

Сначала разделим шесть разных наборов правил

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

Уровень	Что оценивается	Что может произойти
Google Search	Доступность основного контента, общая page experience, Core Web Vitals	Страница может показывать худшие результаты в поиске, но последствия одного окна заранее не рассчитываются
Яндекс Поиск	Полезность, удобство, прямой доступ к ответу, отсутствие агрессивного привлечения и обмана	Алгоритмические ограничения или более слабое ранжирование при системной проблеме качества
Better Ads и Chrome	Конкретные рекламные форматы, признанные раздражающими	Chrome может фильтровать рекламу на сайте со статусом Failing; это не блокировка сайта в поиске
AdSense, Google Ad Manager, РСЯ	Размещение рекламы внутри конкретной сети	Ограничение или отключение рекламных показов, отклонение реализации
Закон и consent	Нужно ли получать согласие, подтверждать возраст или показывать условия	Последствия зависят от страны, вида данных и бизнеса; требуется отдельная правовая проверка
WCAG и доступность	Клавиатура, фокус, имя и роль элемента, работа screen reader	Часть людей не сможет закрыть окно или выполнить задачу, даже если поисковый робот видит страницу

Например, собственная форма подписки обычно не является сторонней рекламой для Ad Experience Report. При этом полноэкранная форма на входе остается риском для поиска, конверсии и доступности. Обратная ситуация тоже возможна: небольшой рекламный overlay не закрывает статью, но нарушает технические требования выбранной рекламной сети.

Что говорит Google о навязчивых окнах

Текущая рекомендация Google Search Central распространяется на промо-диалоги, включая предложение установить приложение или подписаться на рассылку. Google выделяет две главные ошибки:

• interstitial закрывает всю страницу;
• посетителя перенаправляют на отдельный URL, чтобы получить согласие или другие данные до доступа к исходной странице.

Предпочтительный вариант — компактный баннер, занимающий небольшую часть экрана. Он позволяет человеку и поисковику сразу добраться до содержания. Конкретного определения «небольшой части» для Search нет, поэтому правило нельзя превращать в 20%, 30% или другую универсальную цифру.

Текущая формулировка Google осторожна: навязчивый слой затрудняет понимание контента и может привести к плохим результатам в поиске. Это не обещание ручной санкции за единичный показ. У Google также нет одного балла page experience, который можно «пройти». Core ranking systems используют несколько сигналов; Core Web Vitals входят в них, но идеальные метрики не гарантируют верхние позиции.

Почему правило 30% не решает вопрос SEO

Число 30% встречается в Better Ads Standards. На мобильных устройствах оно используется, например, для расчета плотности рекламы и определения large sticky ad. На desktop у отдельных форматов свои критерии: large sticky более 30% экрана, общая плотность рекламы более 50% высоты основного контента и отдельная комбинация плотности со sticky video.

Эти пороги относятся к стороннему коммерческому рекламному контенту в Ad Experience Report. Они не устанавливают допустимый размер newsletter-формы и не дают гарантии Google Search. Chrome при подтвержденном Failing фильтрует рекламу после процедуры уведомления и проверки; основной текст сайта из-за этого сам по себе не исчезает из поиска.

Обязательные окна, login и paywall

Google выделяет обязательные interstitial, связанные с типом контента. В актуальной справке примером служит age gate. Такой слой лучше накладывать на содержимое исходного URL, не отправляя все страницы на одну страницу проверки возраста или согласия. Иначе Googlebot получит один и тот же промежуточный документ вместо разных материалов.

Историческая справка Google отдельно приводила cookie notice и вход к непубличному контенту как допустимые сценарии при ответственном использовании. Текущие документы описывают задачу точнее:

• приватная почта или личный кабинет не рассчитаны на публичную индексацию;
• индексируемая статья с регистрацией или оплатой требует отдельной схемы paywall;
• для paywall Google поддерживает lead-in — открытую вводную часть — и structured data с isAccessibleForFree: false и hasPart;
• Googlebot должен иметь доступ к материалу, который издатель хочет индексировать, а разметка помогает отличить paywall от клоакинга.

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

Что говорит Яндекс

Справка Яндекс Вебмастера о качестве прямо относит к проблемным сайты, основное предназначение которых — агрессивно привлекать внимание к товарам или услугам, в том числе через popup, popunder и clickunder. В разделе о юзабилити есть еще более практичная формулировка: посетитель должен получить прямой доступ к материалу, не преодолевая завесы из рекламы и всплывающих окон.

Поэтому утверждение, что «Яндекс вообще ничего не говорит о pop-up», неверно. Но и название отдельного современного «фильтра за поп-ап» в публичной справке отсутствует. Нет опубликованного безопасного времени, частоты и доли экрана для обычного маркетингового окна. Яндекс рассматривает всплывающие элементы внутри общей оценки качества, удобства, пользы и отсутствия обмана.

Архивная публикация Яндекса 2012 года описывала понижение сайтов с обманными pop-up, которые имитировали сообщения соцсетей, антивирусов или системные уведомления и выманивали данные либо подписку на платную услугу. Это важный пример социальной инженерии, но не современная формула для любой модалки.

Отдельно действуют требования Рекламной сети Яндекса. Они запрещают рекламу РСЯ в самостоятельных окнах браузера pop-up и pop-under, задают положение, размер и кнопку закрытия для overlay-блоков. Эти условия обязательны для партнера сети, но не являются описанием алгоритма Яндекс Поиска.

Какие сценарии безопаснее, а какие рискованнее

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

Сценарий	Более безопасный вариант	Рискованный вариант	Комментарий
Entry pop-up	Небольшое критическое уведомление, не закрывающее ответ	Full-screen промо сразу после входа из поиска	Пользователь еще не убедился, что попал на полезную страницу
Exit intent	Один релевантный оффер, не мешающий уходу, с частотным лимитом	Перехват Back, повторное окно после закрытия, ложная кнопка X	Исключение Better Ads для части exit-сценариев не дает разрешения Google Search
Newsletter	Inline-форма или компактный баннер после вовлечения	Блокировка статьи до ввода email	Подписка должна быть добровольной; отказ не должен ухудшать доступ к бесплатному материалу
Age gate	Обязательный overlay над тем же URL, простое подтверждение	Редирект всех URL на /age-check, выдача роботу случайной заглушки	Нужна отдельная проверка закона и поведения Google/Яндекса
Login	Dialog после команды «Войти»	Автоматический login wall поверх публичной страницы	Для приватного кабинета индексация обычно не нужна; публичный материал не стоит превращать в кабинет
Paywall	Lead-in, понятные условия, корректная разметка, доступ робота по политике издателя	Пустая страница с одним окном оплаты и текстом только после click	Google и Яндекс по-разному описывают доступ роботов; реализацию проверяют отдельно
Cookie consent	Компактный слой, равно понятные варианты, корректная работа без решения	Огромная стена, скрытый отказ, заранее загруженные необязательные tags	Законность зависит от региона; инженерные требования к скорости и доступности остаются всегда
Установка приложения	Малый browser/HTML banner со ссылкой в store	Full-screen interstitial до контента	Google прямо предлагает баннер вместо перекрытия
Реклама	Формат рекламной сети с clear exit и frequency cap	Prestitial с ожиданием, pop-under, deceptive close	Проверяют Better Ads, Chrome, сеть и Search независимо
Чат или обратный звонок	Свернутая кнопка, открытие по click, сохранение закрытия	Авторазворот на половину мобильного экрана поверх кнопок	Лаунчер также не должен скрывать элемент с клавиатурным фокусом
Аварийное сообщение	Inline или sticky alert с кратким фактом и ссылкой на статус	Лид-форма под видом аварии	Modal уместна, только если без подтверждения нельзя безопасно продолжить

Entry и exit-intent

Entry pop-up — самый конфликтный промо-сценарий: он срабатывает раньше, чем человек прочитал заголовок или первый абзац. Если сообщение не является обязательным, лучше заменить его inline-блоком, небольшим баннером или показом после осмысленного действия.

Exit-intent мягче только при строгих условиях. Окно не должно мешать закрытию вкладки, перехватывать Back или появляться снова после отказа. В Better Ads advisory некоторые показы при начале ухода, после 30 секунд бездействия, в конце первой статьи или после возвращения во вкладку пока не включены в стандарт pop-up ads. Это узкая классификация рекламы. Google Search по-прежнему оценивает доступность контента и общий опыт.

На мобильном нет надежного аналога движения курсора к кнопке закрытия. Подмена его быстрым scroll-up или случайным touch часто приводит к ложным срабатываниям. Для смартфона безопаснее конец статьи, завершение шага или явная кнопка.

Cookie consent и age gate

Обязательность окна не освобождает разработчика от UX и доступности. Содержание страницы должно оставаться по исходному URL, а сам слой — быстро загрузиться, дать понятные варианты и корректно сохранить выбор. Нельзя считать, что любой полноэкранный cookie wall автоматически допустим: объем согласия, возможность отказа и допустимость стены зависят от применимого права.

Age gate должен запрашивать минимально необходимое действие. Google допускает показ adult-content проверенному Googlebot без age gate, но реализовывать это нужно только после надежной проверки робота. Не стоит выдавать специальный вариант по одной строке User-Agent. Для Яндекса отдельного идентичного исключения в изученной справке нет; резкое различие контента для робота и пользователя может выглядеть как клоакинг.

Реклама, чат и аварийные уведомления

Для сторонней рекламы сначала выбирают формат, поддерживаемый сетью. Самодельное полноэкранное объявление может одновременно нарушить Better Ads, правила площадки и поисковые рекомендации. Ложная системная иконка, невидимая кликабельная область, кнопка закрытия с переходом на рекламу и манипуляция историей браузера относятся уже к abusive experience.

Чат, callback и предложение консультации лучше держать свернутыми. Автоматическое раскрытие допустимо тестировать только после вовлечения и с надежным frequency cap. На мобильном виджет не должен закрывать навигацию, кнопку покупки, поле формы или сообщение об ошибке.

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

Как выбрать время, площадь и частоту

Поисковики не публикуют волшебную задержку. Советы «15 секунд», «30 секунд» или «60 секунд» в маркетинговых статьях описывают чьи-то гипотезы, а не правило ранжирования.

Выбирайте триггер по готовности посетителя:

• для подсказки к функции — явный click или focus на соответствующем элементе;
• для newsletter — прочитанная значимая часть статьи, конец материала или повторный визит;
• для допродажи — добавление товара либо другой завершенный шаг, но не перекрытие оплаты;
• для аварии — сразу, но в компактном и информативном формате;
• для обязательного согласия — до запуска необязательной обработки, сохраняя работоспособность страницы;
• для рекламы — только поддерживаемые сетью события и frequency cap.

Площадь оценивают на самом маленьком поддерживаемом viewport. Dialog, который занимает треть desktop, на экране 320 пикселей может закрыть все. Учитывайте экранную клавиатуру, safe areas, zoom 200–400% и горизонтальную ориентацию. Если предложение умещается в одну строку и одну кнопку, full-screen формат ему не нужен.

Частотный лимит должен учитывать не только сессию. Сохраняйте закрытие или отказ на разумный срок, не показывайте подписку уже подписанному пользователю и не открывайте одинаковое окно на каждой странице. Проверьте поведение при запрете cookie/localStorage: отсутствие хранилища не должно превращаться в бесконечный показ.

Как сделать основное содержание доступным роботам

Google Search рендерит JavaScript, но не кликает, не вводит данные и не листает интерфейс ради открытия основного текста. Яндекс тоже пишет, что робот не выполняет активных действий. Поэтому заголовок, лид, основной текст, ссылки и данные, ради которых создан URL, должны присутствовать в исходном или rendered HTML без открытия modal.

Практические требования:

• не загружайте статью только после закрытия окна или нажатия «Продолжить»;
• не заменяйте каждый URL редиректом на единую страницу consent;
• не блокируйте CSS и JavaScript, от которых зависит мобильный рендер;
• проверяйте rendered HTML в URL Inspection Google и в инструментах Яндекс Вебмастера;
• для индексируемого paywall размечайте закрытые части и проверяйте доступ робота;
• не показывайте роботу дополнительный SEO-текст, которого нет у пользователя;
• при A/B-тесте сохраняйте одинаковый смысловой контент и не выделяйте поисковый трафик в «облегченную» версию только для робота.

Служебная копия modal иногда попадает в сниппет и вытесняет полезное описание. В Google отдельный фрагмент можно исключить из сниппета через data-nosnippet. В Яндексе есть локальный элемент noindex, но использовать его надо особенно аккуратно: пропущенный закрывающий тег способен скрыть от индекса весь оставшийся текст.

Доступная модалка: фокус, клавиатура и screen reader

Визуальный крестик не делает окно доступным. Полноценный modal dialog меняет режим взаимодействия со страницей, поэтому обязан управлять фокусом и фоном.

Требование	Как должно работать	Типичная ошибка
Семантика	role="dialog" или нативный dialog, aria-modal="true" только для фактически модального слоя	div без роли, который screen reader не распознает как диалог
Доступное имя	aria-labelledby связывает dialog с видимым заголовком; у X есть понятное имя «Закрыть»	Screen reader объявляет «кнопка» без назначения
Начальный фокус	При открытии фокус переходит внутрь; для длинного текста — на заголовок/начало, для короткой формы — на логичный control	Фокус остается на ссылке под затемнением
Tab-цикл	Tab и Shift+Tab обходят только элементы dialog	Фокус уходит в меню или форму за overlay
Закрытие	Видимая кнопка, Escape для необязательного dialog, корректная Cancel	Единственный способ — точный click по маленькой X или backdrop
Возврат фокуса	После закрытия — на инициировавшую кнопку или следующий логичный шаг	Фокус сбрасывается в начало документа
Фон	Background действительно inert: без click, Tab и чтения как активного слоя	Визуально затемнен, но остается интерактивным
Ошибки формы	Ошибка связана с полем и объявляется вспомогательной технологии	Цветная рамка без текста и программной связи

WAI-ARIA Authoring Practices рекомендует видимую кнопку закрытия в последовательности Tab. WCAG 2.2 задает для pointer target минимум 24×24 CSS-пикселя либо достаточное расстояние по условиям критерия. Для мобильного крестика практичнее более крупная активная область.

aria-modal="true" нельзя добавлять к панели, если пользователь по-прежнему может работать с фоном. Screen reader перестанет воспринимать внешний контент, а фактическое поведение останется немодальным. Для небольшого уведомления часто подходит обычный region/status или немодальная панель.

Scroll lock без прыжков страницы

При открытом modal фон не должен прокручиваться. Зафиксируйте исходную позицию, запретите background scroll и восстановите ее после закрытия. Проверьте iOS/Android, длинный dialog, вложенные scroll areas и экранную клавиатуру. Контент самого окна должен прокручиваться, а его заголовок и кнопки — оставаться достижимыми при zoom.

Не открывайте второй modal поверх первого без необходимости. Вложенные ловушки фокуса, два scroll lock и конкурирующие обработчики Escape быстро ломают интерфейс. Если следующий шаг сложный, чаще понятнее закрыть первый dialog и открыть отдельную страницу.

Как поп-ап влияет на LCP, INP и CLS

Core Web Vitals измеряют реальный опыт загрузки, реакции и визуальной стабильности. Хорошие ориентиры Google: Largest Contentful Paint (LCP) до 2,5 секунды, Interaction to Next Paint (INP) менее 200 мс и Cumulative Layout Shift (CLS) менее 0,1 — для 75-го процентиля реальных визитов.

Метрика	Как модалка ухудшает показатель	Что сделать
LCP	Большой cookie dialog становится самым крупным элементом; синхронный vendor script блокирует первый рендер; SDK конкурирует за сеть с hero image/font	Минимизировать слой, подключать скрипт асинхронно, не задерживать основной HTML и критические ресурсы, избегать цепочки tag manager → CMP
INP	Click «Принять» одновременно запускает аналитику, рекламу и несколько vendor tags; open/close пересчитывает большой DOM; validation выполняет долгую задачу	Разбить работу на задачи, дать браузеру отрисовать состояние кнопки, отложить некритичные интеграции, измерять конкретный interaction target в RUM
CLS	Баннер поздно вставляется сверху в поток, меняет высоту header, исчезает без зарезервированного места	Резервировать место заранее или использовать overlay вне потока там, где это уместно; не схлопывать пустой слот

Fixed overlay, который не двигает document flow, может показать CLS 0 и при этом закрыть всю статью. Поэтому один зеленый показатель не оправдывает навязчивый дизайн.

Промо-виджет можно лениво загрузить после основного содержимого или по близкому к показу событию. Но consent manager должен успеть применить выбор до необязательных tags. Надежная схема важнее механического lazy: обязательный слой без CSS или кнопок на медленной сети тоже блокирует пользователя.

Матрица выбора формата

Условие	Inline-блок	Компактный banner	Non-modal popover	Modal dialog	Отдельная страница
Информация дополняет статью	Лучший выбор	Иногда	По click	Обычно избыточно	Нет
Нужно сообщить о кратком статусе всему сайту	Иногда	Лучший выбор	Нет	Только при критическом подтверждении	Для подробностей
Нужен email для необязательной рассылки	Лучший выбор	После вовлечения	По click	После явного интереса	Иногда
Нужно подтвердить необратимое действие	Нет	Нет	Нет	Лучший выбор	Для сложного процесса
Нужна авторизация в приватный кабинет	Нет	Нет	Иногда	По команде пользователя	Лучший выбор для сложного login/SSO
Индексируемый paywall	Lead-in	Можно показать статус лимита	Нет	Понятное предложение доступа	Страница тарифов как следующий шаг
Обязательный age/consent gate	Зависит от требований	Часто	Редко	Если действительно требуется блокирующий выбор	Не редиректить все индексируемые URL на одну заглушку
Установка приложения	Inline link	Лучший выбор	Нет	Рискованно	Store по click
Чат/callback	Inline CTA	Свернутая кнопка	По click	Только для формы после запроса	Для длинной заявки

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

Как тестировать до запуска

Проверка только на desktop при свежих cookie не покрывает реальные состояния. Составьте матрицу и пройдите каждый вариант вручную.

Функциональные состояния

• новый, вернувшийся и уже конвертированный пользователь;
• consent принят, отклонен, не выбран и отозван;
• cookie/localStorage разрешены и заблокированы;
• вход и выход из аккаунта, исчерпанный лимит paywall;
• переход из Google, Яндекса, рекламы, внутренней страницы и по прямой ссылке;
• on-load, time, scroll, inactivity, exit, end-of-article и click triggers;
• медленная сеть, слабый CPU, ошибка vendor script, ad blocker и пустой ad response.

Устройства и доступность

• ширина 320 пикселей, tablet, desktop, portrait и landscape;
• zoom 200–400%, крупный системный шрифт, экранная клавиатура и safe areas;
• полный маршрут только клавиатурой: open, Tab, Shift+Tab, Submit, Escape, возврат фокуса;
• NVDA/JAWS с Chrome или Edge и VoiceOver с Safari, если они входят в поддержку;
• background inert, scroll lock и восстановление позиции;
• видимость focused control под sticky banner, chat и cookie layer;
• размер и контраст X, Reject, Accept, Cancel и основных кнопок.

Поиск и производительность

Проверьте URL через Google URL Inspection и инструменты Яндекс Вебмастера: заголовок, основной текст и ссылки должны быть в rendered HTML до действий. Сравните mobile и desktop. Для рекламы отдельно смотрите Ad Experience Report, Abusive Experience Report и кабинет сети.

Обычный Lighthouse navigation audit загружает начальное состояние. Он может не дождаться delayed/exit окна, не пройти Accept и не увидеть сдвиг после нескольких минут. Лабораторную проверку дополните записью Performance со всеми действиями, Lighthouse user flow или аналогичным сценарием, CrUX и собственным Real User Monitoring (RUM). INP требует реальных взаимодействий; в лаборатории Total Blocking Time служит только приближением.

Как измерять результат без темных паттернов

Конверсия окна не должна расти за счет ухудшения основной задачи. Сравнивайте одинаковые аудитории и заранее задайте защитные метрики.

Цель	Основная метрика	Защитные метрики
Newsletter	Подтвержденная подписка на 100 подходящих показов	Close/refuse, продолжение чтения, ошибки, отписки, жалобы
Лид или callback	Валидный лид и его качество	Выход со страницы, повторные показы, ошибочные отправки, время до основной цели
Paywall	Оплаченная подписка или регистрация	Доля пользователей, увидевших ценность до стены, возвраты, органический трафик, доступность
Cookie consent	Корректно сохраненный выбор	Время ответа, INP кнопок, ошибки tags, возможность изменить решение
App install	Подтвержденный переход/установка	Доступ к web content, закрытия, mobile exits
Реклама	Доход на сессию	Повторные визиты, accidental clicks, Chrome/network violations, CWV

Сегментируйте данные по устройству, шаблону, trigger, новому/вернувшемуся пользователю и состоянию consent. Отдельно записывайте открытие, закрытие, отказ, успешное действие и продолжение основной задачи. Полезно связать RUM с состоянием modal_shown, чтобы увидеть LCP, INP и CLS именно у экспонированной группы.

Не используйте скрытый отказ, заранее выбранные необязательные согласия, confirmshaming, ложный таймер, фальшивый X или повтор после четкого отказа. В A/B-тесте не показывайте поисковому роботу специальную облегченную страницу. Проверяйте не только прирост формы, но и чистый эффект на лиды, продажи, удержание и органические landing pages.

Чек-лист для внедрения

Перед релизом ответьте «да» на каждый применимый пункт:

• Цель окна нельзя проще решить inline-блоком или компактным banner.
• Промо не закрывает основной контент сразу после входа из поиска.
• На мобильном слой не перекрывает весь экран без реальной необходимости.
• Есть крупная видимая кнопка закрытия; она не ведет на рекламу и не меняет действие.
• Escape закрывает необязательный dialog, Back работает штатно.
• Отказ и закрытие запоминаются; уже выполнивший цель не получает повтор.
• Одновременно не открываются consent, chat, newsletter и рекламный interstitial.
• Основной текст присутствует в rendered HTML без click, scroll или ввода.
• Нет общего редиректа всех URL на consent/age/login страницу.
• Paywall и регистрационный контент размечены и проверены по правилам Google, если должны индексироваться.
• Контент для робота не отличается ради ранжирования; исключения age gate реализованы только после надежной верификации бота.
• Dialog имеет роль, доступное имя, логичный начальный фокус и Tab-цикл.
• Background inert, scroll lock стабилен, после закрытия возвращаются фокус и позиция.
• Все действия доступны с клавиатуры и понятны screen reader.
• Sticky элементы не скрывают focused control; close target имеет достаточный размер.
• Скрипт не блокирует LCP и не запускает все third-party tags одной длинной задачей.
• Для позднего banner зарезервировано место либо выбран осмысленный overlay без сдвига.
• Пройдены mobile, zoom, keyboard, screen reader, slow network и blocked-storage состояния.
• Проверены Google/Яндекс rendered HTML и отдельные отчеты рекламных платформ.
• В эксперименте есть метрики основной задачи, качества лида, отказов и Web Vitals, а не только CTR поп-апа.

Вывод

Безопасная стратегия проста: основной ответ страницы доступен сразу, необязательное промо появляется после осмысленного действия или вовлечения, занимает минимум места и легко закрывается. Обязательные age/consent окна остаются на исходном URL и не превращают весь сайт в одну заглушку. Login и paywall проектируются с учетом того, должен ли закрытый материал индексироваться. Для выбора инструмента под такой сценарий пригодится обзор сервисов для создания поп-апов.

Google дает прямую рекомендацию избегать навязчивых interstitial, но не публикует магическую задержку или площадь. Яндекс прямо связывает удобство с отсутствием завес из рекламы и pop-up и упоминает popup/popunder/clickunder в правилах качества, но отдельного именованного «фильтра за поп-ап» и численного допуска в актуальной публичной справке нет. Лучший критерий для решения — может ли человек и робот сразу получить обещанный страницей результат, а затем без ловушек принять или отклонить дополнительное предложение.