Как Google объединяет разные URL в один результат, если они ведут на одну и ту же страницу (например, при мобильных редиректах)

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

Deep Linking (Глубинные ссылки)

Практика создания гиперссылок, которые указывают на конкретную внутреннюю страницу сайта, а не на главную. Некоторые сайты пытаются предотвратить это, перенаправляя внешний трафик на главную страницу.

Device-Specific Versions (Версии, специфичные для устройств)

Различные версии контента, оптимизированные для разных устройств (например, Full Version для десктопа и Mobile Version для смартфона).

Duplicate Search Results (Дублирующиеся результаты поиска)

В контексте патента — функциональные дубликаты: результаты, которые ссылаются на разные URL, но в конечном итоге ведут пользователя на одну и ту же страницу (same destination resource) или доставляют идентичный контент.

Particular Characteristic (Определенная характеристика)

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

Replacement Search Result (Замещающий результат поиска)

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

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

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

1. Система идентифицирует в наборе результатов поиска два несовпадающих результата: Первый (с URL 1, Ресурс 1) и Второй (с URL 2, Ресурс 2).
2. Определяется, что код, включенный в Ресурс 1, и код, включенный в Ресурс 2, указывают на редирект на один и тот же третий URL (URL 3), ведущий на общий целевой ресурс (Ресурс 3).
3. Подтверждается, что оба ресурса автоматически перенаправляют пользовательские устройства на этот общий целевой ресурс с помощью URL 3.
4. В ответ на это генерируется replacement search result, отличный от исходных, который включает URL 3.
5. Предоставляется страница результатов поиска (SERP), которая содержит replacement search result и опускает по крайней мере один из двух исходных дублирующихся результатов.

Claim 2 (Зависимый от 1): Добавляет контекстную зависимость.

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

Claim 3 (Зависимый от 2): Конкретизирует характеристику и сценарий.

Характеристика идентифицирует устройство как мобильное (через cookie или другой код). Исходные ресурсы отформатированы для немобильных устройств, а целевой ресурс — для мобильных. Это явное указание на обработку мобильных редиректов.

Claim 4, 5, 6 (Зависимые): Описывают варианты представления замещающего результата.

Replacement search result может быть представлен как единый результат, заменяющий оба исходных (Claim 4), или как кластер связанных результатов (cluster of related search results) (Claim 5). В кластере могут сохраняться гиперссылки на исходные ресурсы (Claim 6).

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

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

CRAWLING – Сканирование и Сбор данных
Система должна эмулировать разные устройства. Веб-краулер отправляет запросы с различными заголовками (например, User-Agent мобильного устройства), чтобы зафиксировать поведение сервера (редиректы или динамический контент).

INDEXING – Индексирование и извлечение признаков
Система сохраняет информацию о поведении ресурсов для разных устройств. Патент предполагает хранение данных о редиректах или уникальных идентификаторов контента, специфичного для устройства. Это может быть хэш URL редиректа или контрольная сумма (checksum) HTML-контента, фактически предоставленного в ответ на запрос. В индексе могут храниться данные дедупликации, привязанные к конкретным типам устройств.

RERANKING – Переранжирование / METASEARCH – Метапоиск и Смешивание
Основное применение патента происходит после получения первоначального списка ранжированных результатов (RANKING).

1. Идентификация контекста: Система определяет характеристики устройства пользователя.
2. Обнаружение дубликатов: Используя данные из индекса, система проверяет результаты в списке на предмет функциональной дубликации для данного контекста.
3. Консолидация: Если дубликаты найдены, De-duplication Apparatus генерирует replacement search result, а исходные результаты удаляются или кластеризуются.

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

• Исходный набор ранжированных результатов поиска.
• Характеристики пользовательского устройства (Particular Characteristic).
• Индексные данные о поведении ресурсов (редиректы, хэши контента) для разных типов устройств.

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

• Модифицированная SERP с удаленными функциональными дубликатами и вставленным replacement search result.

На что влияет

