Google использует адаптивную систему управления краулинговым бюджетом. Система прогнозирует вероятность успешного сканирования URL на основе скорости ответов сервера и приоритета запроса. Если пропускная способность ограничена, низкоприоритетные URL немедленно отклоняются (Early Rejection), не дожидаясь таймаута, чтобы обеспечить быстрое сканирование важного контента.

Описание

Какую проблему решает

Патент решает проблему управления очередью запросов на сканирование (backlog), когда общий спрос превышает доступную пропускную способность (crawl capacity) для конкретного хоста. Цель — обеспечить низкую задержку (low latency) для высокоприоритетных URL. Традиционные методы, основанные на таймаутах (удаление запроса из очереди по истечении времени), неэффективны, так как увеличивают среднюю задержку и не гарантируют своевременную обработку важных запросов при перегрузке.

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

Запатентована система для предиктивного управления бэклогом сканирования, которая использует механизм немедленного отклонения (early rejection) низкоприоритетных запросов. Система динамически рассчитывает адаптивный Порог Приоритета (Priority Threshold) на основе фактической пропускной способности сканирования (измеряемой через Average Response Interval) и истории запросов. Это позволяет системе адаптироваться к производительности сервера в реальном времени.

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

Механизм работает следующим образом:

  • Внутренние системы Google присваивают приоритет каждому запросу на сканирование.
  • Система непрерывно измеряет скорость поступления запросов (Average Request Interval) и скорость их обработки сервером (Average Response Interval).
  • Рассчитывается вероятность успешного выполнения нового запроса (Estimated Request Success Rate).
  • Если вероятность низкая (спрос превышает предложение), динамически повышается Priority Threshold.
  • Если приоритет нового запроса ниже порога, он немедленно отклоняется, не попадая в бэклог.
  • Бэклог сортируется по приоритету, обеспечивая обработку наиболее важных URL в первую очередь.

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

Высокая. Управление краулинговым бюджетом (Crawl Budget Management) остается критически важным аспектом технического SEO, особенно для крупных и динамических сайтов. Этот патент описывает фундаментальный инфраструктурный механизм того, как Google приоритизирует контент и адаптирует нагрузку к возможностям сервера в условиях ограниченных ресурсов.

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

Значительное влияние (8/10). Хотя патент является инфраструктурным и не описывает факторы ранжирования, он детально объясняет механику использования краулингового бюджета. Он устанавливает прямую математическую связь между производительностью сервера (временем ответа) и способностью Google сканировать менее приоритетные URL. Медленные ответы сервера напрямую приводят к увеличению числа отклоненных запросов на сканирование.

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

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

Average Request Interval (Средний интервал запросов)
Среднее время между поступлением новых запросов на сканирование. Показатель спроса. Используется как числитель при расчете вероятности успеха.
Average Response Interval (Средний интервал ответов)
Среднее время между получением результатов сканирования. Является индикатором фактической пропускной способности (throughput) сканирования для данного хоста. Зависит от скорости ответа сервера. Используется как знаменатель.
Backlog of Pending URL Crawls (Бэклог ожидающих сканирования URL)
Структура данных (например, очередь с приоритетами), содержащая URL, которые были приняты к сканированию, но еще не обработаны.
Crawl Capacity (Пропускная способность сканирования)
Ограничение на скорость сканирования для конкретного хоста, установленное для предотвращения его перегрузки.
Early Rejection / Early Fail (Раннее отклонение)
Механизм немедленного отклонения запроса на сканирование, если его приоритет ниже порога, вместо того чтобы добавлять его в очередь и ждать таймаута (maximum wait time).
Estimated Request Success Rate (Оценочная вероятность успеха запроса)
Прогнозная оценка того, какая доля запросов может быть удовлетворена. Рассчитывается как отношение Average Request Interval к Average Response Interval.
Failure Rate at Priority Threshold (Частота отказов на пороге приоритета)
Метрика, используемая для статистического отклонения части запросов, чей приоритет точно равен Priority Threshold.
Priority Threshold (Порог приоритета)
Динамически рассчитываемое значение приоритета. Запросы с приоритетом ниже этого порога немедленно отклоняются.
Record of Priorities (Запись приоритетов)
Структура данных, хранящая историю приоритетов N последних запросов (как принятых, так и отклоненных). Используется для расчета Priority Threshold.

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

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

  1. Система получает набор запросов на сканирование URL с присвоенными приоритетами.
  2. Запросы, проходящие Priority Threshold, помещаются в бэклог (backlog data structure), имеющий максимальное время ожидания (maximum wait time).
  3. Запросы, не проходящие Priority Threshold, отклоняются. Ключевое условие: отклонение происходит без выполнения сканирования И без ожидания в бэклоге до истечения maximum wait time (механизм Early Rejection).
  4. Priority Threshold корректируется на основе оценки вероятности того, что новые запросы будут удовлетворены.

