Как Google связывает локальные бизнес-данные (адреса и телефоны) с веб-сайтами для показа в результатах поиска

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

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

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

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

База данных, содержащая структурированную информацию о компаниях (название, адрес, телефон, веб-сайт, Cluster ID). Пополняется из сторонних источников (например, Yellow Pages, InfoUSA, Acxiom) или путем сканирования веба.

Mapping Component (Компонент сопоставления)

Система, отвечающая за связывание записей из Local Search Data Storage с URL в Web Search Index Storage. Включает логику разрешения конфликтов.

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

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

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

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

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

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

1. Система анализирует записи в локальной базе данных (содержащие веб-адрес, контактную информацию и идентификатор компании).
2. Идентификатор компании сопоставляется с несколькими веб-адресами (если применимо).
3. Система выбирает один веб-адрес из нескольких для этого идентификатора.
4. Этот один веб-адрес ассоциируется с контактной информацией в поисковом индексе.
5. При получении запроса генерируются результаты. Это включает автоматическое определение географического местоположения пользователя по IP-адресу и использование его для выполнения локального поиска.
6. Система идентифицирует телефон/адрес для результата поиска, используя поисковый индекс.
7. Результаты предоставляются пользователю, включая телефон/адрес в непосредственной близости к результату поиска.

Claim 10 (Независимый пункт): Описывает систему, реализующую метод.

Система включает средства для выполнения шагов, аналогичных Claim 1. Дополнительно включает:

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

Claim 16 (Независимый пункт): Фокусируется на системе и методах разрешения неоднозначностей, в частности, на основе источников данных.

Система выполняет шаги анализа, сопоставления, выбора одного URL и ассоциации в индексе. При генерации результатов:

1. Определяет, связана ли информация с одним из результатов с несколькими веб-страницами.
2. Идентифицирует один URL для включения в результат поиска на основе источников (one or more sources), предоставивших информацию об этих веб-страницах (т.е. доверяет более авторитетным источникам данных).

Claim 20 (Независимый пункт): Детализирует методы выбора URL при конфликтах.

При генерации результатов система определяет, связаны ли несколько URL с одним из результатов поиска в индексе. Если да, то идентифицирует один URL на основе (i) источника, предоставившего URL, или (ii) информации на веб-странице, соответствующей URL (т.е. верификация контента).

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

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

CRAWLING – Сканирование и Сбор данных
Система собирает данные как для веб-индекса, так и для Local Search Data Storage. Локальные данные также поступают от сторонних поставщиков.

INDEXING – Индексирование и извлечение признаков
Ключевой этап применения. Mapping Component работает на этом этапе в режиме офлайн (предварительная обработка). Он анализирует Local Search Data Storage, сопоставляет Cluster IDs с URL, разрешает конфликты и обогащает Web Search Index Storage контактной информацией. Это трансформирует веб-индекс в гибридный индекс, содержащий как веб-документы, так и структурированные локальные данные.

RANKING – Ранжирование / METASEARCH – Метапоиск и Смешивание
На этапе выполнения запроса система извлекает результаты из обогащенного веб-индекса. Логика отображения определяет, нужно ли показывать контактную информацию.

RERANKING – Переранжирование (Локализация)
Если URL связан с несколькими локациями (многофилиальный бизнес), система может инициировать параллельный локальный поиск, используя автоматически определенное местоположение пользователя (IP-адрес, cookie), чтобы найти и отобразить наиболее релевантный результат.

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

• Local Search Data Storage (Cluster IDs, NAP, URL).
• Web Search Index Storage (Веб-документы).
• Данные об авторитетности источников локальных данных (Feeds).
• WHOIS данные.
• Пользовательский запрос.
• Данные о местоположении пользователя (IP-адрес, Cookie, GPS).

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

• Обогащенный Web Search Index Storage.
• Улучшенная поисковая выдача (SERP) с контактной информацией и ссылками на карты/дополнительную информацию.

На что влияет

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

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

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

