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. Он не раскрывает, как именно ранжируются результаты внутри этой локальной базы данных или как определяется их итоговый рейтинг при смешивании с веб-результатами.

Похожие патенты

Как Google использует данные из Local Search и Google Maps для распознавания географических названий в основном поиске
Google анализирует поведение пользователей в интерфейсах с отдельными полями ввода "Что?" и "Где?" (например, в Google Maps). На основе этой статистики система определяет, является ли термин однозначным названием местоположения ("Нью-Йорк") или нет ("Пицца"). Это позволяет поиску отличать локальные запросы от общих и формировать "черные списки" для терминов, которые похожи на города, но ими не являются (например, "Орландо Блум").
  • US8782030B1
  • 2014-07-15

  • Local SEO

  • Семантика и интент

  • Поведенческие сигналы

Как Google определяет релевантность локальных результатов и решает, когда показывать их первыми в выдаче
Google анализирует запрос, чтобы предсказать, ищет ли пользователь локальную информацию. Если да, система автоматически использует текущее или сохраненное местоположение пользователя для генерации локальных результатов. Затем, используя "белые" (Whitelist) и "черные" (Blacklist) списки запросов, Google решает, насколько высоко ранжировать эти локальные результаты по сравнению с обычными веб-результатами или когда следует запросить у пользователя уточнение местоположения.
  • US8005822B2
  • 2011-08-23

  • Local SEO

  • Семантика и интент

Как Google определяет скрытый локальный интент в общих запросах на основе региональной популярности и использования Карт
Google анализирует, является ли общий запрос (без указания места) статистически более популярным в конкретном регионе или часто вводится через интерфейс Карт. Если да, система определяет запрос как «локально значимый», автоматически создает его локализованную версию и подмешивает местные результаты в основную выдачу, обеспечивая видимость локального контента.
  • US9348925B2
  • 2016-05-24

  • Local SEO

  • Семантика и интент

  • SERP

Как Google выбирает, какое местоположение использовать для локализации поисковой выдачи, когда сигналы конфликтуют
Google использует иерархическую систему правил для выбора единственной «геолокации запроса» из множества доступных сигналов. Система анализирует физическое местоположение пользователя, локации в тексте запроса, историю поиска и настройки профиля. Затем она применяет строгую логику приоритетов, чтобы определить, какая локация наиболее релевантна для текущего интента, и соответствующим образом корректирует (смещает) ранжирование результатов.
  • US20150234889A1
  • 2015-08-20

  • Local SEO

  • Персонализация

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

  • Семантика и интент

  • Персонализация

  • Поведенческие сигналы

Популярные патенты

Как Google автоматически добавляет текст существующих объявлений к сайтлинкам (Sitelinks) для повышения CTR
Google использует систему для автоматического улучшения сайтлинков в рекламных объявлениях. Система анализирует существующие текстовые объявления (креативы) рекламодателя и определяет их конечные целевые страницы, игнорируя параметры отслеживания. Затем она сопоставляет их с URL сайтлинков и добавляет наиболее релевантный и эффективный текст креатива к сайтлинку для повышения кликабельности (CTR).
  • US10650066B2
  • 2020-05-12

  • Ссылки

  • SERP

Как Google использует контекст внешних страниц для понимания и идентификации видео и аудио контента
Google анализирует внешние веб-страницы, которые ссылаются на медиафайлы или встраивают их (например, видео YouTube). Система извлекает метаданные из контекста этих страниц — заголовков, окружающего текста, URL. Надежность данных проверяется частотой их повторения на разных сайтах. Эта информация используется для улучшения понимания содержания медиафайла и повышения эффективности систем идентификации контента (Content ID).
  • US10318543B1
  • 2019-06-11

  • Ссылки

  • Индексация

  • Мультимедиа

Как Google классифицирует запросы как навигационные или исследовательские, чтобы регулировать количество показываемых результатов
Google использует систему для динамического определения количества отображаемых результатов поиска. Система классифицирует запрос как навигационный (поиск конкретного места/ресурса) или исследовательский (поиск вариантов). Классификация основана на анализе компонентов оценки релевантности (совпадение по названию vs. категории) и энтропии исторических кликов. При навигационном интенте количество результатов сокращается.
  • US9015152B1
  • 2015-04-21

  • Семантика и интент

  • Поведенческие сигналы

  • Local SEO

