Как Google предотвращает дублирование контента в потоковых результатах поиска (Streaming Search)

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

Client-Side Streaming Code (Клиентский код для стриминга)

Исполняемый код (например, JavaScript, использующий AJAX), отправляемый сервером клиенту. Он инструктирует браузер периодически запрашивать обновления у сервера с помощью Polling URL без перезагрузки всей страницы.

Content ID (Идентификатор контента)

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

De-duplication (Дедупликация)

Процесс сравнения новых результатов с уже отправленными (на основе State String) и удаления дубликатов по Doc ID или Content ID.

Doc ID (Идентификатор документа)

Уникальный идентификатор (например, 64-битный хеш), сгенерированный на основе URL документа. Используется для обнаружения дубликатов страниц с идентичными адресами.

Polling URL (URL для опроса)

Специально сформированный URL, который клиент использует для периодического запроса новых потоковых результатов. Он содержит исходные поисковые термины и State String.

State String (Строка состояния)

Закодированная строка, содержащая Doc IDs и Content IDs всех потоковых результатов, ранее отправленных клиенту в текущей сессии. Позволяет серверу понять, какой контент клиент уже получил.

Streaming Results / Recent Results (Потоковые / Недавние результаты)

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

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

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

1. Система получает первый запрос.
2. Получает первый список результатов.
3. Генерирует Polling URL, включающий уникальные идентификаторы для каждого результата из первого списка, причем каждый идентификатор представляет контент результата (Content ID).
4. Отправляет первый ответ клиенту, включающий результаты и Polling URL.
5. [Позже, используя Polling URL] Система идентифицирует поисковые термины и уникальные идентификаторы из Polling URL.
6. Получает второй список результатов.
7. Идентифицирует уникальные идентификаторы (представляющие контент) результатов второго списка, которые совпадают с идентификаторами из Polling URL (т.е. дубликаты).
8. Обновляет второй список, удаляя результаты с совпадающими идентификаторами.
9. Модифицирует Polling URL, добавляя идентификаторы оставшихся (новых) результатов.
10. Отправляет второй ответ клиенту с обновленным списком и модифицированным Polling URL.

Ядром изобретения является использование Polling URL для передачи состояния (полученного контента) от клиента обратно к серверу, что позволяет серверу эффективно выполнять дедупликацию без хранения состояния сессии у себя (stateless operation).

Claim 4 (Зависимый): Уточняет, что генерация Polling URL также включает кодирование информации, идентифицирующей URL, связанные с первым списком результатов (т.е. Doc IDs). Это обеспечивает дедупликацию не только по контенту, но и по адресу.

Claim 7 (Зависимый от 6): Уточняет, что кодирование информации о контенте (генерация Content ID) включает вычисление хеша (hash) части контента каждого документа.

Claim 9 (Зависимый от 1): Уточняет, что первый ответ также содержит исполняемый код (Client-Side Streaming Code), который инструктирует клиента отправлять периодические запросы обновлений, используя Polling URL.

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

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

INDEXING – Индексирование и извлечение признаков
Чтобы механизм потокового поиска работал, новый контент должен быть быстро проиндексирован. На этапе индексирования система должна присваивать временные метки (timestamps) и генерировать Doc ID (хеш URL) и Content ID (хеш контента).

RANKING – Ранжирование
Система использует специфический тип ранжирования для генерации Recent Results (Потоковых результатов). Это ранжирование фокусируется на свежести (recency) и релевантности запросу, отбирая контент, добавленный в индекс недавно (например, за последние 60 секунд).

RERANKING / METASEARCH – Переранжирование / Доставка
Основное применение патента. Механизм работает во время активной сессии пользователя на странице SERP. Он управляет доставкой обновлений внутри специального блока выдачи (Streaming Results block). Система получает свежих кандидатов и фильтрует их (De-Duplication), удаляя те результаты, которые уже были отправлены клиенту, основываясь на State String.

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

