Google рассчитывает Mobile-Friendliness Score, рендеря страницы как мобильное устройство и оценивая такие сигналы, как размер кликабельных элементов, читаемость текста, настройки области просмотра (viewport) и скорость загрузки. Эта оценка используется для повышения позиций удобных для мобильных страниц в мобильном поиске и для добавления метки «Mobile-Friendly» в поисковой выдаче.
Описание
Какую задачу решает
Патент решает проблему низкого качества пользовательского опыта, когда пользователи мобильных устройств посещают ресурсы, не оптимизированные для маленьких экранов. Это включает проблемы с читаемостью текста (необходимость масштабирования), удобством навигации (слишком маленькие или близко расположенные элементы управления), скоростью загрузки и совместимостью контента. Цель изобретения — систематически оценивать удобство ресурсов для мобильных устройств и использовать эту оценку для улучшения качества мобильной поисковой выдачи.
Что запатентовано
Запатентована система и метод для вычисления Mobile-Friendliness Score (Оценки удобства для мобильных устройств) для веб-ресурсов. Этот процесс включает запрос ресурса с идентификацией себя как мобильного агента (mobile agent), рендеринг документа и оценку результата рендеринга по ряду сигналов (mobile-friendliness signals). Полученная оценка сохраняется в индексе и используется для трех основных целей: корректировки ранжирования результатов при поиске с мобильных устройств, добавления визуального индикатора (метки) в поисковой выдаче и предоставления диагностических инструментов для вебмастеров.
Как это работает
Система (Mobile-Friendliness System) работает преимущественно во время индексирования:
- Эмуляция мобильного устройства: Система запрашивает ресурс, указывая, что запрос исходит от мобильного устройства (mobile agent).
- Рендеринг: Полученный документ рендерится с использованием headless browser (браузера без графического интерфейса), включая выполнение JavaScript и применение CSS.
- Оценка сигналов: Система оценивает результат рендеринга по конкретным сигналам: конфигурация viewport, размер текста, размер и расположение кликабельных элементов (tap targets), использование плагинов, скорость загрузки и другие.
- Расчет Score: Оценки по этим сигналам комбинируются в итоговый Mobile-Friendliness Score.
- Применение: При получении поискового запроса с мобильного устройства, этот балл используется Ranking Engine для корректировки позиций или добавления метки к результатам.
Актуальность для SEO
Крайне высокая. Описанные в патенте механизмы лежат в основе оценки качества страниц (Page Experience) и мобильной оптимизации, которые являются ключевыми факторами ранжирования Google. Принципы Mobile-First Indexing и метрики Core Web Vitals напрямую связаны с концепциями, изложенными в этом документе (особенно сигналы скорости загрузки, использования данных и нагрузки на процессор).
Важность для SEO
Патент имеет критическое значение для SEO. Он описывает конкретный механизм, который напрямую влияет на ранжирование всех поисковых запросов, выполняемых с мобильных устройств. Несоответствие требованиям Mobile-Friendliness приводит к понижению в мобильной выдаче. Этот патент формализовал требования к мобильному UX как фактору ранжирования и предоставил инструменты для его оценки.
Детальный разбор
Термины и определения
- 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 (Независимый пункт): Описывает основной процесс вычисления оценки.
- Получение идентификатора ресурса.
- Отправка запроса на сайт, хостящий ресурс.
- Получение документа ресурса в ответ.
- Рендеринг документа.
- Оценка результата рендеринга для определения оценок по одному или нескольким mobile-friendliness signals.
- Вычисление Mobile-Friendliness Score на основе оценок сигналов.
- Ассоциирование 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 (при выполнении условий).
На что влияет
- Типы устройств: Влияет исключительно на результаты поиска, отображаемые на мобильных устройствах (смартфонах, планшетах, носимых устройствах). Патент не описывает применение этих оценок к десктопному поиску.
- Типы контента и запросы: Влияет на все типы контента и все типы запросов, если они выполняются на мобильном устройстве.
Когда применяется
Алгоритм применяется в двух разных контекстах:
- Расчет оценки (Индексирование): Происходит периодически для ресурсов, которые были просканированы поисковой системой, или по запросу через диагностические инструменты.
- Применение оценки (Ранжирование и SERP): Активируется только при условии, что поисковый запрос классифицирован как отправленный с мобильного устройства.
Пороговые значения:
- Для ранжирования: Mobile-Friendliness Score используется как множитель или добавочный фактор к основной оценке ранжирования.
- Для маркировки в SERP: Mobile-Friendliness Score должен превысить определенный порог, чтобы ресурс считался достаточно оптимизированным для получения метки «Mobile-Friendly».
Пошаговый алгоритм
Процесс А: Вычисление Mobile-Friendliness Score (Этап Индексирования)
- Идентификация ресурса: Система получает данные о ресурсе (например, после сканирования).
- Запрос ресурса как Mobile Agent: Система отправляет запрос на хостинг ресурса, указывая, что запрос исходит от мобильного устройства.
- Получение документа: Система получает документ ресурса и связанные с ним внешние ресурсы.
- Рендеринг: Система рендерит документ с помощью headless browser, выполняя JavaScript и применяя CSS.
- Оценка сигналов: Система анализирует результат рендеринга для вычисления оценок по каждому из mobile-friendliness signals (например, измеряет размер текста, расстояние между tap targets, проверяет конфигурацию viewport, фиксирует время загрузки).
- Вычисление итоговой оценки: Система комбинирует оценки сигналов (например, взвешенная сумма) для генерации overall signal score. Эта оценка может быть нормализована с помощью функции сжатия (squashing function) для маппинга в определенный диапазон (например, 0-100) для получения финального Mobile-Friendliness Score.
- Сохранение: Mobile-Friendliness Score и, опционально, оценки сигналов ассоциируются с ресурсом в индексе.
Процесс Б: Применение оценки при ранжировании (Этап Обработки Запроса)
- Получение запроса и результатов: Система получает запрос и генерирует начальный набор результатов с initial ranking scores.
- Классификация устройства: Система определяет, был ли запрос отправлен с мобильного устройства.
- Проверка условия активации: Если устройство не мобильное, используются стандартные оценки. Если мобильное, процесс продолжается.
- Получение Mobile-Friendliness Scores: Система извлекает из индекса Mobile-Friendliness Score для каждого результата.
- Корректировка оценок: Система корректирует initial ranking score каждого ресурса, используя его Mobile-Friendliness Score (например, путем умножения или сложения, возможно после масштабирования), чтобы получить modified score.
- Ранжирование: Результаты ранжируются в соответствии с modified scores.
Процесс В: Модификация SERP (Этап Обработки Запроса)
- Проверка условий: Выполняется после Процесса Б, если запрос пришел с мобильного устройства.
- Сравнение с порогом: Для каждого результата система проверяет, превышает ли его Mobile-Friendliness Score установленный порог.
- Модификация результата: Если порог превышен, система модифицирует сниппет результата, добавляя индикатор (например, метку «Mobile-Friendly»).
- Предоставление результатов: Модифицированная поисковая выдача отправляется пользователю.
Какие данные и как использует
Данные на входе
Система анализирует данные, полученные в процессе рендеринга страницы как 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).
Выводы
- Mobile-Friendliness — прямой фактор ранжирования для мобильного поиска: Патент четко описывает механизм, при котором Mobile-Friendliness Score используется для корректировки initial ranking score, если запрос сделан с мобильного устройства. Это не просто рекомендация, а конкретный алгоритмический фактор.
- Оценка основана на рендеринге (Rendering-Based Evaluation): Система не просто анализирует статический HTML. Она использует headless browser для выполнения JavaScript и применения CSS, чтобы оценить страницу так, как ее видит пользователь. Блокировка ресурсов, необходимых для рендеринга, негативно скажется на оценке.
- Критичность сканирования как Mobile Agent: Система специально запрашивает ресурс как mobile agent. Это означает, что сайт должен корректно определять мобильный трафик и отдавать оптимизированную версию (будь то адаптивный дизайн, динамический показ или отдельный мобильный сайт).
- Конкретные и измеримые UX-сигналы: Патент перечисляет очень конкретные сигналы, влияющие на оценку: читаемость текста, удобство нажатия на элементы, конфигурация viewport, скорость и использование ресурсов устройства. Это дает четкие ориентиры для оптимизации.
- Предварительный расчет оценки: Mobile-Friendliness Score рассчитывается на этапе индексирования и сохраняется в индексе. Это позволяет быстро применять его во время ранжирования без необходимости рендеринга в реальном времени.
- Три применения технологии: Патент описывает использование оценки не только для ранжирования, но и для добавления метки в SERP (повышение CTR для оптимизированных сайтов) и для предоставления диагностических инструментов вебмастерам (например, Google Mobile-Friendly Test Tool).
Практика
Best practices (это мы делаем)
- Внедрение адаптивного дизайна (Responsive Web Design): Убедитесь, что используется мета-тег viewport с device-width. Это напрямую влияет на Viewport configuration signal и Viewable area signal.
- Оптимизация кликабельных элементов (Tap Targets): Обеспечьте достаточный размер (например, минимум 48×48 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
- Ситуация: Страница категории товаров ранжируется на 5 позиции в мобильном поиске. Анализ показывает, что кнопки «Купить» и фильтры слишком маленькие и расположены близко.
- Действия (на основе патента): Вебмастер увеличивает размер кнопок до 48px и увеличивает отступы между элементами фильтрации.
- Результат: При следующем индексировании система фиксирует улучшение Tap target signal. Mobile-Friendliness Score страницы увеличивается. При обработке мобильных запросов Ranking Engine применяет более высокий коэффициент к initial ranking score страницы. Страница поднимается с 5 на 2 позицию в мобильной выдаче.
Сценарий 2: Использование диагностического инструмента для исправления ошибок рендеринга
- Ситуация: Вебмастер запускает проверку главной страницы через Google Mobile-Friendly Test (инструмент, описанный в Claims 12-14).
- Результат анализа: Инструмент показывает 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».
- Действия: Вебмастер добавляет мета-тег <meta name=»viewport» content=»width=device-width, initial-scale=1.0″> и увеличивает базовый размер шрифта в CSS с 12px до 16px.
- Результат: Повторная проверка показывает Mobile-Friendliness Score: 95. Страница получает метку «Mobile-Friendly» в SERP и улучшает свои позиции в мобильном поиске.
Вопросы и ответы
Влияет ли Mobile-Friendliness Score на ранжирование в десктопном поиске?
Согласно патенту, механизм корректировки ранжирования активируется только в том случае, если система определяет, что запрос был отправлен с мобильного устройства. Патент не описывает использование этого конкретного Mobile-Friendliness Score для корректировки ранжирования на десктопах. Однако с переходом на Mobile-First Indexing, Google использует мобильную версию сайта для индексации и ранжирования на всех устройствах, поэтому проблемы с мобильной версией могут косвенно влиять и на десктоп.
Какие основные сигналы используются для расчета Mobile-Friendliness Score?
Патент выделяет 8 ключевых сигналов: Viewport configuration signal (настройка области просмотра), Viewable area signal (отсутствие горизонтальной прокрутки), Text size signal (читаемость текста), Tap target signal (размер и расстояние между элементами), Plugin signal (отсутствие неподдерживаемых плагинов), а также сигналы производительности: Resource load speed signal (скорость загрузки), Data usage signal (объем данных) и Processor load signal (нагрузка на процессор).
Как система определяет, что сайт удобен для мобильных? По статическому коду или через рендеринг?
Система использует рендеринг. В патенте описано использование headless browser для загрузки страницы, выполнения JavaScript и применения CSS точно так же, как это делает обычный браузер. Оценка производится на основе того, как страница выглядит и функционирует после полного рендеринга, а не просто по анализу исходного HTML-кода.
Насколько важна скорость загрузки в контексте этого патента?
Скорость загрузки очень важна. Патент явно включает Resource load speed signal как один из компонентов Mobile-Friendliness Score. Кроме того, упоминаются Data usage signal и Processor load signal, которые также связаны с производительностью. Это подчеркивает важность оптимизации скорости для мобильного ранжирования задолго до введения Core Web Vitals.
Как этот патент связан с Core Web Vitals (CWV)?
Этот патент можно рассматривать как предшественника или часть более широкой системы Page Experience, включающей CWV. Сигналы производительности (скорость загрузки, нагрузка на процессор) напрямую связаны с метриками CWV (LCP, FID/INP, CLS). Сигналы юзабилити (Tap Targets, Text Size) дополняют CWV, фокусируясь на удобстве взаимодействия. Вместе они формируют комплексную оценку качества страницы на мобильных устройствах.
Что произойдет, если мой сайт использует отдельный мобильный URL (m.example.com)?
Патент применим и к таким конфигурациям. Ключевым моментом является то, что система запрашивает ресурс как mobile agent. Ваш сервер должен корректно распознать этот агент и перенаправить его на соответствующий мобильный URL. Затем система проанализирует контент на этом мобильном URL для расчета Mobile-Friendliness Score. Важно, чтобы перенаправления и канонические ссылки были настроены правильно.
Использует ли Google до сих пор метку «Mobile-Friendly» в поисковой выдаче?
Патент описывает механизм добавления этой метки (Claim 11), если оценка превышает порог. Хотя Google ранее активно использовал эту метку, со временем ее использование в интерфейсе SERP было сокращено, так как большинство сайтов стали оптимизированными для мобильных. Однако сам механизм оценки и ее использование в ранжировании остаются актуальными.
Что такое Headless Browser и почему он используется?
Headless browser — это браузер без графического интерфейса. Он используется потому, что позволяет системе программно рендерить веб-страницы в масштабе, необходимом для индексирования интернета, без затрат ресурсов на отображение интерфейса пользователя. Это обеспечивает точную оценку того, как страница будет выглядеть и работать на реальном устройстве пользователя.
Как рассчитывается итоговый Mobile-Friendliness Score? Это среднее значение всех сигналов?
Патент указывает, что оценки сигналов комбинируются, но не дает точной формулы. Упоминаются различные методы комбинирования, такие как взвешенная сумма или взвешенное произведение. Это означает, что некоторые сигналы (например, корректный viewport) могут иметь больший вес, чем другие. Итоговая оценка также может быть нормализована в определенный диапазон (например, 0-100).
Если Google Search Console показывает проблемы с удобством на мобильных, означает ли это, что мой сайт пессимизируется?
Да, это весьма вероятно. Отчеты в GSC основаны на данных, собранных механизмом, описанным в этом патенте. Если система идентифицирует проблемы (например, слишком мелкий шрифт или близко расположенные элементы), это означает, что Mobile-Friendliness Score снижен. Этот сниженный балл используется для корректировки ранжирования в мобильном поиске, что фактически является пессимизацией по сравнению с оптимизированными сайтами.