Ядро изобретения — использование динамического порога для немедленного отклонения запросов вместо ожидания таймаута.

Claim 5 (Зависимый): Уточняет механизм хранения данных для расчета порога. Приоритеты сохраняются в Record of Priorities и используются для определения Priority Threshold, независимо от того, находятся ли сами запросы в бэклоге (т.е. они могли быть отклонены или уже выполнены).

Это означает, что приоритеты немедленно отклоненных (низкоприоритетных) запросов влияют на расчет порога для будущих запросов.

Claim 6 (Зависимый): Запросы в бэклоге сортируются по приоритету для определения того, какой URL будет сканироваться следующим.

Claim 7 (Зависимый от 1): Определяет факторы вероятности успеха. Вероятность выше, если интервал между запросами больше (меньше нагрузка) и если пропускная способность (throughput) выше (быстрее обработка).

Claim 8 (Зависимый от 1): Описывает поведение при высокой вероятности успеха. Если вероятность успеха высокая (в патенте упоминается пример 90%), Priority Threshold ослабляется (например, до 0), так что новые запросы не отклоняются. Это гарантирует стремление системы использовать всю доступную Crawl Capacity.

Claim 9 (Зависимый от 1): Описывает обработку пограничных случаев. Запросы с приоритетом, равным Priority Threshold, отклоняются с определенной частотой (Failure Rate).

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

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

CRAWLING – Сканирование и Сбор данных

Система реализована в компоненте URL Crawler and Backlog Manager и напрямую управляет процессами:

  • Планирование сканирования (Crawl Scheduling): Определяет порядок сканирования путем сортировки бэклога по приоритету.
  • Управление бюджетом сканирования (Crawl Budget Management): Оптимизирует использование ограниченной емкости хоста, активно отклоняя низкоприоритетные запросы при перегрузке или медленной работе сервера.

Взаимодействие с компонентами:

  • Applications: Внутренние системы Google (Web Search, News, Images), которые генерируют запросы и присваивают им приоритеты.
  • Network/Host: Взаимодействие с целевым хостом (сервером сайта) определяет фактическую пропускную способность (Average Response Interval).

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

  • URL и его присвоенный приоритет.
  • Временные метки поступления запросов.
  • Временные метки завершения сканирований (отражающие время ответа сервера).

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

  • Решение о немедленном отклонении запроса ИЛИ добавление URL в Backlog.
  • Скорректированный Priority Threshold.

На что влияет

  • Технические аспекты и производительность сайта: Влияние критично. Скорость ответа сервера напрямую определяет Average Response Interval. Чем медленнее сервер, тем ниже пропускная способность, тем выше становится Priority Threshold, и тем больше низкоприоритетных URL отклоняется.
  • Крупные сайты: Наибольшее влияние на сайты (e-commerce, новостные порталы), где спрос на сканирование часто превышает доступную емкость, вынуждая систему приоритизировать.
  • Скорость и полнота индексации: Механизм обеспечивает низкую задержку для высокоприоритетного контента, но может привести к игнорированию низкоприоритетных страниц, если емкость постоянно ограничена.

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

