Google использует систему для эффективного сканирования контента мобильных приложений (App Indexing). Вместо фиксированных таймаутов система отслеживает жизненный цикл активности, потребление памяти и сетевые запросы приложения в эмуляторе. Когда эти показатели стабилизируются, Google определяет, что приложение загружено, и начинает сканирование контента.

Описание

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

Патент решает проблему неэффективности и неточности при сканировании контента нативных мобильных приложений (native applications). Основная сложность заключается в определении момента, когда приложение полностью загрузило и отобразило контент, соответствующий определенной глубинной ссылке (deep link).

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

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

Запатентована система и метод для определения момента, когда экземпляр нативного приложения (native application instance) достаточно инстанцирован (загружен) для проведения операции сканирования. Система запускает приложение в эмуляторе и отслеживает различные технические сигналы: события жизненного цикла активности (Activity lifecycle events) и изменения в потреблении памяти (Memory footprint). Когда эти сигналы стабилизируются, система генерирует сигнал загрузки (load signal), разрешающий сканирование.

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

Система работает в эмулируемой среде (OS Emulator):

  1. Инстанцирование: Система запускает приложение, используя deep link.
  2. Мониторинг: Одновременно отслеживаются несколько составных сигналов (constituent load signals):
    • Activity lifecycle events: Система ждет периода "тишины", когда новые события (например, переходы между состояниями) перестают происходить.
    • Memory footprint: Система отслеживает объем используемой памяти. Когда потребление перестает расти (стабилизируется), это считается признаком завершения загрузки.
    • Requests for content (Опционально): Отслеживание сетевых запросов к внешним серверам до их полного выполнения.
  3. Детектирование загрузки: Когда все отслеживаемые параметры стабилизировались, система генерирует итоговый load signal.
  4. Сканирование: Получив load signal, краулер (Data Extractor) приступает к извлечению контента из загруженного приложения.

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

Средняя. Патент напрямую связан с инициативами Google по индексации приложений (App Indexing, позже Firebase App Indexing). Хотя в последние годы фокус частично сместился в сторону веб-технологий и PWA, индексация контента внутри нативных приложений остается частью поисковой экосистемы, особенно на платформе Android. Описанные технические методы эффективного определения момента загрузки актуальны для систем, занимающихся рендерингом и сканированием динамического контента.

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

Влияние на традиционное веб-SEO низкое (2/10), так как патент касается исключительно нативных приложений. Однако для App SEO (App Indexing) влияние среднее (4/10).

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

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

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

Activity lifecycle event (Событие жизненного цикла активности)
Событие, описывающее переход между различными состояниями в жизненном цикле приложения. Примеры включают вызовы методов типа OnCreate(), OnStart(), OnResume(), OnPause(). Используется как индикатор активности приложения.
Constituent load signal (Составной сигнал загрузки)
Промежуточный сигнал, генерируемый одним из модулей мониторинга (например, сигнал о стабилизации памяти или сигнал о завершении запросов). Эти сигналы используются для принятия решения о генерации итогового Load signal.
Deep link (Глубинная ссылка)
Инструкция (например, URI), указывающая на конкретный Environment instance внутри нативного приложения и сконфигурированная для запуска этого экземпляра при активации.
Environment instance (Экземпляр среды)
Конкретный экран, состояние или отображаемая среда внутри нативного приложения, в которой представлен контент (текст, изображения и т.д.).
Load signal (Сигнал загрузки)
Итоговый сигнал, указывающий, что приложение достаточно инстанцировано (загружено) и готово к сканированию.
Memory footprint (Потребление памяти)
Объем оперативной памяти, используемый экземпляром приложения в определенный момент времени. Может определяться, например, размером кучи (heap size).
Native application (Нативное приложение)
Приложение, разработанное специально для выполнения на определенной операционной системе (например, Android, iOS) и работающее независимо от браузера.
OS Emulator (Эмулятор ОС)
Среда, используемая поисковой системой для эмуляции операционной системы, в которой запускаются, отслеживаются и сканируются нативные приложения.

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

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

  1. Инстанцирование нативного приложения.
  2. В ответ на инстанцирование выполняется:
    • Мониторинг событий жизненного цикла активности (activity lifecycle events).
    • Мониторинг изменений в потреблении памяти (memory footprint). Этот процесс включает:
      • Определение первого значения потребления памяти в момент T1.
      • Определение второго значения потребления памяти в момент T2 (позже T1).
      • Определение, превышает ли потребление в T2 потребление в T1.
      • Если НЕ превышает (т.е. память стабилизировалась), генерируется составной сигнал загрузки памяти (memory footprint load signal).
  3. Генерация итогового сигнала загрузки (load signal), когда мониторинг жизненного цикла и мониторинг памяти указывают на достаточную инстанциацию для сканирования.

