Как Google связывает данные локального поиска с веб-индексом для обогащения сниппетов адресами и картами

Описание

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

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

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

Запатентована система и метод для обогащения стандартных результатов веб-поиска структурированными данными из локального индекса. Суть изобретения заключается в предварительном (офлайн) процессе связывания URL-адресов в основном веб-индексе (Web Search Index Storage) с записями о конкретных бизнесах (Cluster ID) в базе данных локального поиска (Local Search Data Storage). Эта связь позволяет отображать контактную информацию и ссылку на карту прямо в сниппете веб-результата.

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

Система работает в два основных этапа:

• Офлайн-процесс (Индексирование/Маппинг): Специальный компонент (Mapping Component) связывает записи о бизнесе (Cluster ID) из локальной базы данных с их URL. Этот процесс включает строгую верификацию данных (например, путем извлечения контактов со страницы или через WHOIS) и применение фильтров. Система исключает сайты, которые слишком велики, являются директориями или имеют неоднозначную привязку к локации. Подтвержденная информация сохраняется в основном веб-индексе.
• Рантайм-процесс (Поиск): Когда пользователь вводит запрос, система извлекает результаты из веб-индекса. Если для URL сохранена контактная информация и нет неоднозначности (например, один URL для множества локаций), система отображает ее в сниппете вместе со ссылкой Map & Info. При неоднозначности может использоваться локализация пользователя.

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

Высокая. Патент описывает фундаментальный механизм интеграции локального поиска и основного веб-поиска, который является предшественником современной интеграции данных из Google Business Profile (GBP) в органическую выдачу. Процессы верификации данных, разрешения конфликтов и связывания веб-страниц с локальными сущностями остаются критически важными для обеспечения качества поиска.

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

Патент имеет значительное влияние на SEO (8/10), особенно в локальном сегменте (Local SEO). Он демонстрирует механизмы, с помощью которых Google связывает веб-сайт с физическим местоположением бизнеса. Понимание процесса верификации и критериев исключения (консистентность NAP, размер сайта, структура директории) критически важно для оптимизации сайтов и обеспечения корректного отображения в органической выдаче, что напрямую влияет на видимость и CTR.

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

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

Cluster ID (Идентификатор кластера)

Уникальный идентификатор, который группирует записи, относящиеся к одному и тому же бизнесу или организации в Local Search Data Storage. Представляет собой локальную сущность.

Local Search Data Storage (Хранилище данных локального поиска)

База данных, содержащая структурированную информацию о локальных объектах (Название, Адрес, Телефон — NAP, URL). Источники данных — сторонние поставщики (например, InfoUSA, Acxiom, Желтые Страницы) или сканирование веб-страниц.

Mapping Component (Компонент маппинга)

Система, отвечающая за офлайн-процесс создания и верификации связей между Cluster ID и URL-адресами. Включает логику разрешения конфликтов и применения фильтров.

Web Search Index Storage (Хранилище индекса веб-поиска)

Основной индекс поисковой системы. В контексте патента, он модифицируется для хранения контактной информации, связанной с конкретными URL.

Candidate contact information (Кандидатная контактная информация)

Контактная информация, извлеченная непосредственно с веб-страницы или полученная из других источников (например, WHOIS). Используется для верификации данных в Local Search Data Storage.

WHOIS query (WHOIS-запрос)

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

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

Патент фокусируется на офлайн-процессе связывания (маппинга) локальных данных с веб-индексом и строгих условиях (фильтрах) для этого процесса.

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

1. Система идентифицирует записи, связанные с Cluster ID в локальном хранилище.
2. Система использует URL для получения Candidate contact information, НО ТОЛЬКО ЕСЛИ размер веб-сайта (определяемый количеством страниц) меньше заданного порога (predetermined size).
3. Система определяет, соответствует ли кандидатная информация сохраненной контактной информации для данного Cluster ID.
4. Информация, связанная с Cluster ID, сохраняется вместе с URL в веб-индексе, ТОЛЬКО ЕСЛИ данные соответствуют.