• Мобильная выдача (Mobile SEO): Наибольшее влияние, особенно для сайтов, использующих отдельные мобильные URL (m-dot) или динамическое предоставление контента (Dynamic Serving).
• Технические конфигурации: Влияет на сайты с ошибочными редиректами (например, когда все глубокие страницы перенаправляют на главную страницу мобильной версии — Faulty Redirects).
• Сайты с обязательной аутентификацией (Login Walls): Если несколько страниц перенаправляют неавторизованных пользователей на одну и ту же страницу входа, система может их дедуплицировать.
• Сайты, блокирующие Deep Linking: Сайты, которые перенаправляют весь внешний трафик с глубоких страниц на главную страницу.

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

• Триггер активации: Когда в результатах поиска присутствуют два или более результата, ссылающиеся на разные URL.
• Условие срабатывания: Когда система определяет (на основе кода страниц или индексных данных), что эти разные URL будут доставлять идентичный контент или перенаправлять на один и тот же целевой URL.
• Контекстная зависимость: Активация часто зависит от того, обладает ли пользовательское устройство определенной характеристикой (например, является мобильным), которая вызывает такое поведение сервера.

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

Процесс А: Подготовка данных (Офлайн - Crawling/Indexing)

1. Сканирование с эмуляцией устройств: Краулер отправляет запросы к URL, эмулируя различные устройства (меняя User-Agent).
2. Фиксация поведения сервера: Регистрируется ответ сервера для каждого типа устройства (например, наличие и цель редиректа).
3. Анализ контента: Если контент динамический, система анализирует фактически полученный HTML.
4. Сохранение данных дедупликации: В индексе для каждого URL сохраняются данные о его поведении. Это могут быть целевые URL редиректов или контрольные суммы (хэши) полученного контента для каждого типа устройства.

Процесс Б: Обработка запроса (Реальное время - Reranking)

1. Получение запроса и контекста: Система получает запрос и определяет характеристики устройства пользователя.
2. Генерация первичных результатов: Формируется стандартный набор результатов поиска.
3. Идентификация функциональных дубликатов: Система анализирует результаты и, используя индексные данные для данного типа устройства, определяет, какие из них вернут одинаковый контент (сравнение целевых URL редиректов или хэшей контента).
4. Генерация замещающего результата: Если дубликаты найдены, генерируется replacement search result. Он может быть единичным результатом, ссылающимся на целевой URL, или кластером.
5. Определение ранга: Система определяет позицию для нового результата (например, по наивысшему рангу из замененных результатов).
6. Модификация SERP: Система представляет модифицированную страницу поиска, включая замещающий результат вместо идентифицированных дубликатов.

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

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

• Технические факторы:
  • URL ресурсов: Исходные и целевые URL редиректов.
  • Код ресурсов: Инструкции редиректа, заложенные в коде страницы (как указано в Claim 1).
  • HTTP-заголовки: User-Agent, используемый краулерами для эмуляции и User-Agent реального пользователя.
• Пользовательские факторы (Контекст):
  • Характеристики устройства (Particular Characteristic): Тип устройства (мобильный/десктоп).
  • Статус аутентификации: Наличие или отсутствие cookie, влияющее на редиректы (например, на страницу входа).
• Контентные факторы:
  • HTML-контент: Фактический контент, который сервер предоставляет в ответ на запрос от конкретного устройства (используется для анализа идентичности).

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

Патент основан на определении идентичности доставленного контента.

• Идентичность целевого URL (Redirect Destination): Сравнение URL, на который происходит редирект с разных исходных страниц. Если целевой URL одинаков для двух исходных URL, они считаются дубликатами. Это основной метод, описанный в Claims.
• Идентичность контента (Хэши/Контрольные суммы): В описании патента упоминается возможность использования контрольной суммы (checksum) HTML-контента. Если хэши контента, полученного с двух разных URL для определенного типа устройства, совпадают, они считаются дубликатами, даже если явного редиректа нет (например, при динамическом показе).