• Успешное сопоставление: Система смогла однозначно сопоставить Cluster ID с конкретным URL в веб-индексе.
• Исключение крупных сайтов: В патенте упоминается возможность не показывать контактную информацию для очень крупных веб-сайтов (например, www.dell.com), если количество страниц на сайте превышает порог, так как общая корпоративная информация может быть не полезна пользователю (Claim 21).
• Многофилиальные компании: Если URL связан с несколькими Cluster IDs (например, сайт сети ресторанов), система может не показывать конкретный адрес, а вместо этого активировать механизм локализации пользователя для показа ближайшего филиала (Claim 23) или предоставить ссылку на локальный поиск.

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

Процесс А: Предварительная обработка (Mapping)

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

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

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

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

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

• Технические факторы: URL-структура (для сопоставления), IP-адрес пользователя (для определения местоположения), Cookies (для определения местоположения). Количество страниц на сайте (для фильтрации крупных сайтов).
• Контентные факторы: Текст на веб-страницах (используется для верификации адресов и телефонов при разрешении конфликтов URL и для выявления сайтов-каталогов).
• Географические факторы: Адреса, почтовые индексы, телефонные номера (NAP) из Local Search Data Storage. Широта и долгота (для генерации карт).
• Внешние данные: Информация от сторонних поставщиков локальных данных (Feeds, например, InfoUSA, Acxiom). Данные из реестров доменных имен (WHOIS).

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

Патент не приводит конкретных формул, но описывает метрики и логические условия для принятия решений:

• Надежность источника данных (Source Reliability): Оценка авторитетности источника, предоставившего локальные данные. Используется для выбора URL при конфликтах (предпочтение более надежным источникам).
• Совпадение контактной информации (Contact Information Match): Булево значение или оценка, указывающая, совпадают ли данные NAP на веб-странице или в WHOIS с данными в Local Search Data Storage.
• Количество адресов на странице: Метрика для выявления каталогов. Если количество адресов превышает порог, URL может быть исключен из сопоставления.
• Размер сайта (Site Size): Количество страниц на сайте. Используется для исключения слишком крупных корпоративных сайтов, где общий адрес не полезен (порог размера сайта).
• Количество локаций (Number of Locations): Количество Cluster IDs, связанных с одним URL. Используется для определения многофилиальных компаний и активации логики локализации.

1. Интеграция локальных данных в веб-индекс: Google не просто выполняет два отдельных поиска (веб и локальный), а активно обогащает основной веб-индекс структурированными локальными данными. Это позволяет быстро предоставлять улучшенные результаты.
2. Критичность сопоставления Сущность-URL: Ядром изобретения является точное сопоставление бизнес-сущности (Cluster ID) с её каноническим веб-представительством (URL). Этот процесс имеет решающее значение для видимости локального бизнеса в веб-поиске.
3. Сложный механизм разрешения конфликтов: Патент раскрывает многофакторный подход к разрешению неоднозначностей при сопоставлении URL. Google учитывает авторитетность источников данных, проводит верификацию контента на странице и использует внешние сигналы (WHOIS). Несогласованность данных (Inconsistent NAP) напрямую вредит этому процессу.
4. Автоматическое определение местоположения пользователя: Система активно использует IP-адреса (и другие сигналы, такие как cookies и GPS) для определения местоположения пользователя, особенно при обработке запросов к многофилиальным компаниям, чтобы предоставить наиболее релевантный локальный результат.
5. Фильтрация по качеству и типу сайта: Система может исключать из улучшенного отображения сайты-каталоги (слишком много адресов на странице) или слишком крупные корпоративные сайты, демонстрируя стремление предоставлять только полезную локальную информацию.

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

