Как Google переписывает ссылки в выдаче для обхода условных редиректов и ускорения загрузки

Описание

Какую задачу решает

Патент решает проблему задержек (latency), возникающих между кликом пользователя по результату поиска и загрузкой конечного ресурса, когда на пути присутствуют один или несколько редиректов. Это особенно критично для мобильных устройств, которые часто перенаправляются с десктопных версий страниц на оптимизированные мобильные версии (Mobile Resources). Цель — улучшить пользовательский опыт за счет ускорения доступа к контенту.

Что запатентовано

Запатентована система и метод модификации результатов поиска для сокращения редиректов. Ключевым компонентом является Redirect Reduction Apparatus, который заранее определяет, что запрос к определенному ресурсу (Redirect Resource) вызовет редирект на другой ресурс при выполнении определенных условий (например, запрос с мобильного устройства). Эта информация сохраняется в Redirect Index. Во время поиска система использует эту информацию для замены ссылки в SERP на конечный URL, позволяя пользователю миновать промежуточные редиректы.

Как это работает

Система работает в двух режимах: офлайн (обнаружение) и онлайн (применение).

• Офлайн (Обнаружение): Redirect Reduction Apparatus сканирует ресурсы, эмулируя различные устройства (меняя User-Agent Header и другие параметры), чтобы обнаружить условные редиректы (например, только для мобильных, определенного языка или бренда). Обнаруженные маппинги (URL A -> URL B + условия) сохраняются в Redirect Index.
• Онлайн (Применение): Когда пользователь выполняет поиск, система анализирует его Device Identification Data. Если результат поиска ведет на URL A, и система знает из Redirect Index, что URL A перенаправит данное устройство на URL B, она модифицирует результат поиска, подставляя прямую ссылку на URL B.

Актуальность для SEO

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

Важность для SEO

Патент имеет важное значение для технического SEO (6/10). Он не описывает алгоритмы ранжирования, но напрямую влияет на то, как Google сканирует, индексирует и представляет в выдаче сайты, использующие разные версии URL для разных устройств или регионов (например, m-dot сайты). Понимание этого механизма критически важно для обеспечения корректной индексации мобильных версий и гарантии того, что пользователи быстро получат доступ к контенту.

Детальный разбор

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

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

Данные, получаемые от устройства пользователя (например, User-Agent Header), которые определяют тип устройства (мобильный/десктоп), бренд, модель, браузер и его версию.

Language Setting Data (Данные языковых настроек)

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

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

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

Redirect Conditions (Условия редиректа)

Факторы, на основе которых сервер принимает решение о перенаправлении (тип устройства, наличие cookie, язык, бренд).

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

База данных, хранящая информацию о Redirect Resources, конечных URL и связанных с ними Redirect Conditions.

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

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

Redirect Resource (Перенаправляющий ресурс)

Ресурс (URL A), который при запросе не отдает контент, а перенаправляет запрашивающее устройство на другой ресурс (URL B).

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

Конечный ресурс в цепочке редиректов, который отдает контент и не инициирует дальнейших перенаправлений.

Transient Redirect Resource (Временный перенаправляющий ресурс)

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

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

Примечание: Анализируются Claims из публикации US20190340205A1, которая является продолжением (continuation) ранее выданных патентов. Claim 1 отменен (canceled).

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

1. Система получает данные о релевантных ресурсах для запроса и идентификационные данные, указывающие, что устройство пользователя относится к первому типу (Тип 1).
2. Система определяет (до предоставления результатов поиска), что для конкретного ресурса будет выдан редирект для устройства Типа 1 на другой ресурс, отформатированный для Типа 1.
3. Ключевое условие: этот редирект НЕ выдается для устройств второго типа (Тип 2).
4. В ответ на это определение (и до предоставления результатов), система удаляет из результата поиска ссылку на исходный ресурс и заменяет ее другой ссылкой, которая инициирует запрос сразу к конечному ресурсу.
5. Система предоставляет модифицированный набор результатов поиска устройству Типа 1.

Claim 3 (Зависимый от 2): Уточняет, что определение Типа 1 включает определение того, что устройство является мобильным устройством (mobile device), и что запрос ресурса с мобильного устройства вызовет редирект.

Claim 4 (Зависимый от 3): Детализирует процесс определения редиректа. Он включает получение данных о редиректах (redirect data), определение того, что идентификатор ресурса включен в эти данные, и подтверждение того, что данные указывают на редирект именно для мобильных устройств.

Claims 5 и 6 (Зависимые): Уточняют, что система проверяет, что редирект не происходит для немобильных устройств (non-mobile devices), и если результат предоставляется такому устройству, исходная ссылка сохраняется.

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

Изобретение затрагивает этапы сканирования, индексирования и финального формирования выдачи.

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

INDEXING – Индексирование и извлечение признаков
Результаты сканирования сохраняются в специализированном Redirect Index. Система индексирует не только контент, но и логику перенаправлений, создавая профили редиректов для ресурсов (маппинг URL и условий).

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

