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

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

Device Identification Data (Идентификационные данные устройства)

Данные, определяющие тип устройства, инициировавшего запрос. Включают User-Agent header (бренд, модель, версия ПО, тип браузера), а также могут включать Language Setting Data и Cookies.

Mobile Resource (Мобильный ресурс)

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

Redirect Index (Индекс редиректов)

База данных, хранящая информацию о выявленных редиректах. Содержит исходный URL, конечный URL и условия (Redirect Conditions), при которых происходит редирект (например, только для мобильных устройств).

Redirect Reduction Apparatus (Устройство сокращения редиректов)

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

Redirect Resource (Редиректный ресурс)

Ресурс (URL), который при запросе не отдает контент, а перенаправляет устройство пользователя на другой ресурс (Different Resource).

Standard Resource (Стандартный ресурс)

Ресурс, который не вызывает редирект при запросе (конечная точка в цепочке редиректов).

Transient Redirect Resource (Временный редиректный ресурс)

Редиректный ресурс, который перенаправляет на временный URL (Transient Resource), который часто меняется (например, содержит динамические ID сессии).

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

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

1. Система получает набор релевантных ресурсов и идентификационные данные, указывающие, что устройство пользователя относится к первому типу (например, мобильное).
2. До предоставления результатов поиска система определяет, что конкретный ресурс из набора перенаправляет устройства первого типа на другой ресурс, отформатированный для этого типа. При этом подчеркивается, что устройства второго типа (например, десктопные) на этот другой ресурс не перенаправляются (условный редирект).
3. В ответ на это определение и до показа выдачи, система удаляет из результата поиска ссылку на исходный ресурс и заменяет её ссылкой на конечный ресурс редиректа.
4. Модифицированный набор результатов поиска предоставляется пользователю.

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

Определение того, что устройство относится к первому типу, включает идентификацию его как мобильного устройства. Определение факта редиректа основывается на предварительно полученных redirect data (Индексе редиректов), которые подтверждают, что исходный ресурс перенаправляет мобильные устройства.

Claim 9 (Зависимый - Исключение): Описывает ситуацию, когда модификация НЕ применяется из-за неполноты данных о редиректах, основанных на бренде (brand-based redirect).

Если система определяет, что ресурс использует редиректы в зависимости от бренда устройства (например, iPhone направляется на один URL, а Android на другой), И система определяет, что данные о редиректах доступны не для всех брендов (not available for at least one brand), то результат поиска предоставляется с исходной ссылкой, без модификации.

Claim 10 (Зависимый - Исключение): Описывает аналогичное исключение для редиректов, основанных на языке (language-based redirect).

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

Claim 11 (Зависимый - Исключение): Описывает исключение для временных редиректов (transient redirect resource).

Если система определяет, что ресурс перенаправляет пользователя на временный URL (transient resource), то результат поиска предоставляется с исходной ссылкой, без включения ссылки на этот временный URL.

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

Изобретение затрагивает несколько этапов поиска, интегрируя офлайн-анализ с обработкой запросов в реальном времени.

CRAWLING – Сканирование и Сбор данных
Redirect Reduction Apparatus активно участвует в сканировании. Ключевая особенность — эмуляция различных типов устройств (изменение User-Agent, языковых настроек) при запросе одного и того же URL. Это позволяет обнаружить условные редиректы, которые стандартный краулер может не увидеть.

INDEXING – Индексирование и извлечение признаков
Результаты сканирования с эмуляцией сохраняются в специализированном Redirect Index. Индексируются не только сами факты редиректов, но и условия их возникновения (например, "URL A -> URL B, только если User-Agent = Смартфон").

RANKING – Ранжирование
Система генерирует стандартный набор результатов поиска.

RERANKING / METASEARCH – Переранжирование / Смешивание
Основное применение патента происходит на этом финальном этапе перед показом выдачи пользователю. Redirect Reduction Apparatus перехватывает сгенерированную выдачу, анализирует Device Identification Data текущего пользователя и сверяет URL в выдаче с Redirect Index. Происходит модификация (замена) URL в реальном времени.

Входные данные:

• Исходный набор результатов поиска (SERP).
• Device Identification Data пользователя (User-Agent, язык, cookies).
• Redirect Index (предварительно рассчитанные данные о редиректах).

Выходные данные:

• Модифицированный набор результатов поиска с замененными URL для сокращения редиректов.

На что влияет

• Конфигурации мобильных сайтов: Наибольшее влияние оказывается на сайты, использующие отдельные URL для мобильных версий (m-dot сайты) или динамический показ контента (Dynamic Serving), где конфигурация сервера определяет редирект или показ контента на основе User-Agent.
• Типы контента: Влияет на любые типы контента, где применяются условные редиректы.
• Географические и языковые аспекты: Влияет на сайты, использующие редиректы на основе языка пользователя, но с ограничениями (см. Claim 10).

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

