Как Google рассчитывает и использует оценки Mobile-Friendliness для ранжирования результатов и маркировки сайтов

Термины и определения

Data usage signal (Сигнал использования данных)

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

Headless browser (Браузер без графического интерфейса)

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

Mobile agent (Мобильный агент)

Идентификатор (например, User-Agent), используемый системой при запросе ресурса, чтобы сообщить сайту, что ресурс запрашивается для отображения на мобильном устройстве.

Mobile Device (Мобильное устройство)

Пользовательский компьютер с уменьшенной областью просмотра (маленьким размером дисплея). Примеры включают смартфоны, планшеты и носимые устройства (wearables).

Mobile-Friendliness Score (Оценка удобства для мобильных устройств)

Итоговая оценка, представляющая степень оптимизации ресурса для просмотра и взаимодействия на мобильных устройствах. Вычисляется на основе комбинации сигналов mobile-friendliness signals.

Mobile-Friendliness System

Компонент поисковой системы, отвечающий за анализ ресурсов и определение Mobile-Friendliness Score.

Plugin signal (Сигнал плагинов)

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

Processor load signal (Сигнал нагрузки на процессор)

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

Resource load speed signal (Сигнал скорости загрузки ресурса)

Сигнал, измеряющий время от запроса ресурса до его полного рендеринга.

Tap target signal (Сигнал кликабельных элементов)

Сигнал, оценивающий, не расположены ли кликабельные элементы (кнопки, ссылки, поля форм) слишком близко друг к другу или не являются ли они слишком маленькими для эффективного взаимодействия.

Text size signal (Сигнал размера текста)

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

Viewable area signal (Сигнал видимой области)

Сигнал, зависящий от того, какая часть общей площади контента видна после рендеринга (т.е. оценка наличия горизонтальной прокрутки).

Viewport configuration signal (Сигнал конфигурации области просмотра)

Сигнал, оценивающий, как документ конфигурирует область просмотра (viewport), обычно с помощью мета-тега. Оценивается, задан ли viewport, является ли он фиксированным или адаптивным.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает основной процесс вычисления оценки.

1. Получение идентификатора ресурса.
2. Отправка запроса на сайт, хостящий ресурс.
3. Получение документа ресурса в ответ.
4. Рендеринг документа.
5. Оценка результата рендеринга для определения оценок по одному или нескольким mobile-friendliness signals.
6. Вычисление Mobile-Friendliness Score на основе оценок сигналов.
7. Ассоциирование Mobile-Friendliness Score с ресурсом в индексе.

Claim 2 (Зависимый от 1): Уточняет критически важную деталь процесса запроса.

Запрос ресурса отправляется как mobile agent. Это гарантирует, что сервер предоставит версию сайта, предназначенную для мобильных устройств (если она отличается от десктопной).

Claims 4-9 (Зависимые от 1): Перечисляют конкретные примеры mobile-friendliness signals, используемых при оценке.

Сигналы включают: Plugin signal (Claim 4), Viewport configuration signal (Claim 5), Viewable area signal (Claim 6), Tap target signal (близость элементов, Claim 7; размер элементов, Claim 8), Text size signal (Claim 9).

Claim 10 (Зависимый от 1) и Claim 15 (Независимый): Описывают применение оценки в ранжировании.

Система получает поисковый запрос и определяет, что он был отправлен с мобильного устройства. В ответ на это, система корректирует исходную оценку ранжирования (initial ranking score) ресурса, используя его Mobile-Friendliness Score, чтобы получить модифицированную оценку ранжирования.

Claim 11 (Зависимый от 1): Описывает применение оценки для модификации SERP.

Если запрос пришел с мобильного устройства и Mobile-Friendliness Score ресурса превышает пороговое значение, система модифицирует результат поиска, добавляя индикатор (метку или значок), указывающий, что ресурс удобен для мобильных устройств.

Claims 12-14 (Зависимые от 1): Описывают использование системы в качестве диагностического инструмента.

Система получает запрос на анализ ресурса (например, от вебмастера). Она генерирует анализ на основе Mobile-Friendliness Score и оценок сигналов и предоставляет его пользователю. Анализ может включать данные об оценках сигналов (Claim 13) или рекомендации по модификации ресурса для улучшения оценки, выведенные из оценок сигналов (Claim 14).

Где и как применяется

Изобретение затрагивает несколько ключевых этапов поисковой архитектуры.

CRAWLING – Сканирование и Сбор данных
На этом этапе система должна запросить ресурс, идентифицируя себя как mobile agent. Это необходимо для получения контента, который сайт отдает мобильным устройствам.