RERANKING – Переранжирование / METASEARCH – Метапоиск и Смешивание
Это основной этап применения патента. Система получает результаты этапа RANKING и данные о пользователе (Device Identification Data, Language Setting Data).

1. Проверка индекса: Система проверяет ресурсы из выдачи по Redirect Index.
2. Сопоставление условий: Определяется, является ли ресурс Redirect Resource и соответствуют ли данные пользователя условиям для редиректа.
3. Модификация SERP: Если условия совпадают, система модифицирует ссылку в результате поиска, заменяя исходный URL на конечный URL.

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

• Исходные результаты поиска от Search System.
• Device Identification Data пользователя (User-Agent).
• Language Setting Data пользователя.
• Данные из Redirect Index.

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

• Модифицированные результаты поиска (Modified Search Results) с прямыми ссылками на конечные ресурсы.

На что влияет

• Конкретные типы контента: Влияет на любые ресурсы, использующие условные перенаправления.
• Специфические запросы и ниши: Наибольшее влияние наблюдается в e-commerce (например, редиректы в магазины приложений в зависимости от бренда телефона — brand-based redirect), а также на крупных порталах и новостных сайтах, которые используют отдельные мобильные версии (например, m.site.com).
• Языковые и географические ограничения: Критически важно для международных сайтов, которые используют автоматические редиректы на основе языка браузера пользователя (language-based redirect).

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

• Триггеры активации: Механизм активируется, когда результат поиска ссылается на ресурс, который идентифицирован в Redirect Index как Redirect Resource.
• Условия применения: Применяется только если Device Identification Data текущего пользователя точно соответствуют условиям редиректа, сохраненным в индексе (например, пользователь зашел с мобильного устройства, а редирект настроен только для мобильных).
• Исключения: Патент описывает ситуации, когда механизм может НЕ применяться:
  • Если конечный ресурс определен как Transient Resource (временный или часто меняющийся URL).
  • Если система имеет только частичные данные о редиректах (partial redirect data). Например, если известно, как ресурс обрабатывает Brand A, но неизвестно, как он обрабатывает Brand B (brand-based redirect), или аналогично для языков (language-based redirect). В таких случаях система может предпочесть не модифицировать ссылку, чтобы избежать ошибок.

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

Процесс А: Офлайн-обнаружение редиректов (Построение Redirect Index)

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

Процесс Б: Онлайн-обработка запроса (Модификация SERP)

1. Получение запроса и данных пользователя: Система получает поисковый запрос, Device Identification Data и Language Setting Data пользователя.
2. Генерация первичных результатов: Поисковая система находит релевантные ресурсы (например, URL A).
3. Проверка редиректов: Redirect Reduction Apparatus проверяет URL A в Redirect Index.
4. Сопоставление условий: Система проверяет, соответствуют ли данные текущего пользователя условиям, при которых URL A редиректит на URL B.
5. Принятие решения о модификации: Если условия совпадают и исключения (например, Transient Resource или неполные данные) не срабатывают.
6. Модификация SERP: Система удаляет ссылку на URL A и заменяет ее ссылкой на URL B в результате поиска.
7. Предоставление результатов: Пользователь получает SERP с прямой ссылкой на URL B.

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

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

• Технические факторы: URL ресурсов. Коды ответов сервера (HTTP-статусы редиректов). Структура URL (используется для определения временных, брендовых или языковых ссылок).
• Пользовательские факторы: Device Identification Data (User-Agent Header). Эти данные критичны для определения типа устройства (мобильный/десктоп), бренда (manufacturer), модели, версии ОС и браузера.
• Географические/Языковые факторы: Language setting data (настройки языка пользователя), используемые для обнаружения и применения языковых редиректов.
• Системные данные (Cookies): В патенте упоминается возможность использования Cookie для определения редиректов, связанных с состоянием пользователя (например, вход в аккаунт), если поисковая система и целевой ресурс управляются одной сущностью и имеют доступ к этим Cookie.

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

Патент не вводит новых метрик ранжирования, но использует следующие методы анализа и классификации:

• Redirect Chain Analysis: Анализ последовательности редиректов от исходного запроса до конечного ресурса.
• Условная логика (Conditional Logic): Определение зависимости редиректа от входных данных (IF mobile AND language=DE THEN redirect).
• Анализ URL и Контента: Используется для валидации типа редиректа. Например, если редирект произошел при эмуляции устройства Brand A, и в конечном URL содержится «BrandA_Store», система классифицирует его как brand-based redirect. Аналогично для языков (поиск «en» или «de» в URL).
• Идентификация Transient Resources: Определение временных ссылок путем анализа структуры URL (например, наличие дат, ID сессий) или путем сравнения результатов сканирования во времени (если конечный URL часто меняется).

Выводы

