Как Google анализирует веб-формы и фильтры для эффективного сканирования «Глубокого интернета» (Deep Web)

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

Deep Web / Hidden Web (Глубокий / Скрытый Интернет)

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

Difference Determination (Определение различий)

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

Form Page (Страница формы)

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

Indexing Record (Запись индексирования)

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

Informative (Информативный)

Характеристика элемента управления вводом (или их комбинации). Элемент считается информативным, если изменение его значения приводит к получению целевых страниц, удовлетворяющих Predefined Difference Standard (т.е. генерирует существенно разный контент).

Input Control (Элемент управления вводом)

Поле ввода на странице формы (например, текстовое поле, выпадающий список, радиокнопка).

Predefined Difference Standard (Предопределенный стандарт различий)

Критерий для определения того, являются ли целевые страницы достаточно разными. Например, требование, чтобы определенная доля (например, 25%) полученных страниц имела различное содержание.

Relevancy Criterion (Критерий релевантности)

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

Target Pages (Целевые страницы)

Страницы, получаемые в результате отправки формы с определенным набором значений ввода.

Tuple (Кортеж)

Комбинация нескольких элементов управления вводом (например, пара, тройка).

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

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

1. Идентификация страницы формы с несколькими элементами управления.
2. Ввод первого набора значений (включая V1 для элемента A) и получение первой целевой страницы.
3. Ввод второго набора значений (включая V2 для элемента A) и получение второй целевой страницы.
4. Выполнение первого сравнения страниц относительно Predefined Difference Standard.
5. Обновление Indexing Record.
6. [Оптимизация Шаг 1] Определение элементов, которые удовлетворяют стандарту (т.е. являются информативными).
7. [Оптимизация Шаг 2] Определение пар элементов управления так, чтобы хотя бы один элемент в каждой паре уже был определен как информативный.
8. Выполнение второго сравнения для этих определенных пар.
9. Обновление Indexing Record на основе результатов для пар.

Ядро изобретения — это итеративное тестирование информативности и использование результатов предыдущих тестов для радикального сокращения пространства поиска (избегание тестирования комбинаций, где ни один элемент не показал себя информативным).

Claim 8 (Зависимый от 1): Описывает итеративное расширение тестирования за пределы пар (Iterative Deepening).

1. Формирование кортежей (Input control tuples), путем расширения тех пар, которые были признаны информативными, еще одним элементом управления (например, до троек).
2. Выполнение третьего сравнения для этих кортежей.
3. Обновление Indexing Record.

Claim 10 (Зависимый от 9): Уточняет, как определяется различие в содержании.

Различие определяется путем извлечения слов с полученных страниц в соответствии с Relevancy Criterion. Это означает, что система фокусируется на значимом контенте, а не на незначительных изменениях HTML или шаблона.

Claim 12 (Зависимый от 1): Описывает обработку неинформативных элементов.

1. Если элемент управления идентифицирован как неинформативный (не удовлетворяет стандарту).
2. Для него выбирается значение по умолчанию (default value).
3. Это значение фиксируется в Indexing Record и используется во время сбора страниц для индексирования.

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

Изобретение находится на стыке процессов сканирования и индексирования, фокусируясь на эффективном обнаружении контента (Content Discovery) в Deep Web.

CRAWLING – Сканирование и Сбор данных
Это основная область применения. Алгоритм используется краулером или модулем обработки форм (Form Processing Module) для интеллектуальной генерации набора URL за формой. Это позволяет обнаружить контент, недоступный по прямым ссылкам, и напрямую влияет на управление бюджетом сканирования (Crawl Budget Management), предотвращая сканирование дубликатов.

INDEXING – Индексирование и извлечение признаков
На этом этапе система выполняет анализ контента целевых страниц для Difference Determination. Это включает извлечение признаков (например, релевантных слов согласно Relevancy Criterion) и вычисление сигнатур страниц для сравнения их со стандартом. Результаты этого анализа определяют, какие URL будут добавлены в Indexing Record для последующего полноценного индексирования.

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

• HTML-код страницы формы (Form Page).
• Возможные значения Input Controls (извлеченные из HTML для списков или сгенерированные для текстовых полей).
• Predefined Difference Standard (системная конфигурация).

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

