Как поисковые системы могут находить сайты по неполным или ошибочным URL-адресам, используя персонализацию и ключевые слова

Описание

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

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

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

Запатентована система (разработанная IBM) для специализированного поиска URL-адресов по частично указанному вводу, включая использование подстановочных знаков (wildcard characters, например, *). Система использует инвертированный индекс (inverted index) строк URL и применяет многофакторное ранжирование для упорядочивания результатов. Ключевым элементом является использование персонализации (история посещений, профиль пользователя, peer groups) и ключевых слов контента сайта для уточнения и ранжирования потенциальных совпадений.

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

Система работает в двух режимах: офлайн и онлайн.

• Офлайн (Индексация): Система сканирует веб, собирает URL-адреса и извлекает основные ключевые слова из контента сайтов. Затем строится инвертированный индекс подстрок (n-грамм) самих URL-адресов. Также анализируются логи для создания профилей пользователей и их кластеризации.
• Онлайн (Обработка запроса): Пользователь вводит частичный URL. Система находит все URL, соответствующие шаблону, в инвертированном индексе. Затем результаты ранжируются с использованием Web Search Request Handler. Ранжирование учитывает: ключевые слова, указанные пользователем (сопоставляя их с контентом сайта), историю недавно посещенных URL (recently accessed URLs) и профиль интересов пользователя (user profile).

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

Низкая. Патент подан IBM в 2000 году. Технологии навигационного поиска и автодополнения в браузерах (Omnibox) и поисковых системах значительно эволюционировали. Современные системы используют сложное машинное обучение, глобальные поведенческие данные (CTR, популярность сайтов) и семантический анализ для исправления ошибок и предсказания намерений пользователя, что делает описанные в патенте методы (такие как явное использование подстановочных знаков и ранжирование на основе базовых профилей) устаревшими.

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

Минимальное влияние (2/10). Патент фокусируется исключительно на навигационном поиске — помочь пользователю добраться до конкретного сайта, когда он не знает точного адреса. Он не описывает механизмы информационного или транзакционного ранжирования. Хотя патент подтверждает важность индексации URL и использования ключевых слов контента для понимания тематики сайта, он не дает стратегических инсайтов для улучшения органической видимости в современных поисковых системах.

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

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

Inverted index of web site URLs (Инвертированный индекс URL веб-сайтов)

Структура данных, которая индексирует URL-адреса на основе содержащихся в них символов и строк символов (n-грамм). Позволяет быстро находить полные URL по их фрагментам.

Partially specified URL (Частично указанный URL)

Ввод пользователя, который является неполным, содержит ошибки или включает подстановочные знаки (wildcard characters).

Peer groups (Группы схожих пользователей)

Кластеры пользователей, объединенных на основе схожих профилей (демография, интересы, история посещений). Информация, полученная от группы, используется для улучшения ранжирования отдельного пользователя в этой группе.

Profile Updater (Обновитель профилей)

Компонент системы, который анализирует логи сервера для обновления профилей пользователей и кластеризации пользователей в peer groups.

Recently accessed URL list (Список недавно посещенных URL)

История посещений пользователя, предоставляемая браузером или прокси-сервером. Используется как фактор ранжирования.

URL Index Builder (Построитель индекса URL)

Компонент системы, отвечающий за сканирование веба, сбор URL, извлечение ключевых слов из контента и построение inverted index.

URL Search Request Handler (Обработчик запросов поиска URL)

Компонент, который использует inverted index для поиска URL, соответствующих частично указанному вводу (поиск по строкам).

User profile database (База данных профилей пользователей)

Хранилище данных о пользователях: история поиска, посещенные сайты, ключевые слова интересов, демография и информация о peer groups.

Web Search Request Handler (Обработчик веб-поисковых запросов)

Компонент, отвечающий за ранжирование результатов, найденных URL Search Request Handler, на основе ключевых слов, истории посещений и профиля пользователя.

Web site URL database (База данных URL веб-сайтов)

Хранилище, содержащее URL-адреса и список топовых ключевых слов (Top ‘m’ keywords), извлеченных из контента соответствующих сайтов.

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

Claim 1 (Независимый пункт): Описывает основной метод поиска по частично указанному URL.

1. Система получает запрос пользователя, содержащий частично указанный URL (partially specified URL).
2. Запускается URL search request handler для поиска этого частичного URL в inverted index of web site URLs.
3. Запускается web search request handler для ранжирования результатов поиска.
4. Ранжирование основывается на трех типах данных: (i) ключевые слова, указанные в запросе пользователя, (ii) список недавно посещенных URL (list of recently accessed URLs), и (iii) профиль пользователя (user profile).
5. Система возвращает пользователю ранжированный список URL-адресов.

