Как Google использует "Адаптеры" для сканирования и индексирования закрытых (не-веб) источников данных

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

Adaptor (Адаптер)

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

Closed File Source / File Source (Закрытый источник файлов)

Репозиторий контента (например, база данных, система управления документами, сетевая файловая система), который недоступен для веб-краулера напрямую.

File Identifier (Идентификатор файла)

Уникальный ключ для доступа к элементу данных внутри источника. Это может быть путь к файлу (S:/MyDocuments/Doc1.txt) или первичный ключ записи в базе данных (myco.address.123456789HOM).

Lister (Листер)

Компонент адаптера, который запрашивает у источника и предоставляет адаптеру список идентификаторов файлов.

Retriever (Ретривер)

Компонент адаптера, который извлекает содержимое файла (контент) из источника по заданному идентификатору.

Seed URL (Начальный URL)

Специальный URL, предоставляемый поисковой системе. Запрос к этому URL запускает процесс обнаружения файлов. В ответ адаптер возвращает список сгенерированных URL в виде ссылок.

Security Module (Модуль безопасности)

Опциональный компонент для проверки прав доступа пользователя (авторизации) к запрашиваемому контенту перед его выдачей.

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

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

1. Система (адаптер) получает идентификаторы файлов из источника, недоступного для веб-краулера.
2. Генерирует HTTP-совместимый URL для каждого идентификатора (преобразуя несовместимые идентификаторы в совместимые URL).
3. Предоставляет эти URL поисковой системе без соответствующего контента.
4. Получает запрос от поисковой системы на получение контента по конкретному URL.
5. Конвертирует URL обратно в идентификатор файла.
6. Получает контент из источника, используя этот идентификатор.
7. Конвертирует контент в HTTP-ответ.
8. Предоставляет HTTP-ответ поисковой системе.

Claim 7 (Зависимый от 1): Описывает альтернативный метод обнаружения контента через Seed URL (метод обнаружения ссылок).

1. Адаптер предоставляет Seed URL поисковой системе.
2. Адаптер получает запрос на контент по этому Seed URL.
3. В ответ на этот запрос адаптер получает идентификаторы файлов (вместо того, чтобы получать их заранее).
4. Предоставление URL поисковой системе осуществляется путем включения сгенерированных URL в виде ссылок (links) в HTTP-ответ на запрос Seed URL.

Claim 13 (Независимый пункт): Описывает систему, реализующую метод.

Система включает:

• Модуль Lister для получения идентификаторов.
• Модуль Retriever для получения контента.
• Модуль Adaptor, который вызывает Lister, генерирует URL (включая доменную часть, указывающую на веб-сервер адаптера) и предоставляет эти URL поисковой системе без контента. Адаптер также обрабатывает входящие запросы, вызывает Retriever и возвращает контент в виде веб-ответа.

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

Патент описывает инфраструктуру, обеспечивающую работу этапа CRAWLING – Сканирование и Сбор данных.

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

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

• Adaptor взаимодействует с Search Engine через стандартный протокол HTTP, эмулируя веб-сервер.
• Adaptor взаимодействует с Closed File Source через специфичные для источника протоколы (например, SQL для баз данных) с помощью модулей Lister и Retriever.

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

• От File Source: Идентификаторы файлов (File Identifiers) и контент.
• От Search Engine: HTTP-запросы на сканирование сгенерированных URL или Seed URL.

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

• Для Search Engine: Список сгенерированных URL (переданный через фид или в виде ссылок).
• Для Search Engine: Стандартные HTTP-ответы, содержащие контент файлов или коды ошибок (404, 401/403).

На что влияет

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

• Конкретные типы контента: Записи в базах данных (упоминаются как table rows), документы в системах документооборота (DMS), файлы на сетевых дисках.

Патент не влияет на ранжирование в публичном веб-поиске Google.com.

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

Алгоритм применяется в сценариях Enterprise Search, когда организации необходимо сделать внутренние данные (не имеющие веб-интерфейса) доступными для поиска через стандартную поисковую систему.

• Триггеры активации: Процесс активируется либо по расписанию (запуск Lister для получения новых идентификаторов), либо при сканировании поисковой системой Seed URL. Последующие запросы контента контролируются поисковой системой (Claim 2).

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

В патенте описано два основных варианта работы системы.

Вариант 1: Прямая передача URL (Feed-based Discovery, с использованием Lister)

1. Получение идентификаторов: Адаптер (по расписанию) запускает модуль Lister для извлечения списка File Identifiers из закрытого источника.
2. Генерация URL: Адаптер создает уникальный, валидный URL для каждого идентификатора (например, используя percent encoding). Доменная часть URL указывает на веб-сервер адаптера.
3. Передача URL (Feed): Адаптер передает сгенерированные URL поисковой системе (например, через Feeder API). Контент не передается.
4. Планирование сканирования: Поисковая система добавляет URL в свой список сканирования (Crawl List).
5. Запрос контента (Crawl): Поисковая система (асинхронно) отправляет HTTP-запрос на сканирование конкретного URL адаптеру.
6. Обработка запроса: Адаптер конвертирует URL обратно в исходный File Identifier.
7. Извлечение контента: Адаптер запускает модуль Retriever для получения актуального контента по идентификатору из источника.
8. Форматирование ответа: Адаптер преобразует полученный контент в валидный HTTP-ответ (например, создает HTML или XML документ из данных БД).
9. Отправка ответа: Адаптер отправляет HTTP-ответ поисковой системе для индексации.

Вариант 2: Обнаружение через Seed URL (Crawl-based Discovery, без Lister)

1. Запрос Seed URL: Поисковая система сканирует заранее предоставленный Seed URL, отправляя запрос адаптеру.
2. Обработка запроса: Адаптер распознает Seed URL и запускает Retriever.
3. Получение идентификаторов (Seed File): Retriever возвращает список File Identifiers (возможно, порциями).
4. Генерация URL и Ответа: Адаптер генерирует URL для полученных идентификаторов и создает HTTP-ответ (например, HTML-страницу), содержащий эти URL в виде гиперссылок (теги <A HREF=...> или <link href=...>).
5. Отправка ответа: Адаптер отправляет этот ответ поисковой системе.
6. Обнаружение ссылок: Поисковая система парсит ответ, находит ссылки и добавляет их в Crawl List.
7. Последующее сканирование: Далее процесс повторяет шаги 5-9 из Варианта 1 для каждого обнаруженного URL.

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

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

Патент фокусируется на инфраструктуре доступа к данным, а не на их анализе для ранжирования.

• Технические факторы:
  • URL-структура: Генерируется адаптером для маршрутизации запросов и идентификации файла.
  • Код ответа: Адаптер генерирует стандартные HTTP-коды (200 OK, 404 Not Found, 401 Unauthorized/403 Forbidden).
• Системные данные (Внутренние):
  • File Identifiers: Ключевые данные для доступа к контенту (пути к файлам, первичные ключи баз данных).
• Контентные факторы:
  • Содержимое файлов: Извлекается из источника модулем Retriever.
  • Метаданные: Могут извлекаться из источника и включаться в HTTP-ответ.

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

Патент не описывает никаких метрик для ранжирования или оценки качества контента.

• Методы трансформации:
  • URL Encoding: Используется для преобразования File Identifiers в валидные URL (упоминается percent encoding согласно RFC3986).
  • Data Transformation: Используется для преобразования извлеченного контента в стандартный веб-формат. Например, преобразование записи базы данных в XML или HTML документ.

Патент описывает внутренние технические процессы Google (в контексте Enterprise Search) без прямых рекомендаций для SEO публичных сайтов.

1. Инфраструктурное решение для Enterprise Search: Патент детально описывает архитектуру «Коннекторов» или «Адаптеров», которые используются для индексации корпоративных данных, недоступных через веб (базы данных, файловые системы).
2. Имитация веб-ресурсов: Основная идея — заставить закрытый источник выглядеть как обычный веб-сайт для стандартного краулера. Это достигается путем генерации уникальных URL и предоставления контента через стандартный HTTP-протокол.
3. Переход от "Push" к "Pull": Система позволяет заменить модель принудительной отправки контента в индекс ("Push") на модель сканирования по запросу ("Pull"/Crawl). Это дает поисковой системе контроль над нагрузкой, планированием и частотой обновления данных в индексе.
4. Разделение обнаружения и извлечения: Система разделяет процесс получения URL (Discovery) и процесс загрузки контента (Crawling). URL могут быть переданы быстро, а контент загружается позже, по запросу.
5. Отсутствие значимости для публичного SEO: Патент не содержит информации об алгоритмах ранжирования, факторах качества или методах оптимизации для публичного поиска Google.com. Он не имеет практической ценности для SEO-специалистов, занимающихся продвижением веб-сайтов.

ВАЖНОЕ ЗАМЕЧАНИЕ: Патент является инфраструктурным и описывает технологии Enterprise Search (корпоративного поиска). Он не дает практических выводов или рекомендаций для публичного SEO.

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

Не применимо для публичного SEO.

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

Не применимо для публичного SEO.

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

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

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

Практических примеров для публичного SEO нет. Ниже приведен пример из области Enterprise Search для иллюстрации работы механизма.

Сценарий: Индексация базы данных сотрудников

1. Источник: Внутренняя SQL-база данных EmployeesDB с таблицей Profiles.
2. Идентификатор: Первичный ключ EmpID (например, "E12345").
3. Работа Адаптера:
   • Lister извлекает все EmpID.
   • Адаптер генерирует URL: http://adaptor.intranet/EmployeesDB/Profiles/E12345.
   • Адаптер отправляет этот URL в корпоративную поисковую систему.
4. Сканирование: Поисковая система отправляет HTTP GET запрос на этот URL.
5. Извлечение и Ответ:
   • Адаптер получает запрос, извлекает EmpID "E12345".
   • Retriever выполняет SQL-запрос к базе данных для получения записи.
   • Адаптер форматирует результат (Имя, Должность, Контакты) в HTML-страницу.
   • Адаптер возвращает HTML-страницу поисковой системе.
6. Результат: Данные сотрудника проиндексированы и доступны для поиска во внутреннем поиске компании.