Алгоритм применяется непрерывно при обработке запросов на сканирование для конкретного хоста.

  • Условие активации отклонений: Механизм отклонения (Priority Threshold > 0) активируется, когда расчетная вероятность успеха запроса (Estimated Request Success Rate) падает ниже определенного уровня (например, ниже 0.9 или 90%). Это происходит, когда спрос превышает предложение (т.е. система перегружена или сервер медленный).
  • Частота корректировки: Интервалы рассчитываются постоянно (используются скользящие средние), а Priority Threshold обновляется периодически (например, раз в минуту) или по событию.

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

Процесс А: Обработка нового запроса на сканирование

  1. Получение запроса: Система получает URL и его приоритет.
  2. Обновление статистики запросов: Приоритет добавляется в Record of Priorities. Обновляется скользящее среднее Average Request Interval.
  3. Сравнение с порогом: Приоритет сравнивается с текущим Priority Threshold.
  4. Принятие или Отклонение:
    • Выше порога: Запрос добавляется в Backlog.
    • Ниже порога: Запрос немедленно отклоняется (Early Rejection).
    • Равен порогу: Применяется дополнительное тестирование с использованием Failure Rate at Priority Threshold для принятия или отклонения.

Процесс Б: Выполнение сканирования и обновление статистики ответов (Параллельный процесс)

  1. Выборка: Система извлекает запрос с наивысшим приоритетом из Backlog.
  2. Сканирование и получение результата: URL Crawler выполняет сканирование.
  3. Обновление статистики ответов: Обновляется скользящее среднее Average Response Interval на основе времени завершения сканирования.

Процесс В: Корректировка порога приоритета (Периодический процесс)

  1. Расчет вероятности успеха: Вычисляется Estimated Request Success Rate (ESR).

Выводы

  1. Прямая зависимость краулинга от скорости сервера: Патент математически доказывает, что скорость ответа сервера (влияющая на Average Response Interval) является ключевым фактором, определяющим объем сканирования. Ухудшение производительности сервера приводит к снижению Estimated Request Success Rate и повышению Priority Threshold.
  2. Приоритет критичен при ограниченном бюджете: Когда спрос на сканирование превышает возможности сервера (например, Success Rate < 0.9), система переходит в режим жесткой приоритизации. Только URL с приоритетом выше динамического порога попадают в очередь.
  3. Раннее отклонение (Early Rejection) вместо таймаутов: Google предпочитает немедленно отклонять запросы, которые вряд ли будут выполнены, вместо того чтобы держать их в очереди. Это гарантирует низкую задержку (low latency) для принятых высокоприоритетных запросов.
  4. Динамическая и адаптивная система: Priority Threshold не является фиксированным. Он постоянно адаптируется к текущей нагрузке и производительности сервера с использованием скользящих средних.
  5. Стремление к полному использованию бюджета: Система спроектирована так, чтобы использовать всю доступную пропускную способность. Отклонение запросов начинается только тогда, когда это необходимо для поддержания качества обслуживания (Claim 8).
  6. Влияние истории запросов: Приоритеты всех запросов, включая отклоненные, сохраняются в Record of Priorities и влияют на расчет порога для будущих запросов (Claim 5).

Практика

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

  • Агрессивная оптимизация времени ответа сервера (TTFB): Это ключевая рекомендация, вытекающая из патента. Поскольку Average Response Interval является знаменателем в расчете вероятности успеха, уменьшение времени ответа напрямую увеличивает пропускную способность и снижает Priority Threshold, позволяя сканировать больше URL.
  • Мониторинг статистики сканирования: Отслеживайте время ответа сервера в логах и Google Search Console. Всплески времени ответа приведут к активации механизма Early Rejection для низкоприоритетных URL.
  • Поддержание стабильной производительности: Система использует скользящие средние, поэтому важна не только скорость, но и стабильность ответов сервера. Резкие колебания производительности негативно сказываются на расчете Average Response Interval.
  • Повышение приоритета важного контента: Хотя SEO-специалисты не могут напрямую устанавливать приоритеты, патент упоминает популярность и свежесть как факторы приоритета. Используйте сильную внутреннюю перелинковку, актуальные Sitemaps (lastmod) и, при необходимости, Indexing API, чтобы максимизировать шансы на высокий приоритет сканирования для ключевых страниц.

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

  • Игнорирование проблем с производительностью сервера: Рассчитывать на то, что Google «в конце концов просканирует всё», неверно. Если сервер медленный, система математически рассчитает высокий Priority Threshold и активно отклонит запросы на сканирование.
  • Блокировка или искусственное замедление краулеров (Throttling): Ограничение скорости сканирования на стороне сервера приведет к увеличению Average Response Interval и, как следствие, к повышению Priority Threshold и отклонению URL.
  • Генерация большого количества низкоприоритетных URL: Создание массы мусорных страниц (например, неоптимизированные фасеты) увеличивает спрос на сканирование. При ограниченной емкости эти URL будут первыми кандидатами на Early Rejection.
  • Размещение важного контента на медленных хостах: Система управляет бэклогом на уровне хоста (host-level). Если важный контент находится на хосте с низкой пропускной способностью, он будет конкурировать за ограниченный ресурс.

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

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

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

