Как Google определяет, ищет ли пользователь информацию НА сайте сущности (бренда/издателя) или О ней, и переписывает запрос

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

Candidate Strings (Строки-кандидаты)

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

Common word or phrase (Общеупотребительное слово или фраза)

Слово или фраза, имеющие широкое распространение в языке (определяется по словарю, IDF или лингвистическим моделям). Критерий для принятия решения о способе переписывания запроса.

Entity (Сущность)

Объект, который может быть связан с определенными документами. Примеры: новостные источники, магазины, бренды, авторы, люди, места и организации.

Entity Identifier (Идентификатор сущности)

Уникальный идентификатор, связанный с сущностью, например, доменное имя (URL) или идентификатор категории.

Entity Name (Название сущности)

Текстовое название сущности (например, "Washington Post").

Restrict Identifier (Идентификатор ограничения)

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

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

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

1. Система получает поисковый запрос.
2. Определяется, включает ли запрос Entity Name.
3. Определяется, соответствует ли Entity Name одному из common words or phrases.
4. Запрос переписывается с включением Restrict Identifier, ограничивающего поиск доменом (domain), связанным с Entity Name.
5. Сценарий А: Поиск выполняется на основе переписанного запроса, ЕСЛИ Entity Name НЕ соответствует общеупотребительному слову.
6. Сценарий Б: Поиск выполняется на основе исходного запроса, ЕСЛИ Entity Name соответствует общеупотребительному слову. В этом случае также предоставляется ссылка на переписанный запрос.

Claim 12 (Независимый пункт): Детализирует оба сценария обработки и результат для пользователя.

Сценарий (Общеупотребительное название): Генерируется ссылка на переписанный запрос. Выполняется поиск по исходному запросу. Результаты и ссылка предоставляются пользователю.

Сценарий (Уникальное название): Исходный запрос переписывается с Restrict Identifier, идентифицирующим конкретный домен (particular domain). Генерируется ссылка на исходный запрос. Выполняется поиск в пределах этого домена. Результаты и ссылка предоставляются пользователю.

Claim 4 (Зависимый от 1): Вводит механизм защиты от разрыва устойчивых фраз.

Система определяет, образует ли слово рядом с Entity Name в запросе общеупотребительную фразу вместе с этим названием (например, "time travel"). Если ДА, поиск выполняется на основе исходного запроса, чтобы не разлагать фразу.

Claims 5, 6, 7 (Зависимые от 1): Описывают методы определения общеупотребительности.

Методы включают сравнение со словарем (Claim 5), использование IDF (inverse document frequency) или лингвистического моделирования (Claim 6), или использование предварительно сгенерированной таблицы (Claim 7).

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

Изобретение применяется на ранних этапах обработки запроса и является ключевой частью интерпретации интента пользователя.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит офлайн-подготовка данных: сбор сущностей, определение их идентификаторов (доменов), генерация Candidate Strings и расчет метрик общеупотребительности слов (например, IDF).

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Система выполняет в реальном времени:

1. Распознавание сущностей (NER): Идентифицирует Entity Name в запросе путем сравнения со списком Candidate Strings.
2. Разрешение неоднозначности (Disambiguation): Определяет, является ли Entity Name общеупотребительным словом и не формирует ли оно устойчивое словосочетание с соседними словами (Claim 4).
3. Переписывание запроса (Query Rewriting): На основе разрешения неоднозначности система решает, переписать ли запрос, добавив Restrict Identifier, или предложить переписывание как опцию.

RANKING – Ранжирование
Этап ранжирования получает на вход уже обработанный запрос. Если запрос был переписан с Restrict Identifier, система ранжирования будет ограничена поиском только в пределах указанного домена или контекста.

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

• Исходный поисковый запрос пользователя.
• Список Candidate Strings.
• Лингвистические данные (словари, модели IDF) для определения common word or phrase.

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