Claim 2 (Зависимый от 1): Уточняет механизм мониторинга жизненного цикла.

  1. Определение, произошло ли событие жизненного цикла в течение определенного периода мониторинга (lifecycle monitoring time period).
  2. Если событие НЕ произошло в течение этого периода (т.е. активность прекратилась), генерируется составной сигнал загрузки жизненного цикла (activity lifecycle load signal).

Claim 3 (Зависимый от 2): Устанавливает строгое условие для генерации итогового сигнала. Load signal генерируется только в том случае, если были сгенерированы ОБА составных сигнала: activity lifecycle load signal И memory footprint load signal (Логическое И).

Claim 4 (Зависимый от 2): Добавляет третий компонент мониторинга к процессу.

  1. Мониторинг запросов контента (requests for content), отправляемых приложением к внешним обслуживающим сущностям.
  2. Определение, был ли выполнен (fulfilled) каждый отслеживаемый запрос.
  3. Если все запросы выполнены, генерируется составной сигнал загрузки запросов (request load signal).

Claim 5 (Зависимый от 4): Устанавливает еще более строгое условие. Итоговый Load signal генерируется только в том случае, если были сгенерированы ВСЕ ТРИ составных сигнала: жизненного цикла, памяти и запросов.

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

Изобретение является частью инфраструктуры Google для индексации мобильных приложений (App Indexing).

CRAWLING – Сканирование и Сбор данных
Это основной этап применения патента. Механизм используется для оптимизации процесса сканирования нативных приложений. Весь процесс происходит внутри компонента OS Emulator, когда система обрабатывает очередь Deep Links для индексации. Система должна определить оптимальный момент для извлечения данных из запущенного приложения.

INDEXING – Индексирование и извлечение признаков
Механизм напрямую влияет на этот этап, определяя момент, когда данные в приложении готовы (загружены и отрисованы) для извлечения краулером (Data Extractor) и последующей передачи в индексатор (Indexer).

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

  • Deep link, указывающий на контент в приложении.
  • Само нативное приложение (например, установочный файл).

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

  • Load signal (внутренний триггер для начала сканирования).
  • Извлеченный контент из загруженного экземпляра приложения.

На что влияет

  • Конкретные типы контента: Влияет исключительно на контент, расположенный внутри нативных мобильных приложений (Android/iOS) и доступный через Deep Links. Патент не оказывает влияния на сканирование и ранжирование веб-контента, PWA или ресурсов, отображаемых через браузер.

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

  • Условия работы алгоритма: Алгоритм применяется каждый раз, когда поисковая система пытается просканировать или обновить контент нативного приложения по Deep Link для целей App Indexing.
  • Триггеры активации: Запуск приложения в OS Emulator активирует систему мониторинга. Триггером для завершения мониторинга и начала сканирования является стабилизация всех отслеживаемых параметров (память, активность, сетевые запросы).

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

