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

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

Address (Адрес)

Идентификатор, указывающий сетевое расположение документа (URL или URI). Включает схему, домен и параметры.

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

Параметр или часть пути, извлеченная из Address. Может включать SKU, ID продукта, ID сессии, параметры отслеживания и т.д.

First Search Index (Первый поисковый индекс)

Индекс, наполняемый преимущественно краулером (например, основной Веб-индекс).

Second Search Index (Второй поисковый индекс)

Индекс, наполняемый преимущественно на основе данных, отправленных пользователями/владельцами сайтов (submissions), например, индекс товаров Google Shopping (через фиды Merchant Center) или Google News.

Mapping (Сопоставление)

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

Key (Ключ)

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

Rule (Правило)

Автоматически сгенерированное правило для конкретного домена и структуры (формы) URL, которое определяет, какой параметр является уникальным идентификатором. Используется для оптимизации процесса.

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

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

1. Система идентифицирует первый адрес (URL1) в первом индексе (Index 1) и второй адрес (URL2) во втором индексе (Index 2). Оба связаны с одним документом.
2. Определяются наборы идентификаторов для URL1 и URL2.
3. Создается сопоставление (Mapping) между URL1 и URL2, если первый идентификатор равен второму идентификатору.
4. Система верифицирует корректность сопоставления на основе сравнения первой информации о документе (из Index 1) и второй информации (из Index 2).
5. Сопоставление передается на серверы индексов.

Claim 3 (Зависимый от 1): Детализирует критически важный процесс фильтрации идентификаторов.

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

Claim 7 (Зависимый от 1): Уточняет процесс верификации.

Верификация подтверждается, если части информации совпадают. Указанные части включают: заголовок (Title) документа, язык документа или контент документа.

Claim 8 (Зависимый от 1): Описывает механизм обмена данными (обогащение).

Система извлекает данные из записи для второго адреса (Index 2) и передает эти данные вместе с сопоставлением в первый индекс (Index 1).

Claim 10 (Независимый пункт): Описывает реализацию с фокусом на Домен, Ключ и верификацию контента.

1. Определяется домен и идентификатор в URL1.
2. Определяется ключ (Key), связанный с идентификатором.
3. Создается сопоставление URL1 к URL2, который связан с тем же доменом и тем же ключом.
4. Определяется, что контент, связанный с URL1, совпадает с контентом, связанным с URL2.
5. Сопоставление верифицируется на основе совпадения контента.

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

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

INDEXING – Индексирование и извлечение признаков (Постобработка)
Основная работа алгоритма происходит здесь (или в виде отдельного офлайн-процесса). Processing Server анализирует существующие индексы (First и Second Search Index):

1. Извлекает и фильтрует Identifiers из URL.
2. Находит совпадения уникальных идентификаторов (Keys).
3. Верифицирует совпадения путем сравнения контента/метаданных.
4. Генерирует базу данных Mapping и обеспечивает обмен данными.
5. Обучается домен-специфичным правилам (Rules) для оптимизации.

METASEARCH – Метапоиск и Смешивание
На этапе формирования выдачи система использует созданный Mapping для обогащения результатов. Когда результат извлекается из одного индекса, система проверяет наличие сопоставления и может подтянуть дополнительные данные (например, цену, наличие) из связанного индекса для отображения в сниппете (Rich Results).

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

• URL из первого индекса и связанные данные (контент, метаданные).
• URL из второго индекса и связанные данные (например, данные из фидов, структурированные атрибуты).

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

• База данных Mapping, связывающая эквивалентные URL.
• Передача данных между индексами (например, передача цены из индекса товаров в веб-индекс).

На что влияет

• Конкретные ниши (E-commerce): Наибольшее влияние на интернет-магазины, где один и тот же товар часто имеет чистый URL (найденный краулером) и URL с параметрами (отправленный через Google Merchant Center).
• Конкретные типы контента (Товары, Новости): Влияет на контент, который индексируется как в основном поиске, так и в специализированных вертикалях (например, Google News).
• Техническое SEO (Структура URL): Влияет на то, как Google интерпретирует параметры URL и идентифицирует уникальный контент.

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

