Как Google использует теорию информации (энтропию) для автоматического определения канонических URL и игнорирования нерелевантных параметров

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

Canonical URL (Канонический URL)

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

Canonicalization Function (Функция каноникализации, C(URL))

Функция, которая преобразует входной URL в его каноническую форму. В идеале C(URL1) = C(URL2) тогда и только тогда, когда URL1 и URL2 указывают на одинаковый контент.

Conditional Entropy (Условная энтропия)

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

Fingerprint (Отпечаток контента, F или FP)

Идентификатор контента. Может быть хешем (например, MD5), полным содержимым файла или метаданными (например, значением заголовка Content-Length, полученным через HTTP HEAD запрос).

H(F|V) (Энтропия F при условии V)

Метрика $H(F|V)$. Измеряет неопределенность того, какой контент (F) будет получен, если известно значение параметра (V). Высокое значение предполагает нерелевантность параметра.

H(V|F) (Энтропия V при условии F)

Метрика $H(V|F)$. Измеряет неопределенность значения параметра (V), если контент (F) известен. Высокое значение предполагает нерелевантность параметра (например, случайные значения для одного и того же контента).

Information Content (Информационное содержание)

Мера того, насколько параметр релевантен для идентификации уникального контента. Определяется на основе расчетов условной энтропии.

Irrelevant/Relevant Parameter (Нерелевантный/Релевантный параметр)

Классификация параметра. Нерелевантные параметры (например, трекинг) игнорируются при каноникализации. Релевантные (например, ID продукта) сохраняются. Важно отличать от Необходимых (Necessary) параметров, которые могут требоваться для доступа к контенту, но не влияют на его идентификацию.

Parameter Tuple (Кортеж параметров)

Группа из двух или более параметров, рассматриваемых вместе для определения их совместной релевантности.

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

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

1. Система получает множество URL с параметрами и идентифицирует отпечатки (fingerprints) соответствующего контента.
2. Вычисляется первая энтропия $H(F|V)$ (энтропия отпечатков при условии значений первого параметра).
3. Вычисляется вторая энтропия $H(V|F)$ (энтропия значений первого параметра при условии отпечатков).
4. На основе значений первой и второй энтропии определяется, что первый параметр нерелевантен для идентификации уникального контента.
5. На основе этого определения формируются и сохраняются канонические URL.

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

Claim 2 и 4 (Зависимые): Уточняют критерии классификации.

Claim 2 определяет нерелевантность: если $H(F|V)$ и $H(V|F)$ превышают соответствующие пороговые уровни.
Claim 4 определяет релевантность: если $H(F|V)$ и $H(V|F)$ ниже соответствующих пороговых уровней.

Claim 8 (Независимый пункт): Описывает процесс классификации параметров на уровне хоста.

1. Получение множества URL для определенного хоста.
2. Определение information content параметров на основе $H(F|V)$ и $H(V|F)$.
3. Определение наборов релевантных и нерелевантных параметров.
4. Определение и сохранение канонических URL на основе этой классификации.

Claim 16 (Зависимый от 8): Описывает процесс активного тестирования (верификации) гипотезы о нерелевантности.

1. Берется URL с параметром, определенным как нерелевантный. Получается его отпечаток (F1).
2. Генерируется тестовый URL без этого параметра. Получается его отпечаток (F2).
3. F1 и F2 сравниваются.
4. Определение нерелевантности уточняется (refining) на основе сравнения (если F1=F2, гипотеза подтверждается).

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

Изобретение является ключевым компонентом систем сканирования и индексирования.

CRAWLING – Сканирование и Сбор данных
Основной этап применения. Web Crawler использует этот механизм для оптимизации краулингового бюджета. При обнаружении нового URL он каноникализируется "на лету" с использованием выведенных правил (Claim 9). Если каноническая версия уже известна, загрузка пропускается. Также краулер используется для активного тестирования правил (Claim 16).

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит обучение системы (генерация правил). Analysis Module в офлайн (пакетном) режиме анализирует данные, собранные краулером (URL и fingerprints), вычисляет энтропию и генерирует правила каноникализации. Также на этом этапе определяется финальный канонический URL для контента в индексе, на который консолидируются все сигналы.

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

• Корпус URL, полученных в результате краулинга.
• Отпечатки контента (Fingerprints), соответствующего этим URL.
• (Опционально) Эвристические правила и предопределенные списки параметров.

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

• Набор правил каноникализации (специфичных для хоста/пути или глобальных).
• База данных канонических URL.
• Решение о необходимости скачивания конкретного URL.

На что влияет

• Структуры URL и сайты: Сильно влияет на сайты, генерирующие большое количество параметров: E-commerce (фасеты, сортировки, трекинг), форумы (session IDs), UGC-платформы.
• Типы контента: Влияет на все типы контента, но особенно подчеркивается важность для ресурсов с высоким потреблением трафика, таких как видеофайлы.
• Компоненты URL: Метод применяется не только к параметрам запроса (query parameters), но также может анализировать компоненты пути (path components) и префиксы хоста (например, www1 vs www2) (Claim 7, 14, 15).

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