• Запрос для выполнения поиска (исходный или переписанный).
• Ссылка на альтернативную интерпретацию запроса.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на брендовые, навигационные запросы и запросы типа [тема] + [бренд/источник] (например, "новости украина bbc" или "iphone 15 apple").
• Конкретные ниши или тематики: Особенно актуально для СМИ (News), электронной коммерции (Stores, Brands) и любых ниш с большим количеством известных сущностей.
• Типы контента: Влияет на то, будут ли в выдаче преобладать документы с официального сайта сущности или микс документов из разных источников.

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

• Триггер активации: В поисковом запросе обнаружен термин, который соответствует Entity Name в списке Candidate Strings.
• Условия для автоматического переписывания: Происходит, если Entity Name НЕ является общеупотребительным словом.
• Исключения: Автоматическое переписывание может быть заблокировано, если Entity Name является частью устойчивого словосочетания (например, "time travel").

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

Процесс А: Генерация данных (Офлайн)

1. Сбор сущностей: Получение списка Entity Names из директорий или путем анализа корпуса документов.
2. Идентификация: Определение Entity Identifier (например, домена) для каждого названия.
3. Генерация вариаций: Применение трансформаций (удаление Inc., .com, замена пробелов, обработка "and" и "&") для создания списка Candidate Strings.
4. Анализ общеупотребительности: Определение того, какие Entity Names являются common words or phrases (используя IDF, словари).

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

1. Получение запроса: Система получает запрос от пользователя.
2. Обнаружение сущности: Термины запроса (часто крайние левые или правые) сравниваются со списком Candidate Strings.
3. Проверка контекста (Опционально): Анализ соседних слов на предмет формирования устойчивой фразы. Если фраза найдена (например, "time travel"), процесс переписывания может быть остановлен.
4. Оценка общеупотребительности: Система определяет, является ли Entity Name common word or phrase.
5. Принятие решения и выполнение:
   • Если НЕ общеупотребительное (Уникальное): Запрос переписывается с добавлением Restrict Identifier. Генерируется ссылка на исходный запрос. Поиск выполняется по переписанному запросу.
   • Если общеупотребительное (Неоднозначное): Запрос остается исходным. Генерируется ссылка на переписанный (ограниченный) запрос. Поиск выполняется по исходному запросу.
6. Презентация результатов: Отображение результатов поиска и ссылки на альтернативный запрос.

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

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

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

• Структурные данные (Сущности): Entity Names, Entity Identifiers (домены, URL) и их вариации (Candidate Strings). Эти данные собираются из внешних источников (директории) или путем анализа корпуса документов.
• Лингвистические данные: Данные для определения common word or phrase. Это могут быть словари, данные об обратной частоте документов (IDF) или данные лингвистических моделей (частотность терминов).
• Контентные факторы (Косвенно): Анализ корпуса документов используется офлайн для выявления устойчивых фраз, которые не следует разлагать (фразы, встречающиеся чаще порогового числа раз).

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

В патенте упоминаются следующие методы оценки общеупотребительности (Commonality):

• Inverse Document Frequency (IDF): Используется для определения распространенности Entity Name. Низкий IDF указывает на общеупотребительное слово.
• Лингвистическое моделирование: Анализ корпуса документов для создания хэш-таблицы частотности терминов. Термины, встречающиеся чаще порогового значения, считаются общеупотребительными.
• Словарная сверка: Прямое сравнение Entity Name со словарем слов и фраз.
• Частотность фраз: Метрика для определения устойчивых словосочетаний, основанная на частоте их появления в корпусе документов.