• Условия применения: Алгоритм применяется при обработке индексов, которые содержат URL с различной структурой, но потенциально ведущие на один и тот же контент.
• Триггеры активации: Наличие извлекаемых идентификаторов (параметров или частей пути) в структуре URL.
• Частота применения: Процесс требует значительных ресурсов и, вероятно, выполняется периодически в офлайн-режиме (batch processing) для обновления базы сопоставлений, а не в реальном времени при запросе.

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

Процесс сопоставления адресов из разных индексов (Индекс А и Индекс Б):

1. Определение наборов идентификаторов: Система извлекает адреса из Индекса А и Индекса Б. Для каждого адреса определяются идентификаторы путем анализа параметров URL (например, все, что находится между символами '/', '?', '=', '#').
2. Фильтрация неуникальных идентификаторов (Ключевой этап): Система анализирует идентификаторы внутри каждого индекса. Если идентификатор связан с несколькими разными адресами в одном индексе (например, параметр "category=shoes" или session ID), он исключается из набора. Цель — оставить только уникальные идентификаторы (например, SKU).
3. Сопоставление идентификаторов с адресами: Оставшиеся уникальные идентификаторы становятся ключами (Keys) и связываются с соответствующими адресами.
4. Сопоставление адресов разных индексов: Система ищет совпадения Keys между Индексом А и Индексом Б. Если адрес из Индекса А и адрес из Индекса Б имеют общий домен и связаны с одним и тем же Key, создается предварительное сопоставление (mapping).
5. Верификация сопоставления: Система проверяет корректность. Для этого извлекается информация о документах (контент, метаданные, Title, длина документа) по обоим адресам. Если информация совпадает, mapping подтверждается.
6. Передача сопоставления и данных: Подтвержденные сопоставления передаются на серверы индексов. Вместе с этим происходит обмен данными (например, цена из Индекса Б передается в Индекс А).

Оптимизация (Генерация Правил):

После обработки множества адресов с одного домена система может определить, что только определенный параметр (например, 'sku') является надежным уникальным идентификатором. Система создает Правило (Rule) для этого домена. При последующей обработке адресов с этого домена система сразу применяет правило для быстрого извлечения Key, минуя этапы 2-3.

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

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

• Технические факторы (Критично): Структура URL, доменное имя, параметры URL (CGI scripts, query strings, fragment identifiers). Эти данные являются основой для извлечения Identifiers и Keys.
• Контентные факторы (Для верификации): Содержимое документа (Content), Заголовок (Title), метаданные (например, длина документа, язык). Используются для подтверждения, что разные URL ведут на одну и ту же страницу.
• Данные из специализированных индексов: Структурированные данные, отправленные пользователями (например, через фиды), такие как цена, бренд, наличие товара. Используются для обогащения других индексов после создания сопоставления.

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

• Уникальность идентификатора (Identifier Uniqueness): Определяется путем подсчета количества адресов, с которыми связан идентификатор в пределах одного индекса. Если количество > 1 (или превышает определенный низкий порог), идентификатор считается неуникальным и фильтруется.
• Совпадение ключей (Key Matching): Прямое сравнение уникальных идентификаторов (Keys), извлеченных из URL разных индексов.
• Метрики верификации (Verification Metrics): Сравнение контента и метаданных. Патент упоминает совпадение заголовков (Title matching), совпадение длины документа или совпадение контента.
• Правила домена (Domain Rules): Предварительно вычисленные шаблоны, основанные на анализе структуры URL конкретного домена, которые определяют, какой параметр является надежным Key.