Claim 3 (Зависимый): Уточняет структуру inverted index. Он содержит список частично указанных URL-адресов и связанный список полных URL-адресов, которые представлены этим частичным адресом.

Claim 4 и 6 (Зависимые): Уточняют, что частично указанный URL может быть неполным адресом, включающим подстановочный знак (wildcard) (Claim 4), или адресом с орфографическими ошибками (Claim 6).

Claim 7 (Зависимый): Определяет метод индексации. Inverted index индексирует URL-адреса по отдельным символам и строкам символов (n-граммам), которые появляются в тексте URL-адреса.

Claim 10, 11, 12 (Зависимые): Детализируют данные профиля пользователя (user search data).

• Включает демографическую информацию, предоставленную пользователем при регистрации (Claim 10).
• Данные кластеризуются по группам схожих пользователей (user peer group), где информация, полученная от одного пользователя, применяется к другим в группе (Claim 11).
• Данные могут быть собраны прокси-сервером, который пользователь использовал для доступа к сайтам (Claim 12).

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

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

CRAWLING – Сканирование и Сбор данных
Система должна сканировать веб для обнаружения URL-адресов и загрузки контента страниц для извлечения ключевых слов.

INDEXING – Индексирование и извлечение признаков
Основной этап подготовки данных.

• Извлечение признаков: Извлечение Top ‘m’ ключевых слов из контента сайта.
• Построение баз данных: Создание Web site URL database (URL + Ключевые слова).
• Построение индекса: Создание Inverted index of web site URLs путем индексации подстрок (n-грамм) самих URL.
• Обработка профилей: Анализ логов доступа и построение User profile database, включая кластеризацию в peer groups.

RANKING – Ранжирование / RERANKING – Переранжирование
Процесс происходит в два этапа при обработке запроса:

• Retrieval (L1): URL Search Request Handler быстро отбирает кандидатов из inverted index на основе совпадения строк (частичный URL, wildcard, fuzzy match).
• Ranking/Reranking (L2/L3): Web Search Request Handler ранжирует отобранных кандидатов, используя сигналы персонализации и контента.

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

• Частично указанный URL.
• Опциональные ключевые слова от пользователя.
• Recently accessed URL list (от браузера/прокси).
• User profile data (идентификатор пользователя).

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

• Ранжированный список полных URL-адресов.

На что влияет

• Специфические запросы: Влияет исключительно на навигационные запросы, где пользователь пытается найти конкретный сайт, но не знает или не помнит точный адрес.
• Конкретные типы контента: Не зависит от типа контента, так как фокусируется на URL, но использует ключевые слова контента для ранжирования.

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

• Триггеры активации: Когда пользователь вводит запрос в специализированный сервис поиска URL или когда система (например, браузер или поисковая система) интерпретирует ввод как попытку навигации по неполному или ошибочному URL.

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

Процесс А: Офлайн-обработка (Maintenance Routine)

1. Сканирование и извлечение ключевых слов: Система обнаруживает URL и извлекает Top ‘m’ ключевых слов из контента сайта (используя метатеги, частоту слов и т.д.).
2. Индексация URL: URL и ключевые слова сохраняются в Web site URL database. Строится inverted index, индексирующий подстроки (n-граммы) URL.
3. Обновление профилей (Profile Updater): Анализируются логи сервера. Обновляется история посещений, выбранные результаты и ключевые слова интересов для каждого пользователя в User profile database.
4. Кластеризация: Пользователи группируются в peer groups на основе схожести профилей. Информация об интересах группы добавляется в профили участников.

Процесс Б: Обработка запроса в реальном времени (URL Search Request Handler)

1. Получение ввода: Система получает частичный URL, опциональные ключевые слова и данные для персонализации (например, recently accessed URL list).
2. Поиск совпадений (URL Retrieval): URL Search Request Handler использует inverted index для поиска всех URL, соответствующих частичному вводу (учитывая wildcards и fuzzy matching для исправления ошибок).
3. Фильтрация (Опционально): Если пользователь указал ключевые слова, система может отфильтровать результаты, если эти ключевые слова не присутствуют в контенте сайта (в Web site URL database).
4. Ранжирование (Web Search Request Handler): Система ранжирует список URL, используя несколько факторов. Описан пример с приоритетами:
   • Приоритет 1: Количество совпавших ключевых слов (указанных пользователем и в контенте сайта).
   • Приоритет 2 (Tie-breaker): Присутствие URL в recently accessed URL list.
   • Приоритет 3 (Tie-breaker): Совпадение с user profile (интересы, демография, peer group info).
   • Альтернатива: Использование взвешенной композитной функции (composite function) для расчета итогового балла.
5. Вывод результатов: Ранжированный список возвращается пользователю.
6. Логирование: Запрос и выбранный пользователем результат логируются для будущего обновления профиля.

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

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

• Контентные факторы: Top ‘m’ ключевых слов, извлеченных из веб-сайта. Патент упоминает использование мета-информации (например, HTML тег meta), XML, PICS аннотаций или частоты встречаемости слов на сайте в качестве источников этих ключевых слов.
• Технические факторы: Сами строки URL-адресов, которые индексируются по подстрокам (n-граммам).
• Пользовательские и Поведенческие факторы:
  • Recently accessed URL list (история посещений от браузера или прокси).
  • Last n search results selected (история выбора результатов поиска).
  • Top ‘m’ ключевых слов из недавно посещенных URL.
  • User ID / Cookie information.
  • Демографическая информация (возраст, доход, пол) – если пользователь зарегистрирован.
  • Subjects of interest (темы интересов).

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

• String Matching / Fuzzy Matching: Используется для сопоставления частичного/ошибочного URL с индексом. Патент не детализирует алгоритм, но упоминает обработку wildcards и ошибок (используя fuzzy logic).
• Keyword Matching (Совпадение ключевых слов): Количество ключевых слов, совпавших между вводом пользователя и контентом сайта.
• Кластеризация: Упоминается использование алгоритмов кластеризации для формирования peer groups на основе профилей пользователей.
• Composite Function (Композитная функция / Взвешенная оценка): Патент предлагает пример формулы для ранжирования: w1*(number of matching keywords) + w2*(number of matching subject interests) + w3*(if the Web site appears in the recently accessed URL list), где w1, w2, w3 – весовые коэффициенты.

Выводы

1. Фокус на навигационном поиске: Патент описывает инфраструктурное решение для улучшения навигации по неточным URL, а не систему органического ранжирования.
2. Индексация URL как строк: Ключевым механизмом является создание инвертированного индекса на основе подстрок (n-грамм) URL-адресов, что позволяет выполнять поиск по фрагментам и с подстановочными знаками.
3. Раннее использование персонализации: Патент (подан в 2000 г.) демонстрирует ранние методы интеграции персонализации в поиск. Используются история посещений (recently accessed URLs), профили интересов и демография для ранжирования результатов.
4. Кластеризация пользователей (Peer Groups): Система использует кластеризацию для определения интересов групп пользователей и применяет эти данные для улучшения ранжирования отдельных участников группы.
5. Контент как фактор ранжирования URL: Для disambiguation (устранения неоднозначности) между похожими URL система использует ключевые слова, извлеченные из контента сайта (например, из метатегов или текста).
6. Низкая актуальность для SEO: Описанные методы устарели и не отражают сложности современных поисковых систем. Патент имеет скорее историческую ценность для понимания эволюции поиска.

Практика

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

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

• Четкие и запоминающиеся URL: Хотя современные системы лучше справляются с ошибками, использование ясных, логичных и содержащих ключевые слова (включая бренд) URL-адресов облегчает их индексацию по подстрокам и улучшает навигацию для пользователей.
• Использование мета-информации: Патент упоминает извлечение ключевых слов из метатегов (meta information) для понимания контента сайта. Это подтверждает важность корректного заполнения метаданных (Title, Description) основными ключевыми словами.

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

• Использование криптических или нечитаемых URL: Использование URL, состоящих из случайных символов или идентификаторов без смысловой нагрузки, усложняет их сопоставление по подстрокам и ухудшает пользовательский опыт.

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

Патент имеет исключительно историческое стратегическое значение. Он показывает, что поисковые системы (в данном случае IBM) давно рассматривали строки URL как индексируемые данные и стремились использовать персонализацию и анализ контента для улучшения навигации. Для современных SEO-стратегий этот патент не меняет понимание приоритетов Google и не влияет на долгосрочное планирование.

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

Практических примеров, применимых к современным SEO стратегиям, из этого патента извлечь нельзя, так как он описывает устаревшую инфраструктуру навигационного поиска.

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