Процесс определения готовности приложения к сканированию.

  1. Инстанцирование приложения: Система получает Deep Link и запускает соответствующий экземпляр нативного приложения в OS Emulator. (В патенте, Claim 8, упоминается возможность использования начального таймаута запуска (launch timeout) перед началом мониторинга).
  2. Инициализация мониторинга: Активируются модули мониторинга: Request Monitor, Activity Monitor и Memory Monitor. Мониторинг может происходить параллельно.
  3. Мониторинг запросов (Процесс A):
    • Отслеживаются все исходящие запросы контента к внешним серверам.
    • Для каждого запроса определяется статус выполнения (получен ответ, ошибка или истек таймаут).
    • Когда все запросы завершены, генерируется request load signal.
  4. Мониторинг активности (Процесс B):
    • Отслеживаются Activity lifecycle events.
    • Система ожидает наступления периода "тишины".
    • Если в течение заданного периода времени (lifecycle monitoring time period) не происходит новых событий, генерируется activity lifecycle load signal.
  5. Мониторинг памяти (Процесс C):
    • Производится замер Memory footprint в момент T1.
    • Производится повторный замер Memory footprint в момент T2 (через определенный интервал).
    • Значения T2 и T1 сравниваются. Если потребление памяти не увеличилось (

Выводы

  1. Инфраструктурный фокус: Патент является сугубо техническим и описывает внутреннюю инфраструктуру Google для сканирования нативных приложений (App Indexing). Он не содержит информации о факторах ранжирования и не дает прямых рекомендаций для веб-SEO.
  2. Оптимизация сканирования: Основная цель изобретения — повышение эффективности сканирования за счет отказа от фиксированных таймаутов в пользу динамического определения момента загрузки. Это экономит ресурсы и повышает полноту индексации.
  3. Стабильность как индикатор готовности: Система интерпретирует стабильность состояния приложения как признак завершения загрузки и отрисовки контента. Стабильность определяется как комбинация факторов: отсутствие изменений в жизненном цикле, стабильное потребление памяти и (опционально) завершение сетевой активности.
  4. Использование эмуляции: Патент подтверждает использование эмулируемой среды (OS Emulator) для запуска, анализа и сканирования приложений в контролируемых условиях.
  5. Технические требования для App Indexing: Для успешной индексации контента приложение должно корректно, быстро и стабильно загружаться в среде эмуляции Google. Проблемы с производительностью или стабильностью (например, утечки памяти) могут препятствовать индексации.

Практика

ВАЖНО: Описанный патент касается исключительно индексации нативных мобильных приложений (App Indexing), а не веб-поиска. Рекомендации ниже применимы для SEO-специалистов и разработчиков, занимающихся продвижением мобильных приложений.

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

  • Обеспечение эффективной и чистой загрузки: Приложения должны быть оптимизированы так, чтобы быстро загружать контент по Deep Link и достигать стабильного состояния. Длительные фоновые процессы, не связанные с отображением основного контента, могут задерживать генерацию Load signal.
  • Тестирование в эмуляторах и профилирование: Необходимо тестировать отображение контента по Deep Links в стандартных эмуляторах (например, Android Studio Emulator). Используйте инструменты профилирования для отслеживания Memory footprint и Activity lifecycle, чтобы убедиться, что приложение достигает стабильности после загрузки.
  • Управление жизненным циклом: Убедитесь, что после завершения загрузки и отрисовки основного контента приложение переходит в стабильное состояние ожидания и не генерирует постоянных или циклических событий активности без взаимодействия с пользователем.
  • Оптимизация сетевых запросов: Обеспечьте быструю загрузку данных с сервера. Долгие или зависающие запросы задерживают индексацию.

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

  • Бесконечная подгрузка контента без стабилизации: Если приложение непрерывно подгружает второстепенный контент, рекламу или выполняет фоновые задачи сразу после запуска, генерируя сетевую активность и потребляя память, система может не дождаться стабилизации и прервать сессию сканирования.
  • Утечки памяти (Memory Leaks): Приложения с утечками памяти будут демонстрировать постоянно растущий Memory footprint. Это заблокирует генерацию memory footprint load signal и, как следствие, предотвратит сканирование контента.
  • Игнорирование производительности в эмуляторе: Если приложение падает, зависает или работает некорректно при запуске в эмулируемой среде (например, из-за зависимости от специфических аппаратных функций, отсутствующих в эмуляторе), оно не будет проиндексировано.

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

Патент подчеркивает важность технического качества, производительности и стабильности нативных приложений для их успешной индексации Google. Он демонстрирует, что Google применяет к сканированию приложений схожие принципы, что и к рендерингу сложных веб-страниц: система должна динамически определить момент полной загрузки контента, прежде чем его анализировать. Для App SEO техническая оптимизация приложения является фундаментом.

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

Сценарий: Оптимизация индексации карточки товара в приложении E-commerce

  1. Задача: Убедиться, что контент карточки товара (описание, цена, фото) успешно индексируется Google через Deep Link.
  2. Анализ (Действия разработчика): Разработчик запускает карточку товара по Deep Link в Android Studio Emulator и использует Android Profiler. Он замечает, что после загрузки основного контента блок "Рекомендованные товары" продолжает обновляться в циклическом режиме, вызывая сетевые запросы и изменяя потребление памяти.
  3. Оптимизация: Разработчик изменяет логику: блок рекомендаций загружается один раз при открытии экрана и не обновляется автоматически.
  4. Результат: После загрузки основного контента и рекомендаций приложение достигает стабильного состояния (память стабильна, сетевые запросы завершены, нет лишних событий жизненного цикла). Система Google успешно детектирует момент загрузки и индексирует контент карточки товара.

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

Касается ли этот патент сканирования веб-сайтов или SPA?

Нет, патент явно описывает мониторинг загрузки native application instance (нативных приложений), которые работают независимо от браузера. Хотя общие принципы определения момента загрузки (ожидание стабилизации активности) могут быть концептуально схожи с тем, как Googlebot рендерит JavaScript на веб-страницах, описанные механизмы (Activity lifecycle events, OS Emulator) специфичны для мобильных ОС типа Android или iOS.

Что такое "Событие жизненного цикла активности" (Activity lifecycle event)?

Это технический термин, относящийся к разработке мобильных приложений. Когда приложение работает, оно переходит между разными состояниями (например, запуск, работа на переднем плане, пауза, остановка). Activity lifecycle events — это события или вызовы функций (например, OnCreate, OnResume, OnPause в Android), которые сигнализируют об этих переходах. Google отслеживает эти события, чтобы понять, активно ли приложение загружает контент или уже находится в состоянии покоя.

Как Google определяет, что память стабилизировалась?

Система производит два замера потребления памяти (Memory footprint) с небольшим интервалом (T1 и T2). Если объем потребляемой памяти в момент T2 не превышает объем в момент T1, система считает, что память стабилизировалась. Если же память продолжает расти, это указывает на продолжающуюся загрузку данных или на утечку памяти.

Что произойдет, если мое приложение имеет утечку памяти?

При утечке памяти потребление Memory footprint будет постоянно расти. В этом случае система мониторинга памяти никогда не сгенерирует составной сигнал о стабилизации (memory footprint load signal). Поскольку патент указывает, что для начала сканирования часто требуются все составные сигналы (Claims 3, 5), утечка памяти может полностью заблокировать индексацию контента вашего приложения.

Влияет ли скорость загрузки приложения на его ранжирование?

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

Как система обрабатывает приложения с фоновой активностью, например, мессенджеры или плееры?

Патент не дает конкретных деталей по типам приложений. Однако механизм ориентирован на стабилизацию. Если приложение после запуска по Deep Link продолжает активную фоновую работу (постоянные сетевые запросы, изменение памяти), система может испытывать трудности с определением момента готовности. Разработчикам следует стремиться к тому, чтобы отображение контента по Deep Link было приоритетным и стабильным.

Должен ли я беспокоиться об этом патенте, если я занимаюсь только веб-SEO?

Нет. Если вы не занимаетесь индексацией и продвижением контента внутри нативных мобильных приложений (App Indexing / Firebase App Indexing), этот патент не имеет прямого отношения к вашей работе. Он полезен для понимания общей инфраструктуры Google, но не влияет на веб-поиск.

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

Лучший способ — использовать стандартные инструменты разработки, такие как Android Studio. Запустите приложение в эмуляторе и используйте Android Profiler для мониторинга сетевой активности, жизненного цикла (Activity lifecycle) и потребления памяти (Memory usage). Убедитесь, что после загрузки контента все три показателя стабилизируются.

Требует ли система стабилизации всех трех параметров (память, активность, сеть)?

В патенте описаны разные варианты реализации. В наиболее строгих вариантах (Claims 3 и 5) требуется стабилизация всех отслеживаемых параметров (логическое И). В других вариантах может использоваться система голосования (большинство параметров стабильны) или определенная последовательность (например, память проверяется только после стабилизации активности).

Что происходит, если сетевой запрос приложения завершается ошибкой?

Патент упоминает, что запрос считается выполненным (fulfilled), если получен ответ или истек таймаут. В некоторых реализациях ошибка или неполный ответ все равно считаются выполнением запроса, позволяя проиндексировать приложение по принципу "best efforts" (с наилучшими возможными результатами). В других реализациях ошибка может блокировать индексацию, чтобы гарантировать качество.

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

Как Google определяет момент полной загрузки нативного приложения для его сканирования и индексации (App Indexing)
Google использует механизм для точного определения момента, когда нативное мобильное приложение полностью загрузило и отобразило контент. Система последовательно отслеживает завершение всех внешних сетевых запросов и состояние бездействия (idle) внутренних потоков приложения. Это гарантирует, что сканирование контента (App Indexing) начинается только тогда, когда экран приложения полностью сформирован.
  • US9513961B1
  • 2016-12-06

  • Индексация

  • Краулинг

Как Google сканирует, индексирует и ранжирует контент внутри мобильных приложений для показа в поиске (App Indexing)
Google использует виртуальные машины для эмуляции мобильных операционных систем (например, Android). В этой среде запускаются нативные приложения, и система извлекает текст, изображения и структуру непосредственно из процесса рендеринга контента. Это позволяет индексировать внутренние страницы приложений и показывать их в результатах поиска вместе с веб-страницами, реализуя механизм Deep Linking.
  • US9002821B2
  • 2015-04-07

  • Индексация

  • Краулинг

  • SERP

Как Google индексирует контент внутри мобильных приложений и формирует сниппеты для App Deep Linking
Google использует виртуальную машину для запуска и рендеринга нативных мобильных приложений с целью извлечения контента, отображаемого на экранах (Application Pages). Система также анализирует установочный пакет приложения (Application Package File) для извлечения иконки и отображаемого имени. Эти данные объединяются для создания информативных результатов поиска (Deep Links), ведущих непосредственно на конкретный контент внутри приложения.
  • US9881095B2
  • 2018-01-30

  • Индексация

  • SERP

Как Google автоматически обнаруживает и индексирует контент внутри мобильных приложений для показа в поиске (App Indexing)
Google использует систему для индексации контента нативных мобильных приложений. Для приложений, связанных с веб-сайтами, система проверяет аффилиацию и использует существующие веб-URL для доступа к контенту приложения. Для приложений с кастомными URI система эмулирует работу приложения и итеративно обнаруживает внутренние ссылки. Это позволяет контенту из приложений появляться в результатах поиска в виде глубоких ссылок.
  • US10073911B2
  • 2018-09-11

  • Индексация

  • Краулинг

  • Ссылки

Как Google проверяет работоспособность Deep Links и обратную совместимость перед индексированием контента мобильных приложений
Google использует автоматизированную систему верификации для индексирования контента мобильных приложений. Перед добавлением в индекс система эмулирует запуск приложения по Deep Link, проверяя корректность загрузки, отсутствие ошибок и соответствие контента связанной веб-странице. Также система тестирует обратную совместимость ссылок при обновлениях приложения, гарантируя, что в поиск попадают только функциональные результаты.
  • US9645980B1
  • 2017-05-09

  • Индексация

  • Ссылки

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

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

Как Google автоматически превращает текст на странице в ссылки на результаты поиска для монетизации контента
Патент Google описывает технологию автоматического анализа контента веб-страницы для выявления ключевых тем и терминов. Система генерирует релевантные поисковые запросы и динамически встраивает гиперссылки в текст страницы. При клике пользователь перенаправляется на страницу результатов поиска (SERP). Ключевая особенность: система приоритизирует термины с высоким потенциалом дохода от рекламы.
  • US7788245B1
  • 2010-08-31

  • Ссылки

  • SERP

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

Как Google комбинирует поведенческие сигналы из разных поисковых систем для улучшения ранжирования
Google использует механизм для улучшения ранжирования путем объединения данных о поведении пользователей (клики и время взаимодействия) из разных поисковых систем (например, Веб-поиск и Поиск по Видео). Если в основной системе данных недостаточно, система заимствует данные из другой, применяя весовой коэффициент и фактор сглаживания для контроля смещения и обеспечения релевантности.
  • US8832083B1
  • 2014-09-09

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

  • SERP

Как Google персонализирует мобильную выдачу, повышая в ранжировании приложения, которые пользователь часто использует (Affinity Score)
Google рассчитывает «Affinity Score» для мобильных приложений на основе того, как часто и долго пользователь их использует (относительное вовлечение). При поиске с мобильного устройства система повышает в ранжировании результаты (deep links), ведущие в приложения с высоким Affinity Score, делая выдачу более персонализированной.
  • US10248698B2
  • 2019-04-02

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

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

  • SERP

Как Google использует погоду, время и местоположение для понимания истинного намерения пользователя и адаптации поисковой выдачи
Google анализирует, как физическое окружение (погода, время, местоположение) влияет на то, что ищут пользователи. Система выявляет корреляции между средой и поведением пользователей в прошлом (включая длительность кликов), чтобы лучше понять текущий интент многозначных запросов. Затем она переранжирует выдачу или переписывает запрос для предоставления наиболее релевантных результатов и рекламы.
  • US8898148B1
  • 2014-11-25

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

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

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

Как Google алгоритмически вычисляет и ранжирует экспертов по темам на основе анализа их контента
Google использует систему для автоматического определения экспертности авторов (Identities) в конкретных темах (Topics). Система анализирует корпус документов, оценивая, насколько сильно автор связан с документом (Identity Score) и насколько документ релевантен теме (Topic Score). Эти оценки перемножаются и суммируются по всем документам, формируя итоговый рейтинг экспертности автора в данной области.
  • US8892549B1
  • 2014-11-18

  • EEAT и качество

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

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

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

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

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

Как Google использует машинное обучение для оптимизации обхода Knowledge Graph и поиска связанных концепций
Google оптимизирует обход Knowledge Graph для эффективного поиска семантически связанных фраз. Вместо анализа всех связей сущности система использует ML-модели для выбора только тех отношений (свойств), которые вероятнее всего приведут к ценным результатам. Этот выбор основан на истории поисковых запросов и контексте пользователя, что позволяет экономить вычислительные ресурсы и повышать релевантность предложений.
  • US10140286B2
  • 2018-11-27

  • Knowledge Graph

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

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

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

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

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

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

Как Google ранжирует сущности (книги, фильмы, людей), анализируя тематичность и авторитетность их упоминаний в вебе
Google использует механизм для оценки значимости конкретных сущностей (например, изданий книг или фильмов). Система анализирует, как эти сущности упоминаются на релевантных веб-страницах, учитывая уверенность распознавания (Confidence) и то, насколько страница посвящена именно этой сущности (Topicality). Эти сигналы агрегируются с учетом авторитетности и релевантности страниц для расчета итоговой оценки сущности, которая затем корректирует ее ранжирование в поиске.
  • US20150161127A1
  • 2015-06-11

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

  • EEAT и качество

  • SERP

Как Google использует распределение кликов по разным типам запросов для оценки общего качества сайта (Website Quality Score)
Google оценивает качество сайта не по общему CTR, а по тому, в ответ на какие запросы он получает клики. Система сегментирует пользовательский фидбек (клики, CTR) по различным параметрам запроса (например, конкурентность, длина, популярность). Сайт считается качественным, если он получает много кликов в ответ на высококонкурентные и популярные запросы, а не только на низкочастотные или нечеткие.
  • US8615514B1
  • 2013-12-24

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