1. Консолидация данных между индексами: Патент описывает инфраструктурный механизм, позволяющий Google решать проблему дублирования контента, существующего под разными URL в разных индексах (Web, Shopping, News). Это форма межиндексной каноникализации.
2. Идентификация через уникальные параметры: Ключевым механизмом является способность системы автоматически определять, какие части URL являются уникальными идентификаторами (например, SKU), а какие — шумом (ID сессии, UTM-метки). Это достигается путем фильтрации параметров, которые встречаются у нескольких страниц в одном индексе.
3. Цель – Обогащение данных (Rich Results): Основная цель сопоставления — обмен данными между индексами. Это позволяет Google показывать в основном веб-поиске структурированные данные (например, цену и наличие), которые были получены только через специализированные каналы (например, фид Google Merchant Center).
4. Важность верификации контента: Система не полагается исключительно на совпадение идентификаторов в URL. Обязательным этапом является верификация путем сравнения контента, заголовков (Title) или метаданных, что защищает от ложных срабатываний.
5. Оптимизация через правила домена: Система способна обучаться и создавать правила для конкретных доменов, определяя надежные идентификаторы для данной структуры URL, что ускоряет обработку.

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

• Использование уникальных идентификаторов в URL (Критично для E-commerce): Убедитесь, что все страницы товаров содержат уникальный идентификатор (например, SKU, MPN или внутренний ID продукта) в виде параметра запроса или части пути URL. Это значительно облегчает Google процесс извлечения Keys и сопоставления страницы между веб-индексом и индексом товаров.
• Консистентность идентификаторов в фидах и на сайте: Уникальный идентификатор, используемый в URL на сайте, должен соответствовать идентификаторам, передаваемым в фидах (например, Google Merchant Center). Это обеспечивает корректный mapping и передачу данных о цене/наличии.
• Обеспечение идентичности контента на эквивалентных URL: Убедитесь, что контент, и особенно Заголовки (Title), на разных версиях URL (например, чистый URL и URL, указанный в фиде) идентичны. Это необходимо для успешного прохождения этапа верификации сопоставления.
• Использование чистой и логичной структуры URL: Хотя система умеет разбирать сложные URL, предпочтение следует отдавать структурам, где уникальный идентификатор легко извлекается и стабилен во времени. Это помогает системе быстрее сформировать Rules для вашего домена.

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

• Отсутствие уникальных идентификаторов в URL: Использование только нечисловых, неуникальных параметров (например, только название категории и название товара) усложняет для Google процесс идентификации и сопоставления страниц.
• Использование нестабильных идентификаторов: Частое изменение уникальных идентификаторов продуктов в URL и фидах приведет к потере консолидированных сигналов и временным проблемам с отображением Rich Results.
• Различия в Title или контенте на эквивалентных страницах: Если Title или основной контент страницы отличается в зависимости от параметров URL (например, в зависимости от источника трафика), система не пройдет этап верификации и не сможет связать URL.
• Блокировка доступа к контенту для верификации: Если одна из версий URL (например, та, что указана в фиде) недоступна для сканирования или отдает неполный контент, верификация не будет пройдена.

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

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

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

Сценарий: Обогащение результатов поиска для интернет-магазина

1. Сбор данных (Индекс А - Веб): Googlebot сканирует сайт и находит URL товара: https://www.site.com/products/tovar-1234. В веб-индексе нет точных данных о цене.
2. Сбор данных (Индекс Б - Товары): Владелец сайта загружает фид в Google Merchant Center с URL: https://www.site.com/products/get.php?sku=1234&utm_source=gmc. В индексе товаров есть цена (99$) и наличие (В наличии).
3. Извлечение и Фильтрация: Система извлекает идентификаторы. Она определяет, что utm_source=gmc используется на многих страницах и фильтрует его. В обоих случаях остается уникальный идентификатор (Key) 1234.
4. Сопоставление (Mapping): Система связывает оба URL, так как они имеют общий домен и общий Key 1234.
5. Верификация: Система сравнивает Title и контент по обоим URL. Они совпадают. Сопоставление подтверждено.
6. Передача данных: Данные о цене (99$) и наличии (В наличии) передаются из Индекса Б в Индекс А и ассоциируются с URL https://www.site.com/products/tovar-1234.
7. Результат в поиске: При поиске по соответствующему запросу, органический результат для https://www.site.com/products/tovar-1234 отображается с Rich Snippet, включающим цену и наличие.