Ключевой элемент — Фильтр по размеру сайта. Это механизм для исключения слишком крупных сайтов (например, глобальных корпораций), где отображение адреса штаб-квартиры не несет практической пользы.

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

1. Система идентифицирует записи, связанные с Cluster ID.
2. Система извлекает (extracting) Candidate contact information с веб-страницы и определяет количество извлеченных экземпляров (number of instances).
3. Система определяет, соответствует ли кандидатная информация сохраненной контактной информации.
4. Информация сохраняется в веб-индексе, ТОЛЬКО ЕСЛИ данные соответствуют И количество извлеченных экземпляров меньше заданного порога (predetermined number).

Ключевой элемент — Фильтр директорий. Если на странице найдено слишком много адресов/телефонов, система считает страницу агрегатором и не выполняет привязку.

Claim 6 (Зависимый от 1): Вводит дополнительный фильтр неоднозначности (мультилокационность). Система определяет количество Cluster ID, связанных с данным веб-адресом. Если это количество превышает порог (т.е. один URL связан со слишком многими локациями), информация НЕ сохраняется в веб-индексе.

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

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

CRAWLING – Сканирование и Сбор данных
Краулеры собирают данные для Local Search Data Storage. Также система сканирует конкретные веб-страницы для извлечения Candidate contact information в процессе верификации.

INDEXING – Индексирование и извлечение признаков
Это основной этап применения офлайн-процесса. Mapping Component работает здесь:

1. Анализирует Local Search Data Storage.
2. Выполняет верификацию связи между Cluster ID и URL (используя данные краулинга, WHOIS, надежность источников).
3. Применяет фильтры и пороги (размер сайта, количество контактов на странице, количество Cluster ID на URL).
4. Разрешает конфликты (несколько URL для одного Cluster ID).
5. Внедряет контактную информацию в Web Search Index Storage.

RANKING – Ранжирование
Search Component выполняет стандартный поиск по запросу, извлекая результаты из уже обогащенного Web Search Index Storage.

METASEARCH & RERANKING – Метапоиск, Смешивание и Переранжирование
На финальных этапах система принимает решение об отображении данных. Происходит проверка на неоднозначность (связан ли URL с несколькими Cluster ID). Если да, система может принять решение не показывать контактную информацию или выполнить дополнительный локальный поиск (METASEARCH), используя местоположение пользователя (IP или cookie), чтобы выбрать наиболее релевантную локацию (RERANKING/Персонализация).

На что влияет

• Конкретные типы контента и ниши: Наибольшее влияние на сайты локальных бизнесов, организаций, школ, ресторанов, магазинов — сущностей, имеющих физический адрес, важный для пользователя.
• Специфические запросы: Влияет преимущественно на навигационные (брендовые) и локальные запросы.
• Исключения: Патент явно описывает механизмы для исключения:
  • Сайтов крупных корпораций (фильтр по размеру сайта).
  • Сайтов-директорий и агрегаторов (фильтр по количеству контактов на странице).
  • Сайтов с высокой степенью неоднозначности локаций.

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

• Офлайн-процесс (Mapping): Выполняется периодически для поддержания актуальности связей. Активируется при наличии URL в записи Local Search Data Storage и успешном прохождении всех фильтров и верификаций (соответствие NAP, пороги размера и количества).
• Рантайм-процесс (Search): Активируется при обработке поискового запроса, если результат (URL) имеет связанную контактную информацию в индексе и связь является однозначной (или неоднозначность была успешно разрешена через локализацию пользователя).

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

Процесс А: Офлайн-маппинг (Mapping Component)

1. Идентификация и Первичный маппинг: Анализ Local Search Data Storage для создания предварительной связи между Cluster ID и его URL(ами).
2. Разрешение конфликтов (Один Cluster ID, много URL): Если один бизнес связан с несколькими URL, система выбирает один основной URL. Методы выбора:
   • Приоритизация надежных источников данных.
   • Верификация путем сравнения контактов (NAP) на веб-странице с данными в хранилище.
   • Использование WHOIS query для подтверждения владельца домена.