Как Google снижает влияние ссылок с аффилированных сайтов и PBN для борьбы с манипуляциями в ранжировании
Патент Google описывает систему ранжирования, которая идентифицирует группы сайтов под общим контролем (аффилированные узлы или PBN). Система резко снижает вес ссылок внутри такой группы и ограничивает общее влияние группы на другие сайты, учитывая только одну, самую сильную ссылку от всей группы. Также описывается механизм "Доверенных авторитетов", чьи ссылки передают максимальный вес независимо от количества исходящих ссылок.
  • US8719276B1
  • 2014-05-06

  • Антиспам

  • Ссылки

  • Техническое SEO

Как Google анализирует текст вокруг ссылки (Rare Words) для борьбы со спамом и определения шаблонных ссылок
Google использует механизм для оценки качества ссылок, выходящий за рамки анкорного текста. Система анализирует редкие слова (rare words) в тексте, непосредственно окружающем ссылку, чтобы определить её уникальный контекст. Ранжирование улучшается при наличии разнообразия этих контекстов. Ссылки с повторяющимся контекстом (спам, Google-бомбинг или шаблонные/сквозные ссылки) идентифицируются и дисконтируются.
  • US8577893B1
  • 2013-11-05

  • Антиспам

  • Ссылки

  • Семантика и интент

Как Google динамически перестраивает выдачу, если пользователь игнорирует результаты, связанные с определенной сущностью
Google использует механизм уточнения интента пользователя в реальном времени при обработке неоднозначных запросов. Система группирует результаты поиска по связанным сущностям. Если пользователь демонстрирует отсутствие интереса к одной из групп (например, прокручивает или смахивает результаты), система динамически модифицирует выдачу, понижая или удаляя все результаты, связанные с этой отклоненной сущностью.
  • US9348945B2
  • 2016-05-24

  • Семантика и интент

  • SERP

  • Поведенческие сигналы

Как Google персонализирует подсказки Autocomplete, анализируя запросы похожих пользователей и обновляя локальный кэш устройства
Google персонализирует подсказки Autocomplete (Search Suggest), анализируя поведение пользователей со схожими профилями (местоположение, интересы, история поиска). Система генерирует кастомизированное обновление для локального кэша устройства на основе запросов, введенных этими похожими пользователями. Это означает, что разные пользователи видят разные подсказки для одного и того же ввода.
  • US8868592B1
  • 2014-10-21

  • Персонализация

  • Поведенческие сигналы

  • Local SEO

Как Google использует личные интересы пользователя для понимания неопределенных запросов и персонализации рекомендаций
Google использует механизм для интерпретации неопределенных запросов или команд (например, «Я голоден» или «Мне скучно»), когда контекст неясен. Если система не может определить конкретное намерение пользователя только из текущего контента (например, экрана приложения), она обращается к профилю интересов пользователя (User Attribute Data) и его местоположению, чтобы заполнить пробелы и предоставить персонализированные рекомендации или выполнить действие.
  • US10180965B2
  • 2019-01-15

  • Персонализация

  • Семантика и интент

  • Local SEO

Как Google персонализирует поисковую выдачу, анализируя историю кликов и поведение пользователя на сайте
Google использует механизм для персонализации поисковой выдачи на основе истории взаимодействия пользователя с результатами поиска. Система отслеживает, какие сайты пользователь выбирает, как долго он на них остается (Dwell Time), частоту и контекст выбора. Основываясь на этих данных, предпочитаемые пользователем ресурсы повышаются в ранжировании при его последующих запросах.
  • US9037581B1
  • 2015-05-19

  • Персонализация

  • Поведенческие сигналы

  • SERP

Как Google использует историю поиска и браузинга для персонализации выдачи и определения предпочтений пользователя
Google записывает и анализирует историю действий пользователя: запросы, клики по результатам и рекламе, посещенные страницы. Система группирует связанные действия в сессии, определяет "Предпочитаемые локации" на основе частоты и времени визитов (stay-time), и использует эту историю для изменения порядка ранжирования, повышая позиции ранее посещенных сайтов в персональной выдаче.
  • US20060224583A1
  • 2006-10-05

  • Персонализация

  • Поведенческие сигналы