• Триггеры активации (Обучение): Анализ запускается при накоплении достаточного количества данных для конкретного хоста или кластера хост/путь для статистически значимого расчета энтропии. Если данных мало, правила могут не генерироваться.
• Триггеры активации (Применение): Правила применяются в реальном времени каждый раз, когда краулер обнаруживает новый URL.
• Активное тестирование (Refinement): Применяется, когда уверенность в релевантности параметра невысока (например, вероятность находится в диапазоне неопределенности 10%-90%) или для периодической валидации существующих правил.

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

Процесс А: Генерация правил каноникализации (Офлайн-анализ)

1. Сбор и кластеризация данных: Получение множества URL и их отпечатков (F). Группировка по хосту или хосту/пути.
2. Расчет информационного содержания: Для каждого параметра (V) в кластере вычисление условных энтропий $H(F|V)$ и $H(V|F)$.
3. Определение релевантности: Сравнение энтропий с порогами. Если обе ниже порогов, параметр релевантен. Иначе – нерелевантен.
4. Анализ кортежей (Tuples) (Опционально): Анализ комбинаций параметров (особенно нерелевантных по отдельности) для выявления совместной релевантности. Если кортеж релевантен, все его компоненты признаются релевантными.
5. Анализ чувствительности к регистру (Опционально): Вычисление $H(F|lower(V)) - H(F|V)$. Если разница выше порога, регистр важен.
6. Слияние и разрешение конфликтов: Агрегация правил для хоста, разрешение конфликтов между разными путями и комбинирование с эвристическими правилами (например, сортировка параметров).
7. Сохранение правил: Сохранение финального набора правил (например, ACCEPT/IGNORE).

Процесс Б: Применение правил при сканировании (Онлайн)

1. Обнаружение URL: Краулер находит новый URL.
2. Каноникализация: Применение сохраненных правил к URL (отбрасывание нерелевантных параметров, нормализация регистра, сортировка релевантных параметров). Обработка вложенных URL в параметрах.
3. Сравнение: Поиск полученного канонического URL в базе данных.
4. Принятие решения: Если совпадение найдено, скачивание не производится. Если нет – контент скачивается, индексируется, канонический URL сохраняется.

Процесс В: Активное тестирование (Уточнение)

1. Выбор кандидата: Выбор URL с параметром, который был определен как нерелевантный.
2. Генерация тестового URL: Создание копии URL без этого параметра.
3. Получение и сравнение отпечатков: Получение отпечатков оригинального и тестового URL (например, через HTTP HEAD или GET).
4. Уточнение правила: Если отпечатки совпадают, нерелевантность подтверждается. Если отличаются, правило корректируется.

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

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

Система использует структурные и технические данные, связанные с URL и контентом.

• Структурные факторы (URL):
  • Host (Хост) и префиксы: Используются для кластеризации. Префиксы (www1, m) также анализируются на релевантность.
  • Path (Путь): Компоненты пути могут анализироваться как параметры.
  • Query Parameters (Параметры запроса): Основной объект анализа (имена, значения, порядок, регистр, вложенные URL).
• Технические факторы (Контент):
  • Content Fingerprints (Отпечатки контента): Хэш-сумма файла (например, MD5). Критически важны для определения уникальности контента.
  • HTTP Headers: Значения HTTP-заголовков (например, Content-Length), полученные через HTTP HEAD запрос, могут использоваться как легковесные отпечатки.
• Системные данные (Heuristics): Предопределенные списки универсально релевантных или нерелевантных параметров (например, "sessionid").

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

Ключевые метрики основаны на теории информации.

• Условная энтропия (Conditional Entropy): Рассчитывается по стандартной формуле теории информации, где вероятности вычисляются на основе частоты встречаемости значений и отпечатков в анализируемом корпусе данных.
• $H(F|V)$: Измеряет, насколько хорошо значение параметра предсказывает контент.
• $H(V|F)$: Измеряет, насколько случайно значение параметра относительно контента.
• Пороговые значения энтропии: Используются для классификации. Параметр релевантен, если обе энтропии ниже порогов (например, 0.5 бит).
• Метрика чувствительности к регистру: $H(F|lower(V)) - H(F|V)$. Измеряет прирост информации при учете регистра.
• Байесовская вероятность (Bayesian Probability): Патент упоминает возможность использования теоремы Байеса для комбинирования результатов энтропии, эвристик и фиксированных списков для определения итоговой вероятности релевантности.