3. Применение фильтров и Верификация: Система проверяет выбранный URL и сайт:
   • Фильтр размера сайта (Claim 1): Если количество страниц превышает порог, маппинг отклоняется.
   • Извлечение и Фильтр директорий (Claim 7): Система извлекает контактные данные со страницы. Если количество найденных контактов превышает порог, маппинг отклоняется.
   • Проверка соответствия (Consistency): Извлеченные данные (Candidate contact information) сравниваются с данными Cluster ID. Если они конфликтуют, маппинг отклоняется.
   • Фильтр неоднозначности (Claim 6): Проверка, не связан ли этот URL с слишком большим количеством других Cluster ID.
4. Инверсия и сохранение: Если все проверки пройдены, создается обратное отображение от URL к Cluster ID. Контактная информация сохраняется в Web Search Index Storage вместе с этим URL.

Процесс Б: Обработка запроса (Runtime — Search Component)

1. Генерация результатов: Система генерирует результаты поиска из обогащенного Web Search Index Storage.
2. Извлечение обогащенных данных: Для топовых результатов система проверяет наличие связанной контактной информации.
3. Проверка на неоднозначность (Один URL, много Cluster ID): Система определяет, связан ли URL с несколькими локациями (например, сайт сети).
   • Если НЕТ (однозначно): Система формирует улучшенный сниппет с контактной информацией и ссылкой Map & Info.
   • Если ДА (неоднозначно): Система может не показывать информацию или выполнить локальный поиск.
4. Локальный поиск (при неоднозначности): Система определяет местоположение пользователя (IP-адрес, cookie) и использует его для выбора наиболее релевантного Cluster ID (локации бизнеса) для отображения.
5. Формирование SERP: Отображение результатов поиска с обогащенными сниппетами. При клике на Map & Info предоставляется карта и дополнительная информация.

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

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

• Контентные факторы: Текст на веб-странице используется в процессе верификации для извлечения адресов и телефонов (Candidate contact information) и сравнения их с данными локального индекса.
• Технические факторы: URL используется как ключевой идентификатор. Размер сайта (количество страниц) используется для фильтрации (Claim 1). IP-адрес пользователя может использоваться для определения местоположения.
• Структурные данные (Локальный индекс): Local Search Data Storage предоставляет NAP (Name, Address, Phone), URL, Широту/Долготу (для карты).
• Внешние данные: Данные от сторонних поставщиков (InfoUSA, Acxiom) для наполнения локальной базы. Данные WHOIS используются для верификации принадлежности домена.
• Пользовательские факторы: Cookies или GPS данные могут использоваться для определения местоположения пользователя при разрешении неоднозначности.

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

Патент фокусируется на пороговых значениях и проверках соответствия:

• Website Size Threshold (Порог размера сайта): Предопределенное количество веб-страниц. Если превышен, маппинг не выполняется (Claim 1).
• Contact Information Instances Threshold (Порог количества контактов): Предопределенное количество адресов/телефонов на одной странице. Если превышен, страница считается директорией, и маппинг не выполняется (Claim 7).
• Verification Match (Проверка соответствия / NAP Consistency): Сравнение контактной информации из разных источников (Локальный индекс vs. Сайт vs. WHOIS). Маппинг происходит только при соответствии.
• Ambiguity Threshold (Порог неоднозначности): Подсчет количества Cluster ID, связанных с одним URL (Claim 6). Если превышает порог, маппинг может быть отклонен или потребует дополнительной логики локализации во время выполнения запроса.

Выводы