Сценарий: Крупный E-commerce сайт во время распродажи

  1. Ситуация: Нагрузка на сервер возрастает из-за наплыва пользователей, время ответа увеличивается.
  2. Реакция системы (Google): Average Response Interval увеличивается. Estimated Request Success Rate падает ниже порога (например, 0.9).
  3. Активация механизма: Система динамически повышает Priority Threshold, чтобы соответствовать снизившейся пропускной способности.
  4. Последствия: Google продолжает сканировать высокоприоритетные URL (например, главную страницу, основные категории, популярные товары), но начинает немедленно отклонять (Early Rejection) запросы на сканирование низкоприоритетных URL (например, старые товары, глубокие страницы пагинации, страницы фильтров).
  5. Результат: Важный контент обновляется с низкой задержкой, но общая полнота сканирования сайта снижается до тех пор, пока производительность сервера не восстановится.

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

Как этот патент связан с краулинговым бюджетом (Crawl Budget)?

Патент описывает конкретный механизм управления краулинговым бюджетом на практике. Он показывает, как Google динамически регулирует количество принимаемых запросов на сканирование (Crawl Demand) в зависимости от доступной пропускной способности хоста (Crawl Capacity). Если сервер не справляется или система перегружена, Google активно сокращает количество сканируемых URL, отдавая предпочтение высокоприоритетным.

Как скорость ответа сервера (TTFB) влияет на этот механизм?

Влияние прямое и критическое. Время ответа сервера определяет метрику Average Response Interval. Чем выше это значение (медленнее сервер), тем ниже расчетная вероятность успеха сканирования (Estimated Request Success Rate). Это, в свою очередь, приводит к повышению Priority Threshold и отклонению большего количества URL.

Могу ли я повлиять на приоритет (Priority) моих URL?

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

Что происходит, если мой сервер очень быстрый и система Google не перегружена?

В этом случае Average Response Interval будет низким. Если Estimated Request Success Rate превысит пороговое значение (например, 90%), система установит Priority Threshold в ноль (Claim 8). Это означает, что все запросы на сканирование будут приниматься в очередь, и Google будет стремиться максимально использовать доступную пропускную способность.

Что означает «Раннее отклонение» (Early Rejection) и почему это важно?

Early Rejection означает, что система немедленно отклоняет запрос, если его приоритет ниже порога, вместо того чтобы добавлять его в очередь и ждать таймаута. Это важно, так как позволяет Google поддерживать низкую задержку (low latency) для принятых высокоприоритетных запросов, не засоряя очередь запросами, которые вряд ли будут выполнены.

Применяется ли этот механизм к каждому сайту?

Механизм управления бэклогом применяется на уровне хоста (host-level). Логика работает для всех хостов, но активация режима отклонения запросов (когда Priority Threshold > 0) происходит только тогда, когда спрос на сканирование превышает доступную емкость. Для небольших сайтов с хорошим хостингом емкость почти всегда достаточна.

Что такое Record of Priorities и почему он хранит отклоненные запросы?

Это история приоритетов недавних запросов. Она используется для определения статистического распределения приоритетов. Хранение приоритетов отклоненных запросов необходимо для корректного расчета Priority Threshold. Если бы учитывались только принятые (высокоприоритетные) запросы, система не смогла бы точно определить, где следует провести границу отсечения для адаптации к текущей нагрузке.