INDEXING – Индексирование и извлечение признаков
Основное применение патента. После получения контента Mobile-Friendliness System выполняет рендеринг документа с помощью headless browser. Производится оценка mobile-friendliness signals и вычисляется итоговый Mobile-Friendliness Score. Эта оценка сохраняется в Index Database вместе с ресурсом.

RANKING / RERANKING – Ранжирование и Переранжирование
Во время обработки запроса система определяет, было ли устройство пользователя мобильным. Если да, Ranking Engine извлекает предварительно рассчитанный Mobile-Friendliness Score из индекса и использует его для корректировки initial ranking score ресурса, генерируя modified ranking score.

METASEARCH – Метапоиск и Смешивание (Генерация SERP)
На этапе формирования поисковой выдачи система может проверить, превышает ли Mobile-Friendliness Score ресурса определенный порог. Если да, и запрос пришел с мобильного устройства, система модифицирует сниппет результата, добавляя визуальный индикатор (например, метку "Mobile-Friendly").

Входные данные (Индексирование):

• Идентификатор ресурса (URL).
• Документ ресурса (HTML) и связанные ресурсы (CSS, JS, изображения), полученные в ответ на запрос от mobile agent.

Выходные данные (Индексирование):

• Mobile-Friendliness Score для ресурса.
• Индивидуальные оценки сигналов (signal scores).

Входные данные (Ранжирование):

• Поисковый запрос.
• Данные, классифицирующие запрос как отправленный с мобильного устройства.
• Набор результатов поиска с initial ranking scores.
• Mobile-Friendliness Scores для каждого результата.

Выходные данные (Ранжирование):

• Набор результатов поиска с modified ranking scores.
• Модифицированные сниппеты с индикатором Mobile-Friendly (при выполнении условий).

На что влияет

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

Когда применяется

Алгоритм применяется в двух разных контекстах:

1. Расчет оценки (Индексирование): Происходит периодически для ресурсов, которые были просканированы поисковой системой, или по запросу через диагностические инструменты.
2. Применение оценки (Ранжирование и SERP): Активируется только при условии, что поисковый запрос классифицирован как отправленный с мобильного устройства.

Пороговые значения:

• Для ранжирования: Mobile-Friendliness Score используется как множитель или добавочный фактор к основной оценке ранжирования.
• Для маркировки в SERP: Mobile-Friendliness Score должен превысить определенный порог, чтобы ресурс считался достаточно оптимизированным для получения метки "Mobile-Friendly".

Пошаговый алгоритм

Процесс А: Вычисление Mobile-Friendliness Score (Этап Индексирования)

1. Идентификация ресурса: Система получает данные о ресурсе (например, после сканирования).
2. Запрос ресурса как Mobile Agent: Система отправляет запрос на хостинг ресурса, указывая, что запрос исходит от мобильного устройства.
3. Получение документа: Система получает документ ресурса и связанные с ним внешние ресурсы.
4. Рендеринг: Система рендерит документ с помощью headless browser, выполняя JavaScript и применяя CSS.
5. Оценка сигналов: Система анализирует результат рендеринга для вычисления оценок по каждому из mobile-friendliness signals (например, измеряет размер текста, расстояние между tap targets, проверяет конфигурацию viewport, фиксирует время загрузки).
6. Вычисление итоговой оценки: Система комбинирует оценки сигналов (например, взвешенная сумма) для генерации overall signal score. Эта оценка может быть нормализована с помощью функции сжатия (squashing function) для маппинга в определенный диапазон (например, 0-100) для получения финального Mobile-Friendliness Score.
7. Сохранение: Mobile-Friendliness Score и, опционально, оценки сигналов ассоциируются с ресурсом в индексе.

Процесс Б: Применение оценки при ранжировании (Этап Обработки Запроса)

1. Получение запроса и результатов: Система получает запрос и генерирует начальный набор результатов с initial ranking scores.
2. Классификация устройства: Система определяет, был ли запрос отправлен с мобильного устройства.
3. Проверка условия активации: Если устройство не мобильное, используются стандартные оценки. Если мобильное, процесс продолжается.
4. Получение Mobile-Friendliness Scores: Система извлекает из индекса Mobile-Friendliness Score для каждого результата.
5. Корректировка оценок: Система корректирует initial ranking score каждого ресурса, используя его Mobile-Friendliness Score (например, путем умножения или сложения, возможно после масштабирования), чтобы получить modified score.
6. Ранжирование: Результаты ранжируются в соответствии с modified scores.

Процесс В: Модификация SERP (Этап Обработки Запроса)