• Условия применения: Алгоритм модификации применяется, когда выполняются все следующие условия:
  1. Ресурс в выдаче идентифицирован в Redirect Index как Redirect Resource.
  2. Device Identification Data текущего пользователя соответствуют условиям редиректа, указанным в индексе (например, пользователь использует смартфон).
  3. Редирект не попадает под исключения: данные полны (не являются частичными brand-based или language-based) и редирект не является временным (transient).
• Триггеры активации: Получение запроса от пользователя и генерация поисковой выдачи, содержащей ссылки на известные Redirect Resources.

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

Процесс А: Офлайн-сбор данных (Построение Redirect Index)

1. Эмуляция и Запрос: Redirect Reduction Apparatus выбирает ресурс (URL A) и отправляет запрос к серверу паблишера, эмулируя устройство Типа 1 (например, Смартфон, User-Agent X).
2. Анализ ответа: Система анализирует ответ от сервера.
   • Если получен контент (Standard Resource): Запись в Redirect Index, что URL A для Типа 1 не является редиректом.
   • Если получена инструкция редиректа (Redirect Instruction) на URL B: Переход к шагу 3.
3. Следование редиректу: Система отправляет запрос на URL B. Процесс повторяется до получения Standard Resource (URL Z) или достижения лимита редиректов.
4. Идентификация и Хранение: В Redirect Index сохраняется цепочка (URL A -> URL Z) и условия (Тип 1, User-Agent X).
5. Анализ исключений: Система анализирует URL Z и условия редиректа, чтобы определить, является ли редирект специфичным для бренда, языка или временным (transient).
6. Повторение для других типов: Процесс повторяется для того же URL A, но с эмуляцией других типов устройств (например, Десктоп, другие бренды, другие языки) для построения полного профиля редиректов.

Процесс Б: Обработка запроса в реальном времени

1. Получение запроса и данных устройства: Система получает поисковый запрос и Device Identification Data (User-Agent, язык) от пользователя.
2. Генерация первичной выдачи: Поисковая система генерирует стандартный набор результатов поиска (SERP).
3. Анализ редиректов: Для каждого результата в SERP система проверяет Redirect Index, чтобы определить, вызовет ли запрос этого ресурса редирект для данного конкретного устройства.
4. Принятие решения о модификации: Если редирект предсказан (URL A -> URL B), система проверяет исключения (Claims 9, 10, 11):
   • Если данные неполные (например, brand-based) ИЛИ редирект временный: Модификация не производится.
   • Если данные полные и редирект постоянный: Переход к шагу 5.
5. Модификация SERP: Система удаляет ссылку на URL A из результата поиска и заменяет её ссылкой на URL B.
6. Предоставление результатов: Модифицированная SERP предоставляется пользователю.

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

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

• Технические факторы:
  • URL ресурсов (исходные и конечные адреса редиректов). Анализ структуры URL используется для выявления Transient Resources.
  • HTTP-ответы и инструкции редиректов (например, коды 3xx), получаемые при сканировании.
• Пользовательские факторы (Device Identification Data):
  • User-Agent header: используется для определения типа устройства (мобильное/десктопное), бренда, модели, браузера. Это ключевой фактор для определения условных редиректов.
  • Language Setting Data: используется для определения редиректов на основе языка.
  • Cookies: Патент упоминает возможность использования cookies для определения необходимости редиректа (например, для залогиненных пользователей).

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

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

• Идентификация типа устройства: Сравнение User-Agent пользователя со списком известных мобильных или десктопных агентов.
• Проверка наличия редиректа: Поиск соответствия URL и условий устройства в Redirect Index.
• Проверка полноты данных (Completeness Check): Определение того, доступны ли данные о редиректах для всех возможных вариаций (брендов, языков), если редирект является условным (brand-based или language-based). Используется в Claims 9 и 10.
• Идентификация временных ресурсов (Transient Check): Анализ структуры URL или сравнение цепочек редиректов во времени для выявления часто меняющихся конечных адресов. Используется в Claim 11.

