Close Menu
    Telegram
    SEO HARDCORE
    • Разборы патентов
      • Патенты Google
      • Патенты Яндекс
    • Скоро
      SEO инструменты
    • Скоро
      SEO аналитика
    SEO HARDCORE
    Разборы патентов • Патенты Google

    Как Google автоматически извлекает структуру фасетной навигации с помощью анализа DOM/XPath для создания расширенных сниппетов и Sitelinks

    SYSTEMS AND METHODS FOR GENERATING NAVIGATION FILTERS (Системы и методы генерации навигационных фильтров)
    • US10354292B1
    • Google LLC
    • 2019-07-16
    • 2014-01-03
    2014 Google Shopping Краулинг Патенты Google Ссылки

    Google использует технологию для автоматического извлечения структурированных данных (Заголовков и Элементов) со страниц сайта. Система находит примеры категорий и фильтров (например, «Бренды», «Цвета»), определяет их структурное расположение в коде (Path/XPath), и затем использует этот шаблон для извлечения всех остальных схожих элементов. Это позволяет формировать «Навигационные фильтры» – концептуально связанные списки для обогащения сниппетов или рекламы прямыми ссылками на отфильтрованный контент.

    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх

    Описание

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

    Патент решает задачу автоматического извлечения структурированных данных с целевого ресурса (например, страницы категории или лендинга) для обогащения элемента контента (content item, например, рекламного объявления или органического сниппета), который ссылается на этот ресурс. Цель – предоставить пользователю краткую сводку содержимого целевого ресурса и прямые ссылки (deep links) на его отфильтрованные представления до перехода на сайт. Это улучшает пользовательский опыт, так как стандартные текстовые описания часто плохо суммируют контент сложных страниц с множеством опций.

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

    Запатентована система генерации Navigation Filters (Навигационных фильтров). Фильтр состоит из Заголовка (Heading) и набора концептуально параллельных элементов (Conceptually parallel items), которые представляют собой вариации в рамках одного измерения (например, Заголовок: «Цвет», Элементы: «Красный», «Синий»). Система использует предопределенные примеры (Archetypal data) для идентификации схожих структур на странице, а затем применяет метод обобщения (Generalization) на основе структурного пути (Path, аналог XPath), чтобы извлечь полный набор фильтров, даже тех, которые не были заранее известны системе.

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

    Система работает в несколько этапов:

    • Сбор и Нормализация Архетипов: Система получает и нормализует набор предопределенных примеров заголовков и элементов (Archetypal headings/items).
    • Идентификация на странице: Система ищет вхождения нормализованных архетипов в коде целевого ресурса.
    • Определение пути (Path Determination): Для каждого найденного вхождения определяется его точный структурный путь в DOM (например, /div/ul/li/a).
    • Обобщение (Generalization): Система создает запрос (Query) на основе найденного пути, чтобы извлечь все другие элементы на странице, имеющие точно такой же путь. Это позволяет найти новые заголовки и элементы, структурно идентичные архетипам.
    • Создание фильтров: Извлеченные элементы ассоциируются с соответствующими заголовками (например, на основе последовательности в коде или общего предка в DOM) для формирования Navigation Filters.
    • Ранжирование и Интеграция: Сгенерированные фильтры ранжируются, и лучшие из них интегрируются в сниппет или рекламное объявление.

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

    Высокая. Автоматическое извлечение структурированных данных и понимание архитектуры сайта (Site Structure Understanding) являются ключевыми направлениями развития поиска. Методы, описанные в патенте, напрямую связаны с тем, как Google анализирует фасетную навигацию, категории и атрибуты товаров для формирования расширенных сниппетов, Sitelinks и товарных выдач. Понимание того, как Google использует структурные шаблоны (Paths/XPath) для извлечения данных, остается критически важным для технического SEO в 2025 году.

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

    Патент имеет высокое значение для SEO (85/100), особенно для E-commerce и контентных проектов с развитой структурой. Он описывает конкретный механизм, с помощью которого Google может понять и извлечь навигационную структуру сайта, даже если она не размечена с помощью Schema.org. Это напрямую влияет на то, как сайт будет представлен в выдаче (Sitelinks, расширенные сниппеты). Оптимизация под этот механизм требует чистого, семантически верного и, главное, консистентного HTML-кода для навигационных элементов.

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

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

    Archetypal headings/items (Архетипичные заголовки/элементы)
    Предопределенные примеры текстовых данных (golden examples), представляющие собой заголовки или элементы, подходящие для использования в навигационном фильтре (например, «Бренды», «Цвета» или конкретные названия брендов). Используются как «семена» для запуска процесса извлечения.
    Conceptually parallel items (Концептуально параллельные элементы)
    Набор элементов, которые являются вариациями в рамках одного измерения (single dimension), определяемого заголовком. Например, для заголовка «Цвет» элементами будут «Красный», «Синий».
    DOM (Document Object Model)
    Объектная модель документа. Иерархическое представление структуры веб-страницы, используемое для анализа путей и взаимосвязей между элементами.
    Generalization (Обобщение)
    Процесс использования структурного пути (Path) идентифицированного архетипа для поиска других заголовков или элементов, которые имеют такой же путь, но не обязательно присутствовали в исходном наборе архетипов.
    Leaf Node (Листовой узел)
    Узел в DOM, не имеющий дочерних элементов. В патенте используется как один из критериев для идентификации качественных заголовков.
    MRCA (Most Recent Common Ancestor / Ближайший общий предок)
    Самый нижний общий предок двух узлов (например, заголовка и элемента) в DOM-дереве. Используется для ассоциации элементов с заголовками на основе структурной близости.
    Navigation Filter (Навигационный фильтр)
    Структурированный элемент, состоящий из одного Заголовка (Heading) и связанного с ним набора концептуально параллельных элементов (Items).
    Path (Путь)
    Структурное расположение элемента в ресурсе. Определяется путем обхода аннотаций (например, HTML-тегов). Описывается как XPath или его вариант. Ядро механизма генерализации.
    Target Resource (Целевой ресурс)
    Страница (например, лендинг, страница категории), на которую ведет Content Item и из которой извлекаются данные для фильтров.

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

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

    1. Система идентифицирует вхождения нормализованных данных (normalized data entries) в целевом ресурсе (target electronic resource).
    2. Система генерирует множество навигационных фильтров на основе этих данных. Каждый фильтр состоит из заголовка и множества параллельных элементов.
    3. Система передает эти фильтры для отображения вместе с элементом контента (content item) на первом электронном ресурсе (например, SERP).
    4. Описывается структура отображения: Минимум два фильтра. Первый фильтр имеет Заголовок 1 (измерение 1) и Элементы (вариации измерения 1); Второй фильтр имеет Заголовок 2 (измерение 2) и Элементы (вариации измерения 2).
    5. Ключевое уточнение: Элементы фильтров содержат гиперссылки (hyperlink), которые при клике ведут на соответствующую часть целевого ресурса, причем контент там уже отфильтрован по условию, указанному в элементе (filtered by a respective item condition).

    Claim 2 и 3 (Зависимые): Детализируют процесс генерации фильтров, раскрывая ядро изобретения (Генерализация по Структуре).

    1. Получение набора архетипов (archetypal headings or archetypal items) и их нормализация (Claim 2).
    2. Определение пути (Path) к каждому найденному вхождению архетипов в ресурсе (Claim 3).
    3. Использование этого пути для создания запроса (construct a query) для поиска других потенциальных заголовков или элементов, имеющих такой же путь (механизм обобщения) (Claim 3).
    4. Генерация фильтра путем ассоциации найденных элементов с заголовками (Claim 3).

    Claim 5, 6, 7 (Зависимые от 3): Описывают три альтернативных метода ассоциации элементов с заголовками (Filter Creation).

    • Claim 5 (Последовательность): Элементы, расположенные между Первым и Вторым заголовком в коде, ассоциируются с Первым заголовком.
    • Claim 6 (Идентичность Пути): Определяется путь к первому элементу после заголовка. Другие элементы ассоциируются с этим заголовком, только если их путь идентичен пути первого элемента.
    • Claim 7 (Общий Предок): Определяется ближайший общий предок (MRCA) заголовка и первого элемента. Другие элементы ассоциируются с этим заголовком, только если они имеют тот же MRCA.

    Claim 12 и 13 (Зависимые от 11): Уточняют правила идентификации заголовков.

    Тег может быть исключен из рассмотрения как потенциальный заголовок, если он НЕ является листовым узлом (Leaf Node) (Claim 12) ИЛИ если он является дочерним узлом гиперссылки (Claim 13).

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

    Изобретение применяется на этапах индексирования для извлечения данных и на финальных этапах формирования выдачи для их отображения.

    CRAWLING – Сканирование и Сбор данных
    Система должна получить доступ к полному контенту и HTML-структуре целевых ресурсов.

    INDEXING – Индексирование и извлечение признаков
    Основная работа механизма происходит на этом этапе.

    1. Парсинг и Рендеринг: Целевой ресурс парсится для создания DOM-представления (Resource Parsing Module).
    2. Извлечение Признаков (Feature Extraction): Система выполняет процесс генерации фильтров: загрузка архетипов (Archetypal Text Module), сопоставление (Matching Modules), определение путей и обобщение (Generalization Modules).
    3. Создание Фильтров: Filter Creation Module собирает извлеченные данные в Navigation Filters.
    4. Сохранение: Сгенерированные фильтры сохраняются в индексе, ассоциированные с URL целевого ресурса.

    METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
    На этапе формирования SERP или показа рекламы система принимает решение о том, какие фильтры показать.

    1. Ранжирование Фильтров: Filter Ranking Module оценивает сохраненные фильтры, используя различные критерии (релевантность запросу, данные пользователя).
    2. Интеграция: Filter Integration Module выбирает топовые фильтры и встраивает их в сниппет или рекламное объявление в соответствующем формате (ссылки, выпадающий список и т.д.).

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

    • HTML/DOM целевого ресурса.
    • Набор Archetypal data entries (из конфигурационных таблиц).
    • Правила нормализации (регулярные выражения).

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

    • Набор сгенерированных Navigation Filters для ресурса.
    • Модифицированный элемент контента (сниппет/реклама) с интегрированными фильтрами (deep links).

    На что влияет

    • Конкретные типы контента: Наибольшее влияние на страницы с четкой иерархической или фасетной структурой – категории товаров (PLP), списки услуг, каталоги, агрегаторы.
    • Конкретные ниши или тематики: E-commerce, недвижимость, авто, путешествия – любые ниши, где товары или объекты имеют множество атрибутов для фильтрации.
    • Форматы контента: Списки (<ul>, <li>), блоки навигации, фасетные фильтры.

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

    • Условия работы: Алгоритм применяется к ресурсам, где возможно идентифицировать повторяющиеся структурные шаблоны, соответствующие навигационным элементам.
    • Триггеры активации: Активируется, когда система находит вхождения Archetypal data на странице, что позволяет запустить механизм определения пути (Path) и последующего обобщения (Generalization).
    • Исключения и Фильтры: Фильтры могут быть отброшены (discarded), если:
      • Они содержат слишком мало элементов (ниже порога).
      • Слишком мало элементов совпало с исходными архетипами (проверка качества).
      • Фильтр слишком часто повторяется на разных страницах домена (repeat instances), что указывает на сквозное меню (boilerplate), а не специфичный контент.

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

    Процесс А: Генерация навигационных фильтров (Обычно Indexing time)

    1. Получение и Нормализация Архетипов: Загрузка набора Archetypal data и их преобразование в стандартную форму с использованием заданных правил (например, регулярных выражений).
    2. Парсинг ресурса: Анализ целевого ресурса и создание его DOM-представления.
    3. Идентификация вхождений (Matching): Поиск вхождений нормализованных архетипов в тексте ресурса.

      Уточнение для заголовков: Проверка, является ли тег листовым узлом (leaf node) и не является ли он дочерним элементом гиперссылки.

    4. Определение пути (Path Determination): Для каждого идентифицированного вхождения определяется структурный путь от корневого элемента ресурса (например, XPath).
    5. Обобщение (Generalization): Использование пути идентифицированного вхождения для создания запроса. Этот запрос извлекает все другие элементы в ресурсе, которые имеют точно такой же путь.
    6. Создание фильтров (Ассоциация): Ассоциация потенциальных элементов с потенциальными заголовками. Используются методы:
      • По последовательности: Элементы между двумя заголовками привязываются к первому.
      • По структуре (Path): Элементы привязываются, если имеют идентичный путь с первым элементом после заголовка.
      • По структуре (MRCA): Элементы привязываются, если имеют того же ближайшего общего предка с заголовком, что и первый элемент.
    7. Пост-фильтрация: Удаление сгенерированных фильтров, если они не соответствуют критериям качества или уникальности (отсечение сквозных блоков).

    Процесс Б: Ранжирование и Выбор фильтров (Обычно Serving time)

    1. Получение фильтров: Получение набора сгенерированных фильтров для ресурса.
    2. Идентификация критериев ранжирования: Определение критериев (запрос пользователя, интересы, глобальные приоритеты).
    3. Ранжирование: Оценка и сортировка фильтров и их элементов.
    4. Выбор и Интеграция: Выбор топовых фильтров для интеграции в сниппет/рекламу с учетом доступного пространства.

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

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

    Патент фокусируется на механизме извлечения структуры и использует следующие типы данных:

    • Структурные факторы (Критически важно): Структура целевого ресурса (DOM), HTML-теги (<a>, <hX>, <ul>, <li> и т.д.), иерархия элементов (intermediate tags), порядок следования элементов (HTML position order). Анализируется статус узла (Leaf Node, дочерний элемент гиперссылки).
    • Контентные факторы: Текст внутри тегов (content text), текст гиперссылок (анкоры). Используется для сопоставления с архетипами и формирования текста фильтров.
    • Технические факторы: URL гиперссылок (href attribute). Используются для создания прямых ссылок (deep links) в навигационных фильтрах.
    • Системные данные: Archetypal data entries (предопределенные списки) и правила нормализации (Regular Expressions).

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

    • Path (Путь): Структурный путь от корневого элемента до конкретного узла (например, XPath). Вычисляется путем обхода DOM-дерева. Основа для генерализации.
    • MRCA (Most Recent Common Ancestor): Ближайший общий предок в DOM. Используется для определения структурной близости и ассоциации заголовка и элемента.
    • Количество элементов в фильтре: Используется для пост-фильтрации (фильтры ниже порога отбрасываются).
    • Количество совпадений с архетипами: Метрика качества фильтра. Фильтры с недостаточным количеством подтвержденных архетипами элементов могут быть отброшены.
    • Частота повторений фильтра (Number of repeat instances): Количество страниц на домене, где встречается идентичный навигационный фильтр (определяемый по fingerprint). Если частота превышает порог, фильтр считается сквозным (boilerplate) и отбрасывается.

    Выводы

    1. Критическая важность консистентной структуры HTML: Патент демонстрирует, что Google активно использует структурные шаблоны (Path/XPath) как основной метод для извлечения связанных данных. Если навигационные элементы (например, фасетные фильтры) имеют разную HTML-структуру, система не сможет применить обобщение (Generalization) и не извлечет полный набор данных.
    2. Извлечение данных без микроразметки: Механизм позволяет извлекать структурированные данные без опоры на Schema.org, полагаясь исключительно на повторяемость HTML-структуры и наличие известных текстовых паттернов (Archetypal data).
    3. Конкретные эвристики для идентификации заголовков: Система применяет правила для поиска заголовков: они предпочтительно должны быть листовыми узлами (Leaf Nodes) и не должны быть частью гиперссылки (Claims 12, 13). Это важный инсайт для технической оптимизации верстки.
    4. Механизм идентификации сквозных блоков (Boilerplate): Система умеет отличать полезные навигационные фильтры, специфичные для страницы, от общих сквозных меню, анализируя частоту повторений (repeat instances) фильтров на домене.
    5. Генерация Deep Links и Sitelinks: Патент описывает механизм формирования динамических Sitelinks и расширенных сниппетов, предоставляя прямые ссылки на отфильтрованные представления контента.
    6. Приоритет концептуальной группировки: Система стремится создавать фильтры, где элементы являются вариациями одного измерения (Conceptually parallel items). Смешивание разнородных ссылок в одном блоке нежелательно.

    Практика

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

    • Обеспечение абсолютной консистентности HTML для навигации и фильтров: Это ключевая рекомендация. Все элементы фасетной навигации и списков атрибутов должны иметь идентичную HTML-структуру и путь в DOM. Например, если список брендов реализован как <ul><li><a>…</a></li></ul>, все элементы списка должны следовать этому шаблону без исключений. Это позволит механизму Generalization корректно извлечь все данные.
    • Использование семантической и чистой верстки: Применение семантических тегов (<nav>, списки, заголовки) помогает системе корректно интерпретировать блоки. Группируйте заголовок и его элементы внутри одного родительского контейнера для облегчения анализа MRCA.
    • Соблюдение правил для заголовков: Убедитесь, что заголовки фильтров (например, «Бренды») являются листовыми узлами (leaf nodes) — не содержат вложенных элементов — и не обернуты в тег <a>.
    • Оптимизация текстов фильтров (Archetypes): Используйте четкие и общепринятые названия для атрибутов и их значений. Это повышает вероятность совпадения с Archetypal data, что необходимо для запуска и верификации механизма извлечения.
    • Проверка уникальности навигации: Убедитесь, что структура фасетной навигации отличается от структуры сквозных блоков (хедер, футер), чтобы избежать отбраковки полезных фильтров как boilerplate.

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

    • Использование разной верстки для однотипных элементов: Применение разных тегов, классов, меняющих структуру, или оберток для элементов одного списка (например, выделение первого или последнего элемента). Это блокирует механизм обобщения, так как Paths будут разными.
    • Вложение заголовков в ссылки: Размещение заголовков фильтров внутри тегов <a>. Патент указывает, что система может исключать дочерние элементы гиперссылок при поиске заголовков (Claim 13).
    • Сложная структура заголовков (Non-leaf nodes): Включение в тег заголовка дополнительных элементов (счетчиков, иконок, вложенных списков). Это нарушает правило Leaf Node (Claim 12).
    • Смешивание разнородных ссылок в одном блоке: Создание блоков, где смешаны ссылки на категории, акции и служебные страницы. Система ищет Conceptually parallel items и может проигнорировать такие блоки.

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

    Патент подтверждает стратегический приоритет Google в автоматическом понимании структуры веб-страниц (Site Structure Understanding). Для SEO это означает, что инвестиции в техническое качество фронтенда — чистый, консистентный и семантический код — напрямую влияют на способность Google извлекать данные и представлять сайт в SERP (Sitelinks, расширенные сниппеты). Этот механизм работает параллельно с микроразметкой и является важным элементом технической оптимизации, особенно для E-commerce.

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

    Сценарий: Оптимизация фасетной навигации E-commerce сайта для лучшего распознавания структуры.

    Плохая реализация (затрудняет извлечение из-за неконсистентности):

    <div class="filter-block">
      <h3>Бренды</h3>
      <div class="item-first"><a href="/b1">Sony</a></div> <!-- Другая структура -->
      <div class="item"><a href="/b2">Nikon</a></div>
      <div class="item"><a href="/b3">Canon</a></div>
    </div>

    Проблема: Система может найти архетип «Sony», определить его путь (например, /div/div[1]/a), но не сможет найти «Nikon» и «Canon» по этому пути, так как их пути отличаются (/div/div[2]/a, если система не игнорирует индексы, или отличаются из-за классов, если они учитываются).

    Хорошая реализация (оптимизирована для извлечения):

    <div class="filter-block">
      <h3>Бренды</h3> <!-- Leaf node -->
      <ul>
        <li><a href="/b1">Sony</a></li> <!-- Консистентная структура -->
        <li><a href="/b2">Nikon</a></li>
        <li><a href="/b3">Canon</a></li>
      </ul>
    </div>

    Результат: Все элементы имеют консистентный путь (например, /div/ul/li/a). Система успешно идентифицирует один элемент и использует генерализацию по пути для извлечения всех остальных Conceptually parallel items.

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

    Что такое «Архетипичные данные» (Archetypal data) и откуда Google их берет?

    Архетипичные данные – это заранее подготовленные примеры (golden examples) заголовков и элементов, которые система ожидает увидеть в навигационных фильтрах (например, списки популярных брендов, цветов, стандартные названия атрибутов). В патенте указано, что эти данные загружаются из конфигурационных файлов или таблиц (key-value lookup table). На практике они, вероятно, формируются Google на основе анализа веба, данных из Knowledge Graph или размеченных датасетов.

    Насколько важна консистентность HTML-кода для работы этого алгоритма?

    Консистентность критически важна. Ядро изобретения – это механизм обобщения (Generalization), который работает на основе структурного пути (Path/XPath). Если система определяет путь к одному элементу фильтра, она ищет другие элементы с точно таким же путем. Если однотипные элементы имеют разную верстку, их пути будут отличаться, и алгоритм не сможет извлечь полный набор данных.

    Означает ли этот патент, что микроразметка Schema.org не нужна?

    Нет, не означает. Этот патент описывает механизм, который позволяет Google извлекать структурированные данные, полагаясь на HTML-структуру, когда явная разметка отсутствует или недостаточна. Schema.org остается предпочтительным и более надежным способом передачи данных. Оптимизация HTML-структуры служит отличным дополнением и страховкой, улучшая общее понимание сайта.

    Как система отличает полезные фильтры от сквозных меню (например, в хедере)?

    Патент описывает механизм пост-фильтрации. Система подсчитывает количество повторений (number of repeat instances) идентичного фильтра (определяемого по fingerprint) на разных страницах домена. Если фильтр повторяется слишком часто (превышает порог), он классифицируется как сквозной (boilerplate) и отбрасывается как неспецифичный для контента страницы.

    Что такое «Концептуально параллельные элементы» и почему это важно?

    Это элементы, которые являются вариациями одного измерения. Например, «Красный», «Синий», «Зеленый» параллельны в измерении «Цвет». Система стремится создавать фильтры именно из таких элементов, чтобы обеспечить логичное представление данных. Блоки, смешивающие разные измерения (например, «Красный», «Скидка 50%», «Новинка»), считаются менее качественными.

    Влияет ли этот патент на органический поиск или только на рекламу?

    Хотя в патенте часто упоминаются «content items» в контексте рекламы, описанные механизмы извлечения структурированных данных универсальны. Они с высокой вероятностью используются для понимания структуры сайта в целом, что влияет на формирование органических Sitelinks, расширенных сниппетов (например, Structured Snippets) и понимание атрибутов товаров в органическом поиске.

    Что такое MRCA и как он используется?

    MRCA (Most Recent Common Ancestor) – это ближайший общий предок в DOM-дереве. Система использует его для ассоциации элементов с заголовками. Она проверяет, находятся ли заголовок и относящиеся к нему элементы внутри одного ближайшего родительского контейнера. Это помогает более точно группировать данные на основе структуры.

    Какие требования предъявляются к заголовкам фильтров?

    Патент упоминает важные эвристики (Claims 12, 13). Потенциальный заголовок предпочтительно должен быть листовым узлом (leaf node) — то есть не содержать вложенных элементов. Также он не должен быть дочерним элементом гиперссылки (т.е. находиться внутри тега <a>). Это помогает отличить заголовки атрибутов от навигационных ссылок или структурных контейнеров.

    Что важнее для SEO в контексте этого патента: чистый код или ключевые слова в фильтрах?

    Оба аспекта важны, но чистый и консистентный код является фундаментом. Без корректной структуры система не сможет извлечь данные, даже если текст идеально оптимизирован. Ключевые слова (текст фильтров) важны для сопоставления с архетипами и для ранжирования фильтров, но первична структура (Path).

    Как проверить, корректно ли Google извлекает структуру моего сайта этим методом?

    Прямого инструмента нет. Косвенные признаки — это появление релевантных Sitelinks и структурированных сниппетов для ваших категорийных страниц. Технически можно валидировать свой код, используя инструменты для извлечения XPath (например, в консоли разработчика браузера), чтобы убедиться в абсолютной консистентности путей к вашим навигационным элементам и заголовкам.

    Навигация
    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх
    Telegram
    © 2025 SEO HARDCORE

    Type above and press Enter to search. Press Esc to cancel.