1. Проверка условий: Выполняется после Процесса Б, если запрос пришел с мобильного устройства.
2. Сравнение с порогом: Для каждого результата система проверяет, превышает ли его Mobile-Friendliness Score установленный порог.
3. Модификация результата: Если порог превышен, система модифицирует сниппет результата, добавляя индикатор (например, метку "Mobile-Friendly").
4. Предоставление результатов: Модифицированная поисковая выдача отправляется пользователю.

Какие данные и как использует

Данные на входе

Система анализирует данные, полученные в процессе рендеринга страницы как mobile agent.

• Технические факторы:
  • Код ответа сервера.
  • Время загрузки (используется для Resource load speed signal).
  • Объем передаваемых данных (используется для Data usage signal).
  • Нагрузка на процессор во время рендеринга и взаимодействия (используется для Processor load signal).
  • Использование внешних ресурсов (CSS, JS).
• Структурные и Контентные факторы:
  • Мета-теги: В частности, тег конфигурации viewport (используется для Viewport configuration signal).
  • Текст: Размер шрифта после рендеринга (используется для Text size signal).
  • Элементы интерфейса (ссылки, кнопки, поля форм): Их размер и расстояние друг от друга после рендеринга (используется для Tap target signal).
  • Общая компоновка: Соотношение видимой области контента к общей площади контента (используется для Viewable area signal).
• Мультимедиа факторы:
  • Использование контента, требующего плагинов (используется для Plugin signal).
• Пользовательские факторы (при обработке запроса):
  • Тип устройства пользователя (мобильное или нет) используется как триггер для применения оценок.

Какие метрики используются и как они считаются

Система вычисляет оценки для нескольких конкретных сигналов:

• Plugin signal: Рассчитывается как доля контента (например, по площади экрана), требующего плагина для отображения.
• Viewport configuration signal: Используется маппинг конфигураций. Адаптивный viewport (например, device-width) получает лучшую оценку, отсутствие viewport или фиксированная ширина — худшую.
• Viewable area signal: Рассчитывается как пропорция общей площади контента, которая видна на экране после рендеринга (без прокрутки).
• Tap target signal: Подсчитывается количество элементов, которые меньше порогового размера или находятся ближе порогового расстояния к другому элементу.
• Text size signal: Рассчитывается пропорция текста, размер которого меньше порогового значения.
• Resource load speed signal: Измеряется время до полного рендеринга.
• Data usage signal: Измеряется общий объем загруженных данных.
• Processor load signal: Измеряется использование вычислительных ресурсов.

Вычисление итоговой оценки:

Mobile-Friendliness Score вычисляется путем комбинирования индивидуальных оценок сигналов. Методы комбинирования могут включать взвешенную сумму, взвешенное произведение или вычисление меры центральной тенденции. Итоговая оценка может быть подвергнута функции сжатия (squashing function) для маппинга в определенный диапазон (например, 0-100).

1. Mobile-Friendliness — прямой фактор ранжирования для мобильного поиска: Патент четко описывает механизм, при котором Mobile-Friendliness Score используется для корректировки initial ranking score, если запрос сделан с мобильного устройства. Это не просто рекомендация, а конкретный алгоритмический фактор.
2. Оценка основана на рендеринге (Rendering-Based Evaluation): Система не просто анализирует статический HTML. Она использует headless browser для выполнения JavaScript и применения CSS, чтобы оценить страницу так, как ее видит пользователь. Блокировка ресурсов, необходимых для рендеринга, негативно скажется на оценке.
3. Критичность сканирования как Mobile Agent: Система специально запрашивает ресурс как mobile agent. Это означает, что сайт должен корректно определять мобильный трафик и отдавать оптимизированную версию (будь то адаптивный дизайн, динамический показ или отдельный мобильный сайт).
4. Конкретные и измеримые UX-сигналы: Патент перечисляет очень конкретные сигналы, влияющие на оценку: читаемость текста, удобство нажатия на элементы, конфигурация viewport, скорость и использование ресурсов устройства. Это дает четкие ориентиры для оптимизации.
5. Предварительный расчет оценки: Mobile-Friendliness Score рассчитывается на этапе индексирования и сохраняется в индексе. Это позволяет быстро применять его во время ранжирования без необходимости рендеринга в реальном времени.
6. Три применения технологии: Патент описывает использование оценки не только для ранжирования, но и для добавления метки в SERP (повышение CTR для оптимизированных сайтов) и для предоставления диагностических инструментов вебмастерам (например, Google Mobile-Friendly Test Tool).

Best practices (это мы делаем)