1. Google активно управляет интентом при брендовых запросах: Система не просто ищет ключевые слова, а интерпретирует намерение пользователя: ищет ли он информацию НА сайте упомянутой сущности или О ней, и автоматически применяет ограничители (аналоги site: или source:).
2. Уникальность названия сущности как ключевой триггер: Критерием для автоматического переписывания запроса является уникальность названия сущности. Если оно совпадает с common word or phrase, Google предпочитает широкую интерпретацию (консервативный подход). Если оно уникально, Google склоняется к ограничению поиска доменом сущности.
3. Механизм разрешения неоднозначности и страховки: Система предусматривает "страховку" на случай ошибки интерпретации. Независимо от принятого решения, пользователю всегда предлагается ссылка на альтернативную версию поиска (широкую или ограниченную).
4. Защита от разрыва фраз: Включение опциональной проверки контекста (чтобы не разбивать фразы типа "time travel") показывает стремление сбалансировать агрессивное переписывание с сохранением исходного смысла запроса.
5. Зависимость от качества данных о сущностях: Эффективность системы зависит от полноты и точности предварительно сгенерированных списков Candidate Strings и корректности идентификации сущностей и их доменов.

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

• Обеспечение распознавания сущности (Entity Recognition): Убедитесь, что Google четко идентифицирует ваш бренд как сущность и ассоциирует его с правильным доменом (Entity Identifier). Используйте микроразметку Schema.org, поддерживайте актуальность данных в Knowledge Graph и обеспечивайте последовательный брендинг.
• Стратегия для уникальных брендов: Если название вашего бренда уникально, этот механизм работает на вас, автоматически фокусируя смешанные запросы (тема + бренд) на вашем сайте. Критически важно иметь качественный контент на сайте по всем темам, связанным с брендом, так как выдача может быть ограничена только вашим доменом.
• Стратегия для брендов с общеупотребительными названиями: Если название вашего бренда неоднозначно (например, "Apple", "Time"), необходимо активно работать над Topical Authority и E-E-A-T. Так как по умолчанию Google выполняет широкий поиск, ваш сайт должен быть достаточно авторитетным, чтобы занять высокие позиции в конкурентной выдаче.
• Мониторинг интерпретации брендовых запросов: Регулярно проверяйте, как Google обрабатывает запросы с вашим брендом. Если Google предлагает ссылку "Искать только на сайте X", это значит, что он считает название общеупотребительным и выполняет широкий поиск по умолчанию.

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

• Выбор общеупотребительных слов в качестве названия бренда: Это создает проблему неоднозначности. Google будет предпочитать широкую интерпретацию запроса, что усложняет контроль над выдачей по брендовым запросам и требует больших усилий для ранжирования.
• Игнорирование неоднозначности бренда: Ошибочно предполагать, что Google всегда понимает, что пользователь ищет именно ваш бренд, если его название совпадает с общеупотребительными словами.
• Непоследовательное представление бренда: Частое изменение названия или использование множества разных вариантов написания может затруднить формирование корректного списка Candidate Strings и привести к ошибкам в распознавании интента.

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

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

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

Сценарий 1: Бренд с уникальным названием (Пример: "MSNBC")

1. Запрос пользователя: "выборы 2024 msnbc"
2. Действие Google: Система распознает "msnbc" как Entity Name и определяет, что это НЕ common word or phrase.
3. Переписывание: Запрос автоматически переписывается в "выборы 2024 source:msnbc" (или аналог site:msnbc.com).
4. Результат в SERP: Пользователь видит результаты ТОЛЬКО с сайта MSNBC. Отображается ссылка: "Искать 'выборы 2024 msnbc' во всех источниках".
5. Действие SEO: Для MSNBC важно обеспечить полноту освещения темы "выборы 2024" на своем сайте.

Сценарий 2: Бренд с общеупотребительным названием (Пример: "Time")

1. Запрос пользователя: "лучшие изобретения time"
2. Действие Google: Система распознает "time" как Entity Name (журнал), но определяет, что это ЯВЛЯЕТСЯ common word or phrase.
3. Переписывание: Запрос НЕ переписывается автоматически.
4. Результат в SERP: Пользователь видит смешанные результаты по запросу "лучшие изобретения time". Отображается ссылка: "Искать 'лучшие изобретения' только на сайте Time".
5. Действие SEO: Для Time.com важно ранжироваться в этой широкой выдаче на основе авторитетности, конкурируя с другими источниками.