1. Автоматизированная каноникализация на основе данных: Патент описывает мощный механизм, позволяющий Google автоматически выводить правила каноникализации для конкретных сайтов на основе статистического анализа (теории информации), а не полагаться только на ручные правила или сигналы вебмастеров (rel=canonical).
2. Энтропия как мера важности параметра: Ключевым является использование условной энтропии ($H(F|V)$ и $H(V|F)$) для оценки влияния параметра на уникальность контента. Это позволяет точно отличать параметры, идентифицирующие контент (product_id), от "мусорных" (session_id).
3. Комплексный анализ URL: Система анализирует не только отдельные параметры запроса, но и их комбинации (tuples), чувствительность к регистру, а также другие части URL, такие как компоненты пути и префиксы хоста.
4. Активная верификация и адаптивность: Система включает механизм активного тестирования (refinement) гипотез о нерелевантности параметров, что позволяет ей проверять свои выводы и адаптироваться к изменениям на сайтах.
5. Релевантность vs Необходимость: Патент четко разделяет параметры, релевантные для идентификации контента, и параметры, необходимые для доступа к нему (например, авторизация). Система каноникализации фокусируется только на первых.
6. Важность консистентности для SEO: Для корректной работы таких систем критически важна консистентность со стороны веб-сервера. Непоследовательное использование параметров может привести к ошибкам каноникализации.

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

• Обеспечение консистентности URL и контента: Убедитесь, что параметры, идентифицирующие контент, используются последовательно. Это помогает системе корректно рассчитать низкую энтропию. Также убедитесь, что URL с нерелевантными параметрами (UTM, session ID) возвращают контент, абсолютно идентичный канонической версии.
• Стандартизация порядка и регистра параметров: Рекомендуется на стороне сервера принудительно использовать нижний регистр и соблюдать фиксированный (например, алфавитный) порядок параметров. Это упрощает анализ для Google и снижает вероятность ошибок каноникализации.
• Использование чистых и стабильных URL: По возможности избегайте включения в URL параметров, которые часто меняются, но не влияют на контент. Это позволяет системе легко идентифицировать их как нерелевантные (высокая энтропия $H(V|F)$).
• Проверка доступности без параметров: Убедитесь, что контент доступен, если из URL удалить все нерелевантные параметры. Это имитирует процесс активного тестирования Google (Claim 16) и подтверждает правильность структуры.
• Управление фасетной навигацией (Tuples): При проектировании фасетной навигации убедитесь, что комбинации фильтров (кортежи параметров) последовательно ведут к уникальному набору результатов. Система способна распознавать такие комбинации как релевантные.
• Корректная обработка HTTP HEAD запросов: Убедитесь, что сервер корректно отвечает на HTTP HEAD запросы и возвращает точные заголовки (например, Content-Length). Патент упоминает возможность использования этих данных в качестве легковесных fingerprints.

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

• Изменение контента на основе нерелевантных параметров: Критическая ошибка. Если вы вставляете ID сессии или трекинг-код в тело HTML-документа (например, в ссылки или текст), это меняет отпечаток контента (Fingerprint). Система увидит корреляцию и ошибочно классифицирует нерелевантный параметр как релевантный, что приведет к массовому дублированию в индексе.
• Непоследовательное изменение контента: Если URL с одним и тем же значением параметра иногда возвращает разный контент (например, из-за некорректного A/B тестирования). Это создает высокую энтропию $H(F|V)$ и ведет к ошибкам.
• Блокировка доступа к URL с параметрами через robots.txt: Если заблокировать сканирование URL с "мусорными" параметрами, система не сможет собрать данные для анализа энтропии и не научится игнорировать эти параметры. Это может привести к проблемам с обнаружением контента по ссылкам, содержащим эти параметры.
• Смешивание релевантных и нерелевантных данных в пути (Path): Использование структур вида /session-id-12345/product/ вместо /product/?sid=12345. Хотя система может анализировать путь, отделение нерелевантных данных в параметры запроса упрощает их идентификацию.

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

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

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

Сценарий: Анализ параметров E-commerce сайта

Ситуация: Сайт использует параметры для ID товара (релевантный) и ID партнера (нерелевантный).

Анализируемые URL:

1. /item?id=123&affid=A (Отпечаток: FP1)
2. /item?id=123&affid=B (Отпечаток: FP1)
3. /item?id=456&affid=A (Отпечаток: FP2)

Анализ параметра 'id':

• $H(F|V)$: Низкая. Значение '123' ведет к FP1, '456' ведет к FP2. Контент предсказуем.
• $H(V|F)$: Низкая. FP1 всегда имеет '123', FP2 всегда имеет '456'. Значение предсказуемо.
• Результат: Параметр 'id' релевантен.

Анализ параметра 'affid':

• $H(F|V)$: Умеренная. Значение 'A' ведет к FP1 или FP2.
• $H(V|F)$: Высокая. При известном FP1 значение 'affid' может быть 'A' или 'B'. Неопределенность высокая.
• Результат: Параметр 'affid' нерелевантен.

Итог: Система генерирует правило: ИГНОРИРОВАТЬ 'affid', ПРИНЯТЬ 'id'. Когда краулер находит /item?id=123&affid=Z, он каноникализирует его в /item?id=123 и не скачивает контент, если он уже в индексе.