• Обновленный Indexing Record со списком URL целевых страниц (Target Pages), соответствующих информативным комбинациям.
• Значения по умолчанию для неинформативных элементов.

На что влияет

• Конкретные типы контента и ниши: Критично для сайтов, где контент доступен через формы поиска, фильтры или конфигураторы: E-commerce (фасетная навигация), недвижимость, авто-порталы, сайты с базами данных.
• Техническая реализация форм: Механизм лучше всего работает с традиционными HTML-формами, особенно использующими метод GET, где комбинации ввода явно формируют URL с параметрами.

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

• Триггеры активации: Алгоритм активируется, когда система обнаруживает страницу с HTML-формой, потенциально ведущую к множеству целевых страниц.
• Пороговые значения: Ключевым порогом является Predefined Difference Standard. В описании патента упоминается примерный порог: ввод считается информативным, если количество различных сигнатур веб-страниц составляет не менее 25% от общего числа сгенерированных веб-страниц.
• Исключения: Если при тестировании возникают ошибки HTML/HTTP, система может прекратить анализ, так как это указывает на недействительные комбинации или проблемы с доступностью.

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

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

1. Инициализация: Идентифицировать страницу формы и все элементы управления вводом (K). Выбрать значения по умолчанию для каждого из K элементов.
2. Тестирование индивидуальной информативности (Фаза 1):
   • Для каждого элемента управления (I):
     • Сгенерировать набор URL, перебирая значения для I, сохраняя остальные элементы (K-1) в значениях по умолчанию.
     • Получить целевые страницы (возможно, выборку).
     • Выполнить Difference Determination: вычислить сигнатуры страниц (используя Relevancy Criterion) и сравнить их со стандартом.
     • Если стандарт удовлетворен (>25% уникальных), пометить I как индивидуально информативный.
3. Инициализация Кандидатов (Фаза 2): Создать начальный набор кандидатов (Cand), состоящий из всех индивидуально информативных элементов.
4. Итеративное расширение и тестирование кортежей (Фаза 3 - Iterative Deepening):
   • Пока набор кандидатов (Cand) не пуст:
     • Расширение (NewCand): Создать новые кандидаты (кортежи большего размера), расширяя каждый кортеж в Cand дополнительными элементами управления. (Например, расширить информативную пару {A, B} до {A, B, C}).
     • Тестирование (NewCand): Для каждого нового кортежа сгенерировать URL, перебирая комбинации значений элементов в кортеже, сохраняя остальные элементы по умолчанию. Получить страницы и выполнить Difference Determination.
     • Определение информативности кортежа: Кортеж информативен, если он генерирует достаточное количество уникальных страниц, в том числе уникальных относительно уже проанализированных страниц этой формы.
     • Обновление Кандидатов: Cand становится набором кортежей из NewCand, которые были признаны информативными.
5. Финализация: Обновить Indexing Record, включив в него URL, сгенерированные всеми найденными информативными кортежами.

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

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

Система использует следующие типы данных:

• Технические факторы: HTML-код страницы формы, URL действия формы (action), типы и имена Input Controls (select, text, radio), значения ввода (извлеченные из HTML или сформулированные для текстовых полей). Коды ответа HTTP (для обнаружения ошибок).
• Контентные факторы: Содержимое полученных Target Pages. Используется для анализа уникальности.

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

• Сигнатура страницы (Page Signature): Краткое представление контента страницы, используемое для сравнения. Вычисляется путем анализа содержимого.
• Relevancy Criterion: Метод для вычисления сигнатуры путем извлечения наиболее релевантных слов, игнорируя шаблонный контент. Учитывает:
  • Частоту слов (Frequency).
  • Размещение слов (Placement, например, в заголовках).
  • Выделение слов (Emphasis, например, капитализация, подсветка).
• Predefined Difference Standard: Порог для определения информативности. Измеряется как доля различных страниц в общем наборе сгенерированных страниц. Пример порога из патента: 25%.