• Обеспечение абсолютной согласованности NAP: Убедитесь, что Название, Адрес и Телефон (NAP) компании идентичны на вашем веб-сайте, в Google Business Profile (GBP) и во всех внешних источниках (каталоги, цитирования). Это критически важно для Mapping Component, чтобы избежать конфликтов при выборе канонического URL и верификации контента.
• Управление данными у агрегаторов и в каталогах: Поскольку Local Search Data Storage пополняется из сторонних источников (Feeds), и авторитетность этих источников влияет на выбор URL (Claim 16), необходимо активно управлять присутствием компании у основных агрегаторов данных и в авторитетных каталогах.
• Четкая и доступная для сканирования контактная информация: Размещайте контактную информацию на сайте в текстовом формате (не в изображениях). Это позволяет системе верифицировать контент страницы при разрешении конфликтов URL. Использование микроразметки LocalBusiness рекомендуется для стандартизации этих данных.
• Структура сайта для многофилиальных компаний: Создавайте отдельные, четко структурированные страницы для каждого физического филиала. Это поможет системе корректно сопоставить каждый Cluster ID (филиал) с соответствующим URL (страница филиала), вместо того чтобы связывать все филиалы с главной страницей сайта и полагаться только на автоматическую локализацию.
• Корректные данные в WHOIS: Убедитесь, что контактная информация в WHOIS актуальна и соответствует официальным данным компании, так как она может использоваться для верификации.

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

• Несогласованные данные NAP: Использование разных номеров телефонов (например, колл-трекинг без указания основного номера) или разных вариантов адреса в разных источниках. Это создает конфликты, которые могут помешать Mapping Component корректно связать сайт с бизнес-сущностью.
• Создание сайта-каталога на домене бизнеса: Размещение большого количества сторонних адресов или филиалов без четкой структуры может привести к тому, что система классифицирует сайт как каталог (Claim 14) и исключит его из улучшенного отображения.
• Скрытие местоположения или использование только абонентских ящиков: Отсутствие четкого физического адреса затрудняет создание Cluster ID и последующее сопоставление с веб-сайтом для локального поиска.

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

Этот патент подтверждает стратегическую важность управления сущностями (Entity Management) и точности данных для локального SEO. Видимость в поиске напрямую зависит от того, насколько успешно Google может идентифицировать компанию как сущность и связать её с веб-сайтом. Для Senior SEO-специалистов это означает, что стратегия локального продвижения должна строиться вокруг обеспечения максимальной согласованности и качества данных во всей экосистеме локального поиска, а не только оптимизации контента на сайте.

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

Сценарий 1: Разрешение конфликта URL для малого бизнеса

1. Ситуация: У кафе "Кофе Хауз" есть официальный сайт cafehouse.com. Также существует старый сайт cafehouse-msk.ru и агрегатор cafereview.ru, где есть страница о них. В Local Search Data Storage все три URL связаны с Cluster ID кафе.
2. Действие SEO: Необходимо убедиться, что NAP на cafehouse.com идеально совпадает с данными в GBP. Проверить WHOIS для cafehouse.com. Убедиться, что основные агрегаторы данных указывают cafehouse.com как официальный сайт. Со старого сайта настроить 301 редирект или удалить его.
3. Результат: Mapping Component выберет cafehouse.com как канонический URL на основе совпадения контента, WHOIS и авторитетности источников, игнорируя другие URL. В выдаче по запросу "Кофе Хауз" будет показан сниппет cafehouse.com с адресом и телефоном.

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

1. Ситуация: Сеть пиццерий PizzaBrand имеет сайт pizzabrand.com. Все филиалы указаны на одной странице pizzabrand.com/locations. В поиске Google не может определить, какой филиал показать, и выдача не локализуется корректно.
2. Действие SEO: Реструктуризация сайта: создание отдельных страниц для каждого филиала (например, pizzabrand.com/locations/moscow-arbat). На каждой странице указать уникальный NAP. Регистрация каждого филиала как отдельной сущности в GBP с указанием соответствующего URL.
3. Результат: Mapping Component сопоставляет каждый Cluster ID (филиал) с его уникальным URL. Когда пользователь ищет "PizzaBrand", система определяет его IP-адрес (например, Москва), выполняет локальный поиск и с большей вероятностью покажет в выдаче ссылку на pizzabrand.com/locations/moscow-arbat с адресом этого конкретного филиала.