1. Google активно борется с функциональными дубликатами: Система стремится к максимальному разнообразию SERP. Если разные URL ведут пользователя в одно и то же место в данном контексте, они будут консолидированы.
2. Анализ конечного пользовательского опыта: При оценке страниц Google учитывает то, что фактически увидит пользователь на своем устройстве после всех редиректов, а не только исходный контент в индексе.
3. Контекстная дедупликация: Дедупликация зависит от характеристик устройства пользователя. Результаты могут быть объединены в мобильной выдаче, но оставаться раздельными в десктопной.
4. Подтверждение мульти-агентного сканирования: Для работы системы Google должен сканировать веб с использованием разных User-Agent (например, Googlebot Smartphone), чтобы заранее понять поведение серверов.
5. Критичность корректных редиректов: Патент явно нацелен на наказание за некорректные технические решения, такие как ошибочные мобильные редиректы или блокировка deep linking. Консолидация уменьшает видимость сайта в SERP.

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

• Настройка корректных 1-к-1 редиректов (для отдельных мобильных URL): Если используются отдельные URL (m-dot), убедитесь, что каждая десктопная страница (site.com/pageA) перенаправляет мобильного пользователя строго на эквивалентную мобильную страницу (m.site.com/pageA), а не на главную (m.site.com). Это предотвратит консолидацию ваших страниц.
• Использование адаптивного дизайна (Responsive Design): Это предпочтительный метод, так как он использует один URL и один набор контента для всех устройств, что позволяет избежать проблем, описанных в патенте.
• Корректная настройка динамического показа (Dynamic Serving): Если контент меняется в зависимости от устройства на одном URL, обязательно используйте HTTP-заголовок Vary: User-Agent. Это помогает Google корректно индексировать разные версии контента.
• Обеспечение доступности контента (Deep Linking): Убедитесь, что пользователи и поисковые боты могут напрямую попадать на внутренние страницы сайта из поиска. Избегайте принудительных редиректов на главную страницу.
• Аудит поведения сайта для разных User-Agent: Регулярно проверяйте (используя эмуляцию в браузере или инструменты вроде Google Search Console), как ваш сайт отвечает на запросы от Googlebot Desktop и Googlebot Smartphone. Убедитесь в корректности редиректов.

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

• Ошибочные мобильные редиректы (Faulty Redirects): Перенаправление пользователей с глубоких страниц десктопной версии на главную страницу мобильной версии. Это гарантированно активирует механизм дедупликации и приведет к потере видимости внутренних страниц.
• Блокировка Deep Linking: Настройка редиректов, которые перехватывают внешний трафик на внутренние страницы и отправляют его на главную. Google консолидирует такие результаты.
• Некорректные Login Walls: Если несколько индексируемых страниц при прямом заходе пользователя редиректят на одну и ту же страницу логина, это может привести к их дедупликации в выдаче.

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

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

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

Сценарий: Некорректная мобильная конфигурация кулинарного сайта

1. Ситуация: У сайта example.net есть три релевантные страницы рецептов:
   • example.net/chickensoup (Рецепт 1)
   • example.net/friedchicken (Рецепт 2)
   • example.net/chickenmonterey (Рецепт 3)
2. Ошибка конфигурации: Сайт настроен так, что при заходе с мобильного устройства на любую из этих страниц происходит редирект на главную страницу мобильной версии m.example.net.
3. Запрос пользователя: Пользователь ищет с мобильного телефона "рецепты курицы".
4. Действие Google (согласно патенту):
   • Google определяет, что пользователь использует мобильное устройство (Particular Characteristic).
   • Система проверяет индекс и видит, что все три URL для этого устройства ведут на один и тот же целевой ресурс (m.example.net).
   • Google идентифицирует их как функциональные дубликаты и генерирует Replacement Search Result.
5. Результат в SERP: Вместо трех отдельных результатов для разных рецептов Google покажет один результат, ссылающийся на m.example.net. Видимость по конкретным рецептам потеряна.