Close Menu

    Как Google использует «Белые списки» для определения локального интента и подмешивания локальных результатов, если город в запросе не указан

    SYSTEM AND METHOD FOR DISPLAYING BOTH LOCALIZED SEARCH RESULTS AND INTERNET SEARCH RESULTS (Система и метод отображения как локализованных результатов поиска, так и результатов интернет-поиска)
    2007 Local SEO Индексация Патенты Google Персонализация

    Google применяет систему для выявления неявного локального интента в запросах без указания местоположения (например, «пицца»). Система проверяет запрос по двум разным «Белым спискам» (Whitelists). В зависимости от того, известно ли местоположение пользователя (из профиля или cookie), система либо автоматически добавляет локальные результаты (Local Pack), либо сначала запрашивает у пользователя его локацию.

    Описание

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

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

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

    Запатентована система и метод для выборочного включения локализованных результатов поиска в ответ на запросы без географических указателей. Ключевым элементом является использование двух предопределенных списков запросов (Whitelists) для идентификации локального интента. Логика системы меняется в зависимости от того, известно ли местоположение пользователя: используются разные списки (Long Whitelist или Short Whitelist) для автоматического запуска локального поиска или запроса местоположения.

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

    Система работает по разветвленному алгоритму:

    • Получение запроса: Система получает запрос без географических терминов.
    • Проверка местоположения: Определяется, известно ли местоположение пользователя (например, из cookie или профиля аккаунта).
    • Сценарий 1 (Местоположение известно): Запрос сравнивается с Long Whitelist (обширный список локальных интентов). При совпадении система автоматически ищет в базе локаций (Secondary Database), используя известное местоположение.
    • Сценарий 2 (Местоположение неизвестно): Запрос сравнивается с Short Whitelist (короткий список явных локальных интентов). При совпадении система запрашивает у пользователя его местоположение и затем выполняет поиск в Secondary Database.
    • Смешивание результатов: Локальные результаты (First results) объединяются с результатами стандартного веб-поиска (Second results) из Primary Database и отображаются в одном окне, часто с выделением локальных результатов в OneBox (Local Pack).

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

    Высокая. Определение неявного локального интента является фундаментальной задачей современного поиска, особенно в контексте мобильных устройств. Хотя конкретная реализация через статические Whitelists, вероятно, устарела и заменена моделями машинного обучения, базовая архитектура и концепция определения интента, использования контекста пользователя (локации) и смешивания локальных и веб-результатов (Universal Search) остаются ядром работы Google Поиска.

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

    Патент имеет критическое значение для локального SEO (Local SEO). Он описывает фундаментальную логику, по которой Google решает, показывать ли Local Pack (OneBox) для запросов без явного указания города или фразы «рядом со мной». Понимание этого механизма необходимо для оптимизации сайтов локального бизнеса под ключевые слова с неявным локальным интентом (например, [ресторан], [сантехник], [юрист]).

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

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

    First Results (Первые результаты)
    Локализованные результаты поиска. Соответствуют физическим местоположениям (physical locations), связанным с географическим положением клиента/пользователя. Генерируются из Secondary Database.
    Second Results (Вторые результаты)
    Стандартные результаты интернет-поиска. Соответствуют доступным в Интернете документам (веб-страницам), которые удовлетворяют поисковому запросу. Генерируются из Primary Database.
    Primary Database (Первичная база данных)
    Основная база данных веб-поиска (Web Database), хранящая информацию о документах в Интернете.
    Secondary Database / Locations Database (Вторичная база данных / База данных локаций)
    База данных, хранящая информацию о физических местоположениях (бизнесы, организации, парки и т.д.). На практике соответствует индексу Google Maps/Google Business Profile.
    Local Intent Terms (Термины с локальным интентом)
    Поисковые запросы, которые сигнализируют о желании пользователя получить локализованные результаты, даже если местоположение не указано.
    Long Whitelist (Длинный белый список / First whitelist)
    Первый набор предопределенных терминов с локальным интентом. Используется, когда местоположение пользователя известно системе. Он значительно больше, чем Short Whitelist.
    Short Whitelist (Короткий белый список / Second whitelist)
    Второй набор предопределенных терминов. Используется, когда местоположение пользователя неизвестно. Содержит термины с очень сильным локальным интентом. При совпадении система запрашивает локацию.
    OneBox (One Box)
    Термин, используемый для описания непрерывной подобласти (contiguous sub-region) окна браузера, в которой отображаются локализованные результаты. На практике соответствует Local Pack.
    Geographic Location Information (Информация о географическом местоположении)
    Данные о локации пользователя. Источники: Cookie, профиль пользователя (user profile) или прямой ввод пользователя.

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

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

    1. Система получает запрос, который не содержит географических терминов.
    2. Выполняется поиск в Primary Database (веб-поиск).
    3. Система определяет, связано ли географическое местоположение с клиентом или пользователем.
    4. Путь A (Местоположение известно):
      • Информация о местоположении извлекается (например, из профиля пользователя).
      • Запрос сравнивается с first whitelist (Long Whitelist), но не со вторым.
      • Если сравнение успешно, выполняется поиск в Secondary Database (локальный поиск) для генерации результатов, соответствующих физическим местоположениям в этой локации.
    5. Путь B (Местоположение неизвестно):
      • Запрос сравнивается со second whitelist (Short Whitelist), но не с первым. Важное условие: first whitelist содержит множество терминов, которых нет в second whitelist (т.е. Long значительно больше Short).
      • Если сравнение успешно, система запрашивает и получает географическое местоположение от пользователя.
      • Выполняется поиск в Secondary Database с использованием полученного местоположения.
    6. Система отправляет клиенту подмножество результатов из Primary Database и, если применимо, подмножество результатов из Secondary Database.

    Claim 2 и 9 (Зависимые от 1): Уточняют источники информации о местоположении. Определение местоположения может включать проверку, вошел ли пользователь в систему (logged into a service), и извлечение местоположения из его профиля (user profile), либо получение cookie, который идентифицирует географическое местоположение.

    Claim 5 и 6 (Зависимые от 1): Описывают формат представления. Результаты из Secondary Database (локальные) могут быть отправлены для отображения в непрерывной подобласти (OneBox) окна браузера, или они могут быть отображены в списке выше результатов из Primary Database (веб-результатов).

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

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

    INDEXING – Индексирование и извлечение признаков
    Система поддерживает две отдельные базы данных: Primary Database (Веб-индекс) и Secondary Database (Индекс локаций/мест).

    QUNDERSTANDING – Понимание Запросов
    Это ключевой этап применения патента. Система выполняет классификацию запроса для определения локального интента. Это достигается путем: 1. Определения текущего местоположения пользователя (проверка cookies, профилей). 2. Сравнения запроса со статическими списками (Long Whitelist и Short Whitelist) в зависимости от наличия данных о местоположении.

    RANKING – Ранжирование
    Если активирован локальный интент, система запускает параллельные процессы ранжирования: один для Web Database Search Engine, другой для Locations Database Search Engine.

    METASEARCH – Метапоиск и Смешивание
    Система объединяет результаты из двух источников. Search Results Formatting Module форматирует локальные результаты (используя One Box results formatting module) и веб-результаты для отображения в едином интерфейсе (Blended SERP).

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

    • Поисковый запрос (без географических терминов).
    • Данные о местоположении клиента/пользователя (если доступны).
    • Статические списки Local Intent Terms (Long и Short Whitelists).

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

    • Смешанный набор результатов поиска, включающий стандартные веб-ссылки и блок локальных результатов (OneBox).
    • ИЛИ: Стандартный набор веб-ссылок с запросом на уточнение местоположения пользователя.

    На что влияет

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

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

    Алгоритм применяется при выполнении строгих условий, зависящих от наличия информации о местоположении пользователя.

    Условие 1: Местоположение известно (Known Location)

    • Триггер активации: Запрос совпадает с термином в Long Whitelist.
    • Результат: Автоматическое добавление локальных результатов в выдачу.

    Условие 2: Местоположение неизвестно (Unknown Location)

    • Триггер активации: Запрос совпадает с термином в Short Whitelist.
    • Результат: Система запрашивает местоположение у пользователя. Локальные результаты добавляются только после получения этой информации.

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

    Процесс обработки поискового запроса без географических указателей.

    1. Получение запроса: Сервер получает поисковый запрос от клиента.
    2. Поиск в первичной базе: Система инициирует поиск в Primary Database (веб-поиск) для генерации стандартных результатов.
    3. Определение доступности местоположения: Система проверяет, доступна ли информация о географическом местоположении клиента или пользователя (проверка cookie или профиля).
    4. Путь А: Местоположение известно:
      1. Извлечение местоположения: Система извлекает данные о локации.
      2. Сравнение с Long Whitelist: Запрос сравнивается с Long Whitelist.
      3. Активация локального поиска (если совпадение): Если запрос найден в списке, система инициирует поиск в Secondary Database (база локаций), используя извлеченное местоположение. Переход к шагу 6.
      4. Если совпадения нет: Переход к шагу 6.
    5. Путь Б: Местоположение неизвестно:
      1. Сравнение с Short Whitelist: Запрос сравнивается с Short Whitelist.
      2. Запрос местоположения (если совпадение): Если запрос найден в списке, система запрашивает у пользователя его местоположение (например, город или почтовый индекс).
      3. Получение местоположения и активация поиска: После получения ответа система инициирует поиск в Secondary Database, используя предоставленное местоположение. Переход к шагу 6.
      4. Если совпадения нет: Переход к шагу 6.
    6. Смешивание и форматирование: Если локальный поиск был активирован и дал результаты, система объединяет их (First Results) с результатами веб-поиска (Second Results). Локальные результаты могут быть отформатированы для отображения в OneBox и размещены над веб-результатами.
    7. Отправка результатов: Объединенный набор результатов отправляется клиенту для отображения в одном окне браузера.

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

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

    Патент фокусируется на использовании данных о пользователе и предопределенных списках для классификации запроса.

    • Географические факторы / Пользовательские факторы:
      • Географическое местоположение: Критически важные данные. Источники: Cookie с сохраненной информацией о локации; User Accounts/Profiles (если пользователь вошел в систему — logged into a service); прямой ввод пользователя по запросу системы.
    • Данные запроса (Query Data):
      • Текст поискового запроса, который сравнивается со списками Local Intent Terms.

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

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

    • Whitelists (Белые списки): Основной механизм определения интента. Используются два списка: Long Whitelist и Short Whitelist.
    • Predefined Criteria (Предопределенные критерии): Условием срабатывания является совпадение поискового запроса с термином в соответствующем Whitelist.
    • Размер списков: Патент явно указывает, что Long Whitelist содержит значительно больше терминов, чем Short Whitelist (приводятся примеры: на 100, 500 или 1000 терминов больше). Это означает, что система гораздо более агрессивно предполагает локальный интент, если ей уже известно местоположение пользователя.

    Выводы

    1. Разделение индексов Локального и Веб-поиска: Google использует архитектуру с двумя отдельными базами данных (Primary для веба и Secondary для локаций/физических мест) и специализированными поисковыми движками для каждой из них.
    2. Определение локального интента через Whitelists: Патент описывает механизм классификации запросов с неявным локальным интентом с использованием предопределенных списков (Whitelists). Это позволяет системе решать, когда запускать поиск по Secondary Database.
    3. Дифференцированная агрессивность (Long vs Short): Логика системы кардинально меняется в зависимости от того, известно ли местоположение пользователя. Если известно, используется обширный Long Whitelist (более агрессивный подход). Если неизвестно, используется консервативный Short Whitelist, и система может активно запросить локацию.
    4. Использование пользовательских данных для локализации: Патент подтверждает использование сохраненных данных (cookies и профили аккаунтов) для определения местоположения пользователя и персонализации выдачи без явного указания локации в запросе.
    5. Механизм Blending и OneBox (Universal Search): Запатентован метод интеграции локальных результатов в основную выдачу через выделенную область (OneBox/Local Pack), расположенную над стандартными веб-результатами.
    6. Эволюция определения интента: Хотя статические списки, вероятно, уступили место нейронным сетям, этот патент закладывает фундаментальную логику: контекст пользователя (его локация) является ключом к активации локального поиска по широкому спектру запросов.

    Практика

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

    • Оптимизация под неявный локальный интент: Необходимо определять ключевые слова в вашей нише, которые подразумевают локальный поиск, но не содержат географических указателей (например, [чистка ковров], [срочное фото], [юридическая консультация]). Эти запросы, вероятно, входят в Whitelists (или их современные эквиваленты). Стратегия должна включать оптимизацию под эти запросы наравне с гео-модифицированными.
    • Максимизация присутствия в Locations Database (GBP): Поскольку локальные результаты берутся из Secondary Database (Google Business Profile/Maps), критически важно иметь полный, точный и хорошо оптимизированный профиль компании. Это гарантирует, что ваш бизнес будет рассмотрен при активации локального поиска.
    • Работа с категориями бизнеса: Выбор правильных основных и дополнительных категорий в GBP напрямую влияет на то, по каким запросам с локальным интентом будет показываться компания, так как категории часто коррелируют с терминами в Whitelists.
    • Усиление локальных сигналов на сайте: Необходимо обеспечить сильную связь между сайтом (Primary Database) и профилем GBP (Secondary Database) через согласованные NAP-данные (Name, Address, Phone), локальную микроразметку (LocalBusiness) и контент, ориентированный на вашу локацию.

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

    • Игнорирование общих запросов в локальном SEO: Ошибка считать, что локальное продвижение касается только запросов вида [услуга + город]. Патент показывает, что Google активно пытается локализовать общие запросы без гео-модификаторов.
    • Фокус только на веб-сайте: Для локального бизнеса недостаточно иметь хорошо ранжируемый сайт в органической выдаче. Если компания отсутствует или плохо оптимизирована в Secondary Database (GBP), она упустит трафик из OneBox (Local Pack), который часто располагается выше органических результатов.
    • Отсутствие четкой географической привязки: Попытки ранжироваться в локальном поиске без реального физического присутствия или четкой зоны обслуживания противоречат логике Locations Database, которая хранит данные о физических местоположениях.

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

    Патент подтверждает стратегию Google по интеграции локального поиска в основной продукт (Universal Search). Для SEO-специалистов это подчеркивает, что локальный поиск — это не отдельная вертикаль, а неотъемлемая часть обработки большинства коммерческих запросов. Стратегия продвижения любого бизнеса с физическим присутствием должна строиться вокруг оптимизации сущности компании в Locations Database (GBP) как приоритетной задачи. Также важно понимать, что поведение выдачи может меняться в зависимости от того, локализован пользователь или нет (логика Long vs Short Whitelist).

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

    Сценарий 1: Известное местоположение (Long Whitelist)

    1. Контекст: Пользователь вошел в свой аккаунт Google, в профиле которого указан город Пало-Альто, или у него есть cookie с этой локацией.
    2. Запрос: Пользователь вводит [музеи].
    3. Обработка: Система определяет местоположение (Пало-Альто). Запрос [музеи] присутствует в Long Whitelist.
    4. Действие: Система автоматически выполняет поиск в Secondary Database по запросу [музеи в Пало-Альто] и в Primary Database по запросу [музеи].
    5. Результат: Пользователь видит OneBox (Local Pack) с музеями Пало-Альто над стандартными органическими результатами (например, статьей в Википедии о музеях).

    Сценарий 2: Неизвестное местоположение (Short Whitelist)

    1. Контекст: Пользователь использует режим инкогнито, cookie отсутствуют, вход в аккаунт не выполнен. Местоположение неизвестно.
    2. Запрос: Пользователь вводит [срочный ремонт сантехники].
    3. Обработка: Местоположение неизвестно. Запрос сравнивается с Short Whitelist. Этот запрос имеет очень сильный локальный интент и присутствует в списке.
    4. Действие: Система отображает стандартные веб-результаты, но также добавляет блок: «Ищете локальные результаты для [срочный ремонт сантехники]? Укажите город или индекс».
    5. Результат: Если пользователь вводит свой город, система перезагружает выдачу, добавляя OneBox с локальными сантехниками.

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

    В чем ключевое различие между Long Whitelist и Short Whitelist?

    Long Whitelist используется, когда система уже знает местоположение пользователя (через cookie или профиль). Он значительно обширнее и включает запросы с умеренным локальным интентом. Short Whitelist используется, когда местоположение неизвестно. Он короче и содержит только запросы с очень сильным, однозначным локальным интентом. Если запрос попадает в Short Whitelist, система запросит у пользователя его местоположение.

    Как Google узнает местоположение пользователя согласно этому патенту?

    Патент указывает три основных источника. Первый — это cookie, в котором сохраняется информация о локации из предыдущих сессий. Второй — это профиль пользователя (User Profile), если пользователь вошел в систему (logged into a service). Третий — прямой запрос местоположения у пользователя, если сработал Short Whitelist. IP-адрес в данном патенте явно не упоминается.

    Что такое Primary Database и Secondary Database на практике?

    Primary Database — это основной веб-индекс Google, содержащий миллиарды веб-страниц. Secondary Database (или Locations Database) — это индекс физических мест, бизнесов и организаций. На практике это база данных, которая питает Google Maps и Google Business Profile (GBP). Для успешного локального SEO необходимо присутствие в обеих базах.

    Что такое OneBox, упоминаемый в патенте?

    OneBox — это технический термин Google для обозначения специального блока результатов, который интегрируется в основную выдачу (Universal Search). В контексте этого патента OneBox используется для отображения локальных результатов в виде непрерывной подобласти (contiguous sub-region). Сегодня мы знаем этот блок как Local Pack (блок с картой и списком компаний).

    Актуален ли этот патент, если Google сейчас использует машинное обучение для определения интента?

    Да, патент остается актуальным с точки зрения архитектуры и стратегии. Хотя механизм определения локального интента, вероятно, эволюционировал от статических списков (Whitelists) к сложным ML-моделям, базовая концепция остается той же: определить интент, определить локацию и запустить поиск в двух разных базах данных (Веб и Локальной), а затем смешать результаты.

    Что произойдет, если мой бизнес-запрос есть в Long Whitelist, но нет в Short Whitelist?

    Если запрос есть только в Long Whitelist, ваш бизнес будет показан в локальных результатах только тем пользователям, чье местоположение уже известно Google. Пользователям с неизвестным местоположением локальные результаты по этому запросу автоматически показаны не будут, и система не будет запрашивать у них уточнение локации.

    Что важнее для локального бизнеса: ранжирование в органике (Primary) или в Local Pack (Secondary)?

    Патент указывает (Claim 6), что локальные результаты (Secondary) могут быть отображены выше стандартных веб-результатов (Primary). Учитывая визуальную заметность и расположение Local Pack на современной выдаче, оптимизация присутствия в Secondary Database (GBP) часто является более приоритетной задачей для привлечения локального трафика.

    Почему система более агрессивна в показе локальных результатов, если знает мое местоположение?

    Если система знает местоположение, у нее больше контекста для интерпретации запроса. Это снижает риск ошибки и позволяет использовать более обширный Long Whitelist. Например, запрос [книги] может быть общим, но если система знает, что вы в центре города, она с большей уверенностью предположит, что вы ищете книжный магазин поблизости, и покажет Local Pack.

    Может ли мой бизнес попасть в Whitelist?

    Whitelists содержат типы запросов (например, [ресторан], [автосервис]), а не названия конкретных бизнесов. SEO-специалист не может напрямую добавить запрос в список. Однако, оптимизируя бизнес под релевантные категории и услуги с высоким локальным интентом, вы увеличиваете вероятность того, что ваш бизнес будет показан, когда пользователь введет соответствующий запрос из Whitelist.

    Есть ли в патенте информация о факторах ранжирования внутри локальной выдачи?

    Нет. Патент фокусируется исключительно на механизме определения локального интента (с использованием Whitelists) и триггерах для запуска поиска по Locations Database. Он не раскрывает, как именно ранжируются результаты внутри этой локальной базы данных или как определяется их итоговый рейтинг при смешивании с веб-результатами.