• Внедрение адаптивного дизайна (Responsive Web Design): Убедитесь, что используется мета-тег viewport с device-width. Это напрямую влияет на Viewport configuration signal и Viewable area signal.
• Оптимизация кликабельных элементов (Tap Targets): Обеспечьте достаточный размер (например, минимум 48x48 CSS пикселей) и расстояние между ссылками, кнопками и полями форм. Это критично для Tap target signal.
• Контроль размера шрифта: Используйте базовый размер шрифта (например, 16px) и масштабируемые единицы измерения, чтобы текст оставался читаемым без масштабирования на маленьких экранах. Это влияет на Text size signal.
• Оптимизация скорости и производительности: Работайте над улучшением времени загрузки и рендеринга. Это включает оптимизацию объема данных и эффективности выполнения скриптов, что влияет на Resource load speed signal, Data usage signal и Processor load signal. (Прямая связь с Core Web Vitals).
• Отказ от устаревших технологий: Избегайте использования плагинов (например, Flash) для отображения основного контента, так как они часто не поддерживаются мобильными браузерами (Plugin signal).
• Обеспечение доступности ресурсов для Mobile Agent: Убедитесь, что Googlebot (смартфон) может получить доступ ко всем CSS и JavaScript файлам, необходимым для корректного рендеринга мобильной версии сайта.
• Использование диагностических инструментов Google: Регулярно проверяйте ключевые шаблоны страниц с помощью инструментов, основанных на этом патенте (например, Mobile-Friendly Test, отчеты в Google Search Console), чтобы получать диагностическую информацию (Claims 12-14).

Worst practices (это делать не надо)

• Использование фиксированной ширины для мобильных устройств: Установка фиксированного viewport или использование элементов с фиксированной шириной, превышающей ширину экрана мобильного устройства, приведет к горизонтальной прокрутке и низким оценкам по Viewport configuration signal и Viewable area signal.
• Игнорирование юзабилити навигации: Размещение ссылок слишком близко друг к другу или использование мелких кнопок ухудшит Tap target signal и приведет к понижению в ранжировании.
• Блокировка CSS/JS в robots.txt: Если ресурсы, необходимые для формирования мобильного макета, заблокированы от сканирования, система не сможет корректно отрендерить страницу и присвоит низкий Mobile-Friendliness Score.
• Некорректная обработка Mobile Agent (Клоакинг): Отдача разного контента пользователям и поисковому боту (mobile agent) является нарушением правил и может привести к санкциям, помимо проблем с расчетом Mobile-Friendliness Score.
• Использование ресурсоемких скриптов и стилей: Тяжелые фреймворки и неоптимизированный код, которые вызывают высокую нагрузку на процессор при рендеринге или прокрутке, негативно повлияют на Processor load signal.

Стратегическое значение

Этот патент является фундаментальным для современного SEO. Он закрепил переход от простого наличия мобильной версии к оценке качества пользовательского опыта на мобильных устройствах как ключевого фактора ранжирования. Он стал основой для последующих инициатив, таких как Mobile-First Indexing (где мобильная версия становится основной для индексации и ранжирования) и Page Experience Update (включая Core Web Vitals). Стратегия SEO должна быть построена вокруг обеспечения идеального мобильного опыта, основанного на скорости, читаемости и удобстве взаимодействия.

Практические примеры

Сценарий 1: Повышение ранжирования интернет-магазина за счет оптимизации UX

1. Ситуация: Страница категории товаров ранжируется на 5 позиции в мобильном поиске. Анализ показывает, что кнопки "Купить" и фильтры слишком маленькие и расположены близко.
2. Действия (на основе патента): Вебмастер увеличивает размер кнопок до 48px и увеличивает отступы между элементами фильтрации.
3. Результат: При следующем индексировании система фиксирует улучшение Tap target signal. Mobile-Friendliness Score страницы увеличивается. При обработке мобильных запросов Ranking Engine применяет более высокий коэффициент к initial ranking score страницы. Страница поднимается с 5 на 2 позицию в мобильной выдаче.

Сценарий 2: Использование диагностического инструмента для исправления ошибок рендеринга

1. Ситуация: Вебмастер запускает проверку главной страницы через Google Mobile-Friendly Test (инструмент, описанный в Claims 12-14).
2. Результат анализа: Инструмент показывает Mobile-Friendliness Score: 65 и предоставляет рекомендации: "The viewport for your page is not properly configured" и "Increasing the size of the text on your page may make your page more mobile-friendly".
3. Действия: Вебмастер добавляет мета-тег <meta name="viewport" content="width=device-width, initial-scale=1.0"> и увеличивает базовый размер шрифта в CSS с 12px до 16px.
4. Результат: Повторная проверка показывает Mobile-Friendliness Score: 95. Страница получает метку "Mobile-Friendly" в SERP и улучшает свои позиции в мобильном поиске.