1. Google активно переписывает URL в SERP для улучшения UX: Основная цель патента — ускорение загрузки контента для пользователя путем устранения задержек, вызванных серверными редиректами. Google берет на себя задачу определения конечного URL до того, как пользователь кликнет по ссылке.
2. Критическая роль эмуляции при сканировании: Система полагается на обширное сканирование веба с эмуляцией различных устройств (User-Agent, язык). Это подчеркивает способность Google видеть и индексировать контент, который отдается только при определенных условиях (например, Googlebot Smartphone).
3. Поддержка раздельных мобильных URL (m-dot): Этот механизм напрямую поддерживает конфигурацию с раздельными URL. Он позволяет таким сайтам оставаться конкурентоспособными по скорости загрузки из поиска, так как устраняет основной недостаток этой конфигурации — задержку редиректа.
4. Важность консистентности и стабильности редиректов: Система требует четких и постоянных правил редиректов. Если правила часто меняются (transient redirects) или неполны (например, покрывают только часть аудитории по брендам или языкам), Google предпочтет не вмешиваться и оставит исходный URL (Claims 9, 10, 11).
5. Техническая точность реализации: Для корректной работы этой системы сайты должны правильно сигнализировать поисковым системам о наличии разных версий контента для разных устройств (например, через HTTP-заголовок Vary при динамическом показе).

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

• Корректная настройка мобильных версий (Separate URLs/Dynamic Serving): Если используются отдельные URL или динамический показ, необходимо обеспечить консистентные и чистые редиректы на основе User-Agent. Убедитесь, что мобильный пользователь всегда попадает на соответствующую мобильную страницу (page-to-page redirect), а не на главную страницу мобильной версии.
• Использование HTTP-заголовка Vary: Критически важно отдавать HTTP-заголовок Vary: User-Agent, если контент страницы меняется в зависимости от типа устройства (Dynamic Serving) или если настроен условный редирект. Это сигнал для кэширующих систем и Google о том, что нужно хранить разные версии для разных User-Agent.
• Обеспечение доступности для Googlebot Smartphone: Убедитесь, что мобильная версия сайта полностью доступна для сканирования Googlebot Smartphone. Это необходимо для того, чтобы Redirect Reduction Apparatus мог обнаружить редиректы и проиндексировать мобильный контент для построения Redirect Index.
• Использование стабильных URL: Конечные URL мобильных страниц должны быть постоянными. Избегайте включения сессионных идентификаторов или временных параметров, чтобы система не классифицировала их как Transient Resources (Claim 11).
• Тестирование редиректов для разных устройств: Регулярно проверяйте работу редиректов, эмулируя различные User-Agent (Десктоп, Android, iOS) и языковые настройки, чтобы убедиться в их консистентности и отсутствии ошибок.

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

• Неконсистентные или ошибочные редиректы: Перенаправление мобильных пользователей на нерелевантные страницы (например, на главную) или отсутствие редиректа там, где он ожидается.
• Использование временных URL в редиректах: Использование URL, содержащих сессионные идентификаторы или другие часто меняющиеся параметры. Google классифицирует это как transient redirect и не будет сокращать такие редиректы (Claim 11).
• Клоакинг (Cloaking): Попытки показать Googlebot один контент или редирект, а пользователям — другой. Способность Google сканировать с эмуляцией различных устройств делает такие манипуляции рискованными и неэффективными.
• Использование JavaScript-редиректов для смены версии: Патент фокусируется на устранении серверных (HTTP) редиректов. JS-редиректы медленнее, требуют рендеринга и, вероятно, не оптимизируются этим механизмом.
• Сложные цепочки редиректов: Множественные редиректы усложняют задачу по выявлению конечного стабильного URL и увеличивают риск ошибок.

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

Патент подтверждает стратегический фокус Google на скорости и мобильном пользовательском опыте. Он демонстрирует глубокую интеграцию между системами сканирования, индексирования и показа результатов. Для SEO-стратегии это означает, что конфигурации с раздельными мобильными URL остаются жизнеспособным решением, при условии идеальной технической реализации. Google инвестирует ресурсы в то, чтобы компенсировать технические недостатки таких конфигураций (задержки редиректов) ради улучшения UX. Это также подчеркивает важность точного технического SEO и корректной работы серверной инфраструктуры.

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

Сценарий: Оптимизация сайта с раздельной мобильной версией (m-dot)

1. Ситуация: У сайта есть десктопная версия (example.com/page1) и мобильная версия (m.example.com/page1). Настроен серверный редирект для мобильных пользователей.
2. Действия SEO-специалиста:
   1. Проверить, что сервер отдает заголовок Vary: User-Agent (рекомендуется).
   2. Убедиться, что редирект является постоянным (HTTP 301 или 302) и не ведет на временные URL (Transient).
   3. Проверить в Google Search Console, что Googlebot Smartphone успешно сканирует обе версии страниц и обнаруживает редирект.
   4. Убедиться, что настроены аннотации rel="alternate" и rel="canonical" для связи страниц.
3. Ожидаемый результат: Google обнаруживает редирект при сканировании и заносит его в Redirect Index. При поиске с мобильного устройства Google применит механизм из патента и покажет в выдаче ссылку сразу на m.example.com/page1. Это ускорит загрузку для пользователя, так как запрос к example.com/page1 будет пропущен.