Как система реагирует на внезапное замедление сервера?

Система использует скользящие средние для Average Response Interval. При внезапном замедлении эта метрика начнет расти. Система периодически пересчитывает Priority Threshold. Как только порог будет обновлен на основе новых данных о производительности, система начнет более агрессивно отклонять низкоприоритетные запросы.

Что происходит с URL, которые были отклонены механизмом Early Rejection?

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

Как обрабатываются запросы с одинаковым приоритетом?

Если приоритеты равны и находятся в бэклоге, порядок может быть FIFO. Если приоритет равен Priority Threshold, система использует метрику Failure Rate at Priority Threshold, чтобы статистически решить, принять или отклонить запрос, обеспечивая справедливое распределение оставшейся емкости (Claim 9).

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

Как Google динамически приоритизирует сканирование страниц, когда Googlebot отстает от графика
Google использует адаптивную систему управления сканированием. Если краулер не успевает обработать все запланированные URL (отстает от графика), система динамически меняет приоритеты. Вместо хронологического порядка приоритет отдается наиболее важным страницам (на основе Importance Rank/PageRank), чтобы гарантировать свежесть индекса для ключевого контента, даже если другие страницы дольше ждут своей очереди.
  • US8666964B1
  • 2014-03-04

  • Краулинг

  • Свежесть контента

  • Индексация

Как Google оптимизирует краулинговый бюджет, динамически изменяя частоту сканирования на основе популярности, значимых изменений контента и ошибок сервера
Google использует систему планирования сканирования для оптимизации ресурсов. Система динамически рассчитывает интервал сканирования для каждого ресурса, учитывая его популярность (например, количество подписчиков), частоту «значимых» изменений контента (особенно в визуально важных блоках) и состояние доступности (ошибки сервера). Это позволяет чаще сканировать важный и обновляемый контент и сокращать ресурсы на неизменный или недоступный контент.
  • US8868541B2
  • 2014-10-21

  • Краулинг

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

  • Индексация

Как Google адаптивно управляет краулинговым бюджетом и скоростью сканирования на основе производительности сервера
Google использует распределенную систему управления сканированием, которая группирует URL по хостам и определяет оптимальное время следующего обращения к серверу («Stall Time»). Эта система адаптивно регулирует частоту запросов на основе фактической скорости ответа сервера («Retrieval Time»), чтобы эффективно сканировать интернет, не перегружая отдельные сайты.
  • US7305610B1
  • 2007-12-04

  • Краулинг

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

Как Google определяет частоту и приоритет сканирования страниц на основе PageRank, частоты обновления контента и времени с последнего визита
Google использует автоматизированную систему планирования для оптимизации ресурсов сканирования. Для каждого URL рассчитываются оценки приоритета (Scores) на основе его важности (PageRank), исторической частоты изменения контента (Content Change Frequency) и времени, прошедшего с момента последнего сканирования (Age). Это определяет, будет ли страница сохранена в индексе, как часто она будет сканироваться (ежедневно, в реальном времени или редко) и нужно ли загружать ее заново.
  • US7725452B1
  • 2010-05-25

  • Краулинг

  • Индексация

  • Свежесть контента

Как Google приоритизирует сканирование, управляет краулинговым бюджетом и повторно использует контент
Google использует распределенную систему планирования для оптимизации сканирования. Приоритет URL определяется их важностью (Page Importance/PageRank) и специальными коэффициентами (Boost Factor). Система фильтрует постоянно недоступные страницы и решает, загружать ли контент заново или использовать кэшированную версию (Reuse), основываясь на истории изменений и важности страницы.
  • US8042112B1
  • 2011-10-18

  • Краулинг

  • Свежесть контента

  • Индексация

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