1. Интеграция локального и веб-индексов на уровне индексации: Google использует сложный офлайн-процесс для внедрения структурированных локальных данных непосредственно в основной веб-индекс, а не просто смешивает результаты на лету.
2. Критичность верификации данных и NAP Consistency: Система использует многофакторную верификацию (извлечение данных со страницы, WHOIS, надежные источники) для подтверждения связи между URL и физическим бизнесом (Cluster ID). Согласованность NAP является обязательным условием.
3. Активная фильтрация для обеспечения качества: Патент включает явные механизмы фильтрации для исключения нерелевантных результатов:
   • Фильтр размера сайта (Claim 1): Исключает крупные корпоративные сайты, где общий адрес бесполезен.
   • Фильтр директорий (Claim 7): Исключает агрегаторы и каталоги по количеству контактов на странице.
4. Обработка неоднозначности мультилокационных сайтов: Система распознает проблему, когда один URL представляет множество локаций (Claim 6). В таких случаях она использует локализацию пользователя для выбора релевантного адреса или скрывает информацию.
5. Приоритет пользовательского опыта (UX): Основная цель — экономия времени пользователя, предоставляя контактную информацию и доступ к карте мгновенно, до клика по результату.

Практика

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

• Обеспечение абсолютной согласованности NAP (Name, Address, Phone): Критически важно поддерживать идентичность названия, адреса и телефона на сайте, в Google Business Profile (GBP) и во всех авторитетных внешних каталогах. Это необходимо для успешной верификации связи между URL и Cluster ID.
• Четкое и доступное размещение контактной информации: Контактные данные должны быть легко доступны для извлечения (в текстовом формате). Это помогает системе получить Candidate contact information для верификации (Claim 7). Использование микроразметки Schema.org/LocalBusiness настоятельно рекомендуется.
• Поддержание «чистой» структуры страницы: Убедитесь, что главная или контактная страница не выглядит как директория. Наличие множества разных адресов (например, список партнеров) может активировать фильтр (Claim 7) и помешать отображению ваших контактов.
• Стратегия для мультилокационных бизнесов: Для сетей необходимо создавать отдельные посадочные страницы для каждого филиала с уникальным NAP. Это позволяет системе однозначно связать URL с конкретным Cluster ID, избегая неоднозначности (Claim 6).
• Поддержание актуальности WHOIS: Так как WHOIS query упоминается как метод валидации, необходимо следить за актуальностью и точностью публичной контактной информации в регистрационных данных домена.

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

• Несогласованные контактные данные: Различия в адресах или телефонах между сайтом и внешними источниками приведут к сбою верификации.
• Размещение слишком большого количества адресов на одной странице: Создание страниц, которые могут быть восприняты как директории, активирует фильтр (Claim 7) и помешает сопоставлению основного адреса компании.
• Использование главной страницы для всех локаций без четкой структуры: Если сайт сети использует один URL для всех филиалов, система идентифицирует связь с несколькими Cluster IDs (Claim 6) и может отключить показ контактной информации.
• Скрытие или затруднение доступа к контактной информации: Размещение контактов в изображениях, iframe или через сложный JavaScript затрудняет процесс извлечения данных для верификации.

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

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

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

Сценарий: Оптимизация сниппета для локального бизнеса (кафе)

1. Анализ текущей ситуации: По брендовому запросу в сниппете не отображается адрес и телефон.
2. Проверка (по критериям патента):
   • Согласованность NAP: Обнаружено, что в GBP указан один номер телефона, а на сайте другой (для коллтрекинга). Это вызывает сбой верификации.
   • Фильтр директорий (Claim 7): На главной странице указан только один адрес, фильтр не активирован.
   • Фильтр размера сайта (Claim 1): Сайт небольшой, фильтр не активирован.
3. Действия по оптимизации:
   • Убрать номер коллтрекинга с сайта и заменить его на основной номер, идентичный указанному в GBP.
   • Добавить микроразметку LocalBusiness для структурирования NAP.
4. Ожидаемый результат: При следующем цикле маппинга Mapping Component сможет верифицировать связь, используя согласованные данные. В результате в сниппете появится актуальный адрес, телефон и ссылка Map & Info.

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