1. Приоритет скорости и UX: Google активно борется с задержками загрузки, вызванными редиректами, путем их «схлопывания» непосредственно в результатах поиска. Это инфраструктурное решение для улучшения пользовательского опыта, особенно на мобильных устройствах.
2. Продвинутое сканирование с эмуляцией: Система использует сложный механизм сканирования, эмулируя различные типы устройств, бренды и языковые настройки. Это позволяет Google строить детальную карту условных редиректов (Redirect Index).
3. Важность корректной мобильной конфигурации: Для сайтов с отдельными мобильными версиями (m-dot) критически важно, чтобы условные редиректы были настроены корректно и последовательно. Система стремится направить мобильного пользователя сразу на Mobile Resource.
4. Учет сложных сценариев и исключений: Механизм учитывает сложные редиректы (на основе бренда, языка, cookie), но имеет защитные механизмы. Если конечный URL является временным (Transient) или если данные о логике редиректов неполные (partial data), модификация ссылки в SERP не произойдет, и будет использован исходный URL.
5. Техническая реализация важнее конфигурации: Независимо от того, используется ли адаптивный дизайн или отдельные URL, техническая реализация должна быть чистой и понятной для поисковых систем. Однако патент показывает сложность поддержки конфигураций с условными редиректами.

Практика

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

• Использовать чистые и последовательные редиректы: Если используется отдельная мобильная версия сайта (m-dot), убедитесь, что условные редиректы (на основе User-Agent) настроены корректно, используют стандартные HTTP 301/302 и легко обнаруживаются краулерами. Это поможет Google корректно заполнить Redirect Index.
• Обеспечивать эквивалентность контента: Контент на конечном URL (например, мобильная страница) должен быть эквивалентен контенту на исходном URL (десктопная страница). Поскольку Google перепишет ссылку в SERP, важно, чтобы пользователь получил релевантный ответ.
• Тестирование с разными User-Agents: Регулярно проверяйте логику работы сайта, используя инструменты эмуляции различных устройств (смартфоны разных брендов, планшеты, десктопы) и Googlebot Smartphone. Убедитесь, что поведение сервера соответствует ожиданиям.
• Корректная настройка международных редиректов: Для международных сайтов убедитесь, что редиректы на основе языка браузера работают корректно, но предпочтительно полагаться на hreflang, а не на автоматические перенаправления, так как обработка language-based redirects может быть отключена при неполных данных.
• Предпочтение адаптивному дизайну: По возможности используйте адаптивный дизайн вместо отдельных мобильных сайтов. Это устраняет необходимость в условных редиректах и упрощает индексацию, делая описанный в патенте механизм неактуальным для вашего сайта.

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

• Сложные цепочки редиректов: Использование многошаговых или непоследовательных цепочек редиректов усложняет работу Redirect Reduction Apparatus и может привести к ошибкам в Redirect Index.
• Использование временных URL для основного контента: Настройка редиректов на URL с идентификаторами сессий или временными метками приведет к тому, что Google классифицирует их как Transient Resources и не будет использовать их для модификации SERP.
• Непоследовательные редиректы (Inconsistent Redirects): Если логика редиректов часто меняется или работает по-разному для одинаковых User-Agents, Google не сможет надежно определить конечный URL.
• Блокировка краулеров или ресурсов: Блокировка доступа мобильному Googlebot к мобильной версии сайта или блокировка CSS/JS не позволит системе корректно обнаружить редиректы и конечный мобильный ресурс.
• Клоакинг (Cloaking): Показ разных редиректов для пользователей и Googlebot при одинаковом User-Agent. Это нарушает правила и противоречит логике работы системы эмуляции.

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

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

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

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

1. Ситуация: Сайт использует site.com/page1 для десктопов и m.site.com/page1 для мобильных устройств. Настроен условный редирект.
2. Действие SEO-специалиста: Проверить с помощью мобильного User-Agent, что site.com/page1 корректно редиректит на m.site.com/page1. Убедиться, что настроены теги canonical/alternate.
3. Работа системы (по патенту): Googlebot (мобильный) обнаруживает редирект и заносит его в Redirect Index.
4. Результат: Когда пользователь ищет с телефона, Google модифицирует SERP и показывает ссылку сразу на m.site.com/page1, минуя редирект через site.com и ускоряя загрузку. (Примечание: Визуально в SERP может по-прежнему отображаться site.com/page1, но ссылка будет вести на m.site.com/page1).

Сценарий 2: Обработка редиректов в App Store (Исключение)

1. Ситуация: Компания рекламирует приложение на странице site.com/app. Эта страница определяет бренд телефона и редиректит пользователя в соответствующий магазин приложений (App Store A или App Store B).
2. Работа системы (по патенту): Google сканирует site.com/app, эмулируя разные бренды. Он обнаруживает brand-based redirects.
3. Результат (Исключение): Если Google определил логику только для Brand A, но не смог определить ее для Brand B (неполные данные), система НЕ будет модифицировать ссылку в SERP. Она оставит ссылку на site.com/app, чтобы избежать отправки пользователя Brand B в магазин Brand A.

Вопросы и ответы