Как Google использует исторические данные о кликах по Сущностям для ранжирования нового или редко посещаемого контента
Google решает проблему «холодного старта» для новых страниц, у которых нет собственных поведенческих данных. Система агрегирует историю кликов на уровне Сущностей (Entities). Если сущности, упомянутые на новой странице, исторически имеют высокий CTR по целевому запросу, страница получает бустинг в ранжировании, наследуя поведенческие сигналы через эти сущности.
  • US10303684B1
  • 2019-05-28

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

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

  • SERP

Как Google рассчитывает тематическую популярность (Topical Authority) документов на основе поведения пользователей
Google использует данные о посещаемости и навигации пользователей для расчета популярности документов. Система классифицирует документы и запросы по темам, а затем вычисляет популярность документа внутри каждой конкретной темы (Per-Topic Popularity). Эта метрика используется как сигнал ранжирования, когда тема запроса пользователя соответствует теме документа.
  • US8595225B1
  • 2013-11-26

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

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

  • SERP

Как Google использует анализ многословных фраз для улучшения подбора синонимов с учетом грамматического согласования
Google анализирует, как пользователи одновременно меняют несколько слов в запросе (например, при изменении числа или рода). Подтверждая, что каждое измененное слово является лексическим или семантическим вариантом оригинала, Google идентифицирует «синонимы с N-граммным согласованием». Это позволяет системе улучшить понимание синонимов отдельных слов, даже если эти слова редко меняются поодиночке в определенных контекстах.
  • US7925498B1
  • 2011-04-12

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

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

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

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

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

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

Как Google динамически регулирует влияние фактора близости в локальном поиске в зависимости от тематики запроса и региона
Google использует систему для определения того, насколько важна близость (расстояние) для конкретного поискового запроса и региона. Анализируя исторические данные о кликах и запросах маршрутов, система вычисляет «Фактор важности расстояния». Для запросов типа «Кофе» близость критична, и удаленные результаты пессимизируются. Для запросов типа «Аэропорт» близость менее важна, и качественные результаты могут ранжироваться высоко. Система также учитывает плотность региона (город или село), адаптируя ожидания пользователей по расстоянию.
  • US8463772B1
  • 2013-06-11

  • Local SEO

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

Как Google идентифицирует экспертов на основе их активности и позволяет фильтровать выдачу по их контенту
Google использует систему для идентификации людей (членов социальной сети), тесно связанных с темой запроса, на основе их активности (посты, взаимодействия, репосты) и квалификации. Система отображает этих людей в специальных блоках (Display Areas) рядом с результатами поиска, позволяя пользователям просматривать их профили или фильтровать выдачу, чтобы увидеть только контент, созданный, одобренный или прокомментированный этими экспертами.
  • US9244985B1
  • 2016-01-26

  • EEAT и качество

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

  • SERP

Как Google переносит вес поведенческих сигналов (кликов) между связанными запросами для улучшения ранжирования
Google улучшает ранжирование по редким или новым запросам, для которых недостаточно собственных данных, используя поведенческие сигналы (Clickthrough Data) из связанных запросов. Если пользователи часто вводят запросы последовательно, система идентифицирует связь и переносит данные о кликах с одного запроса на другой, позволяя документам с высоким engagement ранжироваться выше по всему кластеру.
  • US7505964B2
  • 2009-03-17

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

  • SERP

Как Google предсказывает намерения пользователя и выполняет поиск до ввода запроса (Predictive Search)
Google использует механизм для прогнозирования тем, интересующих пользователя в конкретный момент времени, основываясь на его истории и контексте. При обнаружении сигнала о намерении начать поиск (например, открытие страницы поиска), система проактивно выполняет запрос по предсказанной теме и мгновенно показывает результаты или перенаправляет пользователя на релевантный ресурс.
  • US8510285B1
  • 2013-08-13

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

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

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

Как Google использует историю физических перемещений пользователя для фильтрации и персонализации результатов поиска
Google может собирать и хранить историю физических перемещений пользователя (Location History). Патент описывает интерфейс, позволяющий пользователю осознанно включать свои прошлые местоположения (например, «места, где я был на прошлой неделе») в качестве фильтра для нового поискового запроса, чтобы сделать результаты более релевантными личному опыту.
  • US8874594B2
  • 2014-10-28

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

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

  • Local SEO

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

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

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

  • Local SEO