• Polling URL, полученный от клиента (содержит Search Terms и текущий State String).
• Новые результаты из поискового индекса, соответствующие Search Terms (с их Doc IDs и Content IDs).

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

• Список новых (недубликативных) потоковых результатов.
• Обновленный Polling URL (с модифицированным State String).

На что влияет

• Конкретные типы контента: Влияет на контент, требующий отображения в реальном времени. Патент упоминает новостные статьи, посты в блогах, а также контент из социальных сетей (упоминаются Google+, Facebook, Twitter).
• Специфические запросы: Запросы, связанные с текущими событиями, трендами, новостями (QDF - Query Deserves Freshness).
• Форматы контента: Блоки выдачи, которые обновляются автоматически без перезагрузки страницы (Streaming Search Results).

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

Алгоритм применяется при следующих условиях:

• Поисковая выдача (SERP) содержит блок потоковых результатов (Streaming Results).
• Клиент получил и выполняет Client-Side Streaming Code.
• Код инициирует периодический опрос (polling) сервера для получения обновлений по мере появления нового релевантного контента в индексе.

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

Этап 1: Инициализация сессии

1. Запрос: Клиент отправляет поисковый запрос.
2. Получение результатов: Сервер получает стандартные релевантные результаты и новейшие (Streaming) результаты из индекса.
3. Генерация идентификаторов: Для новейших результатов сервер генерирует Doc IDs (на основе URL) и Content IDs (на основе хеша контента).
4. Создание состояния: Сервер кодирует эти идентификаторы в State String.
5. Создание Polling URL: Сервер формирует Polling URL, включающий поисковые термины и State String.
6. Первая доставка: Сервер отправляет клиенту результаты, Polling URL и Client-Side Streaming Code.
7. Отображение: Клиент отображает результаты и запускает код стриминга.

Этап 2: Обновление потока (Цикл)

1. Ожидание: Клиентский код ждет заданный интервал (например, 30-60 секунд).
2. Запрос обновлений: Код отправляет асинхронный запрос (AJAX) на сервер, используя Polling URL.
3. Извлечение состояния: Сервер получает запрос и извлекает поисковые термины и State String. State String декодируется обратно в список идентификаторов.
4. Получение новых данных: Сервер запрашивает у индекса новые результаты, появившиеся с момента последнего запроса.
5. Дедупликация: Сервер генерирует Doc IDs и Content IDs для новых результатов и сравнивает их с идентификаторами из State String. Если найден дубликат (совпадение по Doc ID ИЛИ Content ID), результат отбрасывается.
6. Ослабление дедупликации (Опционально): Если новых результатов недостаточно для поддержания потока, система может ослабить дедупликацию и разрешить отправку некоторых дубликатов.
7. Обновление состояния: Сервер добавляет идентификаторы оставшихся (недубликативных) результатов в State String. При этом старые идентификаторы могут удаляться для контроля размера строки.
8. Генерация нового Polling URL: Сервер создает новый Polling URL с обновленным State String.
9. Доставка обновлений: Сервер отправляет новые результаты и новый Polling URL клиенту.
10. Обновление отображения: Клиент добавляет новые результаты в блок стриминга и возвращается к шагу 1 (Ожидание).

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

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

Система использует следующие типы данных для обеспечения своей работы:

• Технические факторы: URL документа. Критически важен для генерации Doc ID.
• Контентные факторы: Содержимое документа (текст). Используется для генерации Content ID.
• Временные факторы: Метки времени (timestamps) индексации, создания или модификации документа. Используются для определения, является ли результат «недавним» (Recent) и подлежит ли он включению в поток.
• Пользовательские факторы: Исходный запрос пользователя (Search Terms), передаваемый в Polling URL.

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

• Doc ID: Уникальный идентификатор URL. Обычно рассчитывается как 64-битный хеш URL. Используется для предотвращения отправки одной и той же страницы дважды.
• Content ID: Уникальный идентификатор контента. Рассчитывается как 64-битный хеш содержимого документа или его значимой части. Используется для предотвращения отправки дублирующегося контента, размещенного на разных URL.
• Ограничения размера State String: Патент описывает методы контроля размера State String, чтобы он не превышал лимиты URL:
  • Частичные хеши (Partial Hashes): Вместо полных 64-битных идентификаторов могут использоваться их части. Патент предполагает, что 21-битный поднабор может быть оптимальным компромиссом между размером строки и риском ложных срабатываний (коллизий).
  • Временное ограничение (Time-based dropping): Хранение идентификаторов только за определенный период. Патент предлагает примеры: хранить Doc IDs за последнюю 1 минуту и Content IDs за последние 5 минут, исходя из предполагаемого объема внимания пользователя.
  • Количественное ограничение: Хранение фиксированного числа идентификаторов (например, 10 Doc IDs и 50 Content IDs).

Патент описывает внутренние инфраструктурные процессы Google без прямых рекомендаций для SEO. Он дает понимание технических механизмов, обеспечивающих работу потокового поиска.

1. Инфраструктура и Масштабируемость: Основная цель патента — повышение эффективности и масштабируемости системы потокового поиска. Перенос управления состоянием (State String) на сторону клиента позволяет серверу не хранить данные сессий (stateless operation), что критично при большом количестве пользователей.
2. Два уровня дедупликации: Система использует два типа идентификаторов: Doc ID (по URL) и Content ID (по контенту). Это подтверждает способность Google эффективно распознавать и отфильтровывать не только полные дубликаты страниц, но и синдицированный или скопированный контент в реальном времени.
3. Фокус на свежести: Механизм предназначен для доставки контента, который был недавно проиндексирован. Это подчеркивает важность скорости индексации для попадания в блоки реального времени (QDF-запросы).
4. Оптимизация передачи данных: Использование частичных хешей (например, 21 бит) и временных ограничений (1-5 минут) для контроля размера State String показывает, как Google балансирует между точностью дедупликации и ограничениями веб-инфраструктуры (длина URL).

Патент является инфраструктурным и не дает прямых практических выводов для SEO-ранжирования. Однако он предоставляет важный контекст для работы со свежим контентом и понимания обработки дубликатов.

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

• Обеспечение максимальной скорости индексации: Для попадания в потоковые результаты (Streaming Search) контент должен быть проиндексирован мгновенно. Хотя патент не описывает, как этого достичь, он подчеркивает важность этого аспекта. Используйте чистую техническую оптимизацию, XML Sitemaps (включая News Sitemaps) и Indexing API.
• Фокус на создании уникального контента: Использование Content ID для дедупликации означает, что Google активно фильтрует неуникальный контент в потоковой выдаче. Если вы публикуете новость, добавление уникальной ценности (аналитика, комментарии, дополнительные факты) критично, чтобы ваш контент не был сочтен дубликатом синдицированного источника и был показан в потоке.

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

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

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

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

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

Сценарий: Дедупликация синдицированной новости

1. Событие: Агентство Reuters публикует срочную новость. Google индексирует её.
2. Показ 1: Пользователь видит статью Reuters в потоке результатов. Сервер генерирует Content ID (например, Hash_R) и отправляет его пользователю в State String.
3. Публикация копии: Через 2 минуты сайт CNN публикует ту же самую статью Reuters (идентичный текст) под другим URL. Google индексирует её.
4. Запрос обновления: Браузер пользователя запрашивает обновления, отправляя State String, содержащий Hash_R.
5. Дедупликация: Сервер видит статью CNN как кандидата. Он вычисляет её Content ID и получает Hash_R. Сервер сравнивает его с идентификаторами из State String, находит совпадение и исключает статью CNN из ответа.
6. Результат: Пользователь не видит ту же самую новость повторно, даже если она пришла из другого источника (CNN).