Главная›Глоссарий›Page Experience Update

Page Experience Update

Алгоритм за качество пользовательского опыта

Учёт скорости и удобства как фактора ранжирования.

Page Experience Update — обновление Google с 2021 года, которое формализовало учёт пользовательского опыта в ранжировании. Включает Core Web Vitals (LCP, CLS, INP), мобильность, HTTPS, отсутствие интерстициальной рекламы во весь экран.

Сам по себе фактор не очень сильный — при прочих равных лучшая страница по UX поднимается выше. Но между двумя сайтами с одинаковым контентом и ссылками может стать решающим.

Скорость
Core Web Vitals

LCP < 2.5с, INP < 200мс, CLS < 0.1 — порог зелёной зоны

Mobile
и mobile-first

Адаптивная вёрстка, touch-targets ≥ 44×44px, нет горизонтального скролла

Безопасность
и без агрессивной рекламы

HTTPS, нет malware, нет блокирующих интерстишелов, нет всплывашек

Page Experience: совокупный сигнал Google о качестве пользовательского опыта. Включает CWV, mobile, HTTPS и «без раздражений»
Пример из практики

Два конкурента с одинаковым контентом и ссылками. У первого все Core Web Vitals в зелёной зоне, у второго — LCP «poor». Первый стабильно выше на 1–2 позиции.

Ключевой нюанс: Page Experience — это тай-брейкер. Никакого буста он не даёт. Google прямо называл его сигналом, который решает исход между релевантно равными страницами; вытащить слабый по смыслу документ за счёт зелёных Core Web Vitals он не способен. Поэтому гнаться за идеальными цифрами на странице, которая и так в топ-3 по интенту, смысла мало — выигрыш дают пограничные запросы, где вы делите 5–8 позицию с похожими по контенту конкурентами.

Частая ошибка — мерить «page experience» только лабораторными прогонами Lighthouse. Ранжирование опирается на полевые данные реальных пользователей из CrUX (Chrome User Experience Report), и оценка ставится по 75-му перцентилю за 28 дней. Поэтому изменения в коде проявляются в отчёте «Удобство для пользователей» Search Console с задержкой в несколько недель, а на сайтах с низким трафиком CrUX-данных может не быть вовсе — тогда Google смотрит агрегат по типу страниц или по всему origin. У Яндекса отдельного аналога нет: поведенческие и скоростные сигналы он учитывает иначе, через отклик интерфейсаи метрики вовлечённости в Метрике, без стандартизированного набора порогов.

Смежные термины
HTTPSLCPCLSINP

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

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

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

Насколько сильно эти сигналы влияют на позиции?

Умеренно: они работают как уточнение при сопоставимом качестве страниц. Материал, который лучше отвечает на запрос, обгонит быструю страницу с поверхностным содержанием.

Что входит в набор сигналов?

Основные веб-показатели скорости и стабильности, удобство на мобильных, защищённое соединение и отсутствие навязчивых окон, перекрывающих содержание при входе на страницу.

Где проверить свои показатели?

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

С чего начать улучшение?

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

Спросите нейросети про «Page Experience Update»

Отвечает DeepSeek