1. Эффективность сканирования — главный приоритет: Google не будет перебирать все комбинации форм (brute-force). Система разработана для поиска минимального набора URL, который репрезентативно покрывает уникальный контент, чтобы оптимизировать Crawl Budget.
2. Ключевое понятие — «Информативность»: Система классифицирует поля ввода (фильтры/параметры) как информативные или нет. Информативность определяется исключительно способностью поля генерировать существенно различный контент, согласно Predefined Difference Standard.
3. Оценка различий фокусируется на релевантном контенте: Система использует Relevancy Criterion для сравнения страниц, фокусируясь на значимых словах и игнорируя шаблонный текст (boilerplate). Изменения только в шаблоне не сделают элемент информативным.
4. Итеративная оптимизация пространства поиска (Iterative Deepening): Запатентован конкретный метод оптимизации: система тестирует комбинации (пары, тройки), только если их подмножества уже были признаны информативными. Это значительно сокращает количество необходимых тестов.
5. Обработка неинформативных полей: Поля, которые не генерируют различный контент (например, сортировка), помечаются как неинформативные, и для них фиксируется значение по умолчанию.

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

Рекомендации критически важны для сайтов с фасетной навигацией (E-commerce, агрегаторы).

• Обеспечение существенных различий для важных фильтров: Убедитесь, что фильтры, которые вы хотите индексировать («информативные»), генерируют страницы с действительно уникальным контентом. Различия должны быть значительными, чтобы удовлетворить Difference Standard (>25% уникальности).
• Уникализация контента целевых страниц: Используйте уникальные Title, H1 и мета-описания для страниц, сгенерированных фильтрами. Это поможет системе применить Relevancy Criterion и распознать различия в контенте.
• Использование GET для индексируемых форм: Для навигации и фильтров используйте метод GET. Это генерирует явные URL с параметрами, что упрощает анализ для поисковой системы по сравнению с POST-запросами.
• Корректная обработка ошибок и пустых результатов: Убедитесь, что валидные комбинации фильтров возвращают код 200 OK. Наличие ошибок HTML/HTTP при тестировании может привести к прекращению анализа формы системой.
• Управление неинформативными параметрами: Помогайте системе, используя canonical или robots.txt для параметров, которые не меняют контент (сортировка, ID сессии), чтобы они не тратили ресурсы на анализ.

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

• Генерация массовых дубликатов через формы/фильтры: Создание уникальных URL для фильтров, которые незначительно меняют контент. Система классифицирует их как неинформативные, потратив при этом ресурсы на анализ.
• Минимальные различия контента: Если при смене важного параметра (например, цвета товара) меняется только изображение, а текст, заголовки и характеристики остаются идентичными, система может посчитать этот параметр неинформативным.
• Использование сложных JavaScript-форм для навигации: Реализация фильтров через сложный JS без генерации уникальных, доступных для сканирования URL затрудняет применение описанного механизма.
• Использование POST для навигации по контенту: Скрытие индексируемого контента за формами POST усложняет его обнаружение и индексацию.

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

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

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

Сценарий: Оптимизация фасетной навигации интернет-магазина одежды

Магазин имеет фильтры: Категория (I), Размер (J), Цвет (K), Сортировка (L).

1. Анализ системы (Фаза 1):
   • Система тестирует L (Сортировка). Контент страниц идентичен, меняется только порядок. L признан неинформативным. Для L фиксируется значение по умолчанию.
   • Система тестирует I (Категория), J (Размер), K (Цвет). Все признаны информативными, так как существенно меняют список товаров и заголовки.
2. Анализ системы (Фаза 3):
   • Система тестирует пары (IJ, IK, JK). Все признаны информативными. (Например, «Платья Размер M» уникальны).
   • Система тестирует тройку (IJK). Признана информативной. (Например, «Красные Платья Размер M» уникальны).
3. Действия SEO-специалиста:
   • Обеспечить уникальность: Проверить, что страницы «Красные Платья Размер M» имеют уникальный H1 («Красные платья размера M») и Title, отличающийся от «Платья Размер M». Это гарантирует, что система увидит различия через Relevancy Criterion.
   • Техническая реализация: Убедиться, что фильтры реализованы через GET-запросы (/catalog?cat=dress&size=M&color=red).
4. Ожидаемый результат: Google эффективно сканирует все валидные комбинации Категория+Размер+Цвет, но не тратит ресурсы на сканирование разных вариантов сортировки для каждой из этих комбинаций.