Как Google автоматически определяет и удаляет неважные URL-параметры для каноникализации и эффективного сканирования

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

Approximately the same content (Приблизительно тот же контент)

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

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

Предпочтительная версия URL. В контексте патента — это самая короткая версия URL (с минимальным количеством параметров), которая возвращает тот же контент, что и исходный URL.

Fetch Bot (Бот-загрузчик)

Компонент краулера (Spider), отвечающий за загрузку контента по заданным URL.

Parameter (Параметр)

Часть строки запроса URL (обычно после символа '?'), состоящая из ключа и значения. Система анализирует комбинации параметров.

Promiscuous Crawl («Неразборчивое» сканирование)

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

Required Parameter (Необходимый параметр)

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

Rewrite Component (Компонент перезаписи)

Модуль в составе Spider, который генерирует Rewrite Rules и применяет их для преобразования URL в каноническую форму.

Rewrite Rule (Правило перезаписи)

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

Similarity Hash (Хеш подобия)

Упомянутый в патенте метод для определения того, являются ли два документа «приблизительно одинаковыми».

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

Патент содержит два основных независимых блока утверждений: один описывает процесс генерации правил (Claim 1), а другой — процесс применения этих правил (Claim 7).

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

1. Система получает первый URL, включающий один или несколько параметров, и извлекает его контент.
2. Система генерирует набор различных комбинаций (подмножеств) параметров из исходного URL.
3. Извлекается контент для URL, содержащих эти различные комбинации параметров.
4. Проводится сравнение контента исходного URL с контентом, полученным по URL с комбинациями параметров.
5. Идентифицируется комбинация параметров, которая приводит к получению контента, «приблизительно такого же» (approximately the same), как у первого URL, и которая содержит сокращенное число параметров.
6. На основе этой идентифицированной комбинации генерируется одно или несколько правил перезаписи URL (URL rewrite rules).

Ядром изобретения является автоматическое определение важности параметров путем активного запроса (пробинга) сервера и сравнения результатов.

Claim 5 (Зависимый от 1): Уточняет критерий выбора канонической версии.

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

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

1. Система получает URL, который ссылается на контент и содержит набор параметров.
2. Применяется заранее определенное правило перезаписи (predetermined rewrite rule).
3. Правило удаляет из URL те параметры, которые (как было определено ранее путем сравнения контента) не влияют на контент, на который ссылается URL.
4. Переписанный URL выводится как каноническая форма (canonical form) исходного URL.

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

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

CRAWLING – Сканирование и Сбор данных
Это основная область применения патента. Механизм работает внутри краулера (Spider).

Процесс генерации правил:

• Система выполняет Promiscuous Crawl, собирая множество динамических URL с различными комбинациями параметров.
• Затем Rewrite Component инициирует активное зондирование (Active Probing): Fetch Bots многократно запрашивают вариации URL для тестирования параметров.

Процесс применения правил:

• Во время стандартного сканирования из загруженных документов извлекаются URL.
• Rewrite Component применяет сгенерированные Rewrite Rules.
• Полученные Canonical URLs передаются в URL Manager для планирования дальнейшего сканирования. Это оптимизирует краулинговый бюджет, предотвращая загрузку дубликатов.

INDEXING – Индексирование и извлечение признаков
На этапе индексирования система использует Canonical URLs, полученные на этапе CRAWLING. Это предотвращает появление дубликатов в индексе и позволяет консолидировать все сигналы ранжирования (например, ссылки) на едином каноническом адресе.

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

• Набор URL с одного хоста, содержащих параметры.
• Контент, полученный в ответ на запросы этих URL и их вариаций.

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

• Набор Rewrite Rules, специфичных для сайта или шаблона URL.
• Преобразованные Canonical URLs во время сканирования.

На что влияет

• Конкретные типы контента и ниши: Наибольшее влияние оказывается на крупные динамические сайты:
  • E-commerce и маркетплейсы: Обработка фильтров, сортировок, параметров отслеживания (UTM-метки, аффилиатные коды), идентификаторов сессий.
  • Форумы и UGC-платформы: Обработка параметров просмотра тем, идентификаторов сессий.
  • Новостные сайты: Обработка реферальных кодов и систем аналитики.
• Технические факторы: Влияет на сайты, использующие строки запроса (query strings) для управления отображением контента.

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

• Генерация правил: Происходит периодически или по мере накопления достаточного количества данных о новом сайте или новой структуре URL (обнаруженных через Promiscuous Crawl). Это ресурсоемкий процесс.
• Применение правил: Происходит в реальном времени каждый раз, когда краулер извлекает новый URL во время сканирования.
• Пороговые значения: Для генерации правила необходимо собрать предопределенное количество образцов URL (например, 5) с определенной комбинацией параметров. Параметр считается «обязательным», если он присутствует в пороговом количестве (например, 4 из 5) канонических версий, найденных в ходе тестирования.

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

Процесс А: Автоматическая генерация правил перезаписи (Обучение)

1. Сбор данных (Gathering): Система собирает набор URL с определенного хоста, используя Promiscuous Crawl с фокусом на обнаружении новых комбинаций параметров.
2. Выбор комбинации параметров (Selection): Выбирается конкретная комбинация параметров (например, paramA и paramB), которая часто встречается в собранных данных.
3. Формирование выборки (Sampling): Из собранных URL отбирается предопределенное количество образцов (например, 5 различных URL), содержащих выбранную комбинацию.
4. Итеративное тестирование образцов (Probing & Comparison): Для каждого URL из выборки:
   1. Загрузка документа с полным набором параметров (эталон).
   2. Загрузка документа со всеми возможными подмножествами параметров (без параметров, только А, только B, A и B и т.д.).
   3. Сравнение контента вариаций с эталоном с использованием Similarity Hash.
   4. Выбор самой короткой версии URL (с минимальным количеством параметров), которая возвращает approximately the same content. Она помечается как локальный Canonical URL для данного образца.
5. Агрегация результатов (Aggregation): Анализируются все полученные локальные Canonical URLs из выборки.
6. Идентификация необходимых параметров (Identification): Если параметр присутствует в пороговом количестве канонических URL (например, в 4 из 5), он помечается как «Необходимый» (Required).
7. Генерация правила (Rule Generation): Создается Rewrite Rule для данного хоста и исходной комбинации параметров. Правило предписывает перезаписывать URL, оставляя только Required Parameters и удаляя все остальные.

Процесс Б: Применение правил (Краулинг)

1. Обнаружение URL: Краулер извлекает ссылку из документа.
2. Применение правил: Rewrite Component проверяет наличие подходящих Rewrite Rules.
3. Каноникализация: Если правило найдено, URL перезаписывается (удаляются неважные параметры).
4. Планирование: Канонический URL передается в URL Manager для добавления в очередь на сканирование.

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

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

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

• Технические факторы: URL-структура, включая хост, путь (path) и строку запроса (query string). Система группирует URL и применяет правила на уровне хоста.
• Структурные факторы (URL): Параметры (ключи) и их значения в строке запроса. Анализируются наличие и комбинации параметров.
• Контентные факторы: Полное содержание документа (веб-страницы), полученное при запросе URL. Это используется исключительно для сравнения версий.

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

• Схожесть контента (Content Similarity): Ключевая метрика для определения approximately the same content. Рассчитывается путем сравнения документов, например, с помощью Similarity Hash. Это позволяет игнорировать незначительные изменения в контенте (реклама, счетчики).
• Минимальное количество параметров (Minimum number of parameters): Критерий для выбора канонической версии. Предпочтение отдается самой короткой версии URL.
• Размер выборки (Sample Size): Предопределенное количество URL (например, 5), используемых для тестирования определенной комбинации параметров.
• Порог для необходимого параметра (Threshold for Required Parameter): Статистический порог для генерации правила. Параметр считается необходимым, если он присутствует в значительном большинстве (например, >80% или 4 из 5) канонических URL, определенных в выборке.

1. Активная каноникализация через пробинг: Google не полагается пассивно на сигналы от вебмастеров. Система активно зондирует (Active Probing) веб-серверы, чтобы алгоритмически определить, как обрабатывать параметры URL, путем тестирования и сравнения ответов.
2. Контент определяет каноничность: Решение о том, является ли параметр необходимым, принимается исключительно на основе того, меняется ли контент при его удалении. Структура URL вторична.
3. Агрессивное сокращение URL: Система стремится найти самую короткую возможную версию URL (minimum number of parameters), которая представляет контент. Это подтверждает стратегию Google по минимизации индекса и оптимизации сканирования.
4. Толерантность к шуму (Approximate Matching): Использование Similarity Hash и концепции «приблизительно того же контента» критически важно. Это позволяет системе игнорировать незначительные изменения на странице (реклама, счетчики, временные метки) и фокусироваться на основном содержании.
5. Специфичность правил для хоста: Правила генерируются на основе анализа конкретного хоста. Система признает, что один и тот же параметр может быть критически важным на одном сайте и избыточным на другом.

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

• Обеспечение Graceful Degradation параметров: Критически важно, чтобы веб-сервер корректно обрабатывал запросы при удалении неважных параметров (UTM-метки, session ID). Их удаление не должно приводить к ошибке (404, 500) или изменению основного контента. Это позволит системе Google корректно обучиться и сгенерировать Rewrite Rules.
• Четкая дифференциация полезного контента: Если параметр должен изменять контент (например, фильтр товара или пагинация), убедитесь, что изменения контента достаточно существенны (т.е. меняется основной контент, а не только порядок элементов), чтобы Similarity Hash не классифицировал их как дубликаты.
• Поддержание стабильности и скорости сервера: Процесс генерации правил (Active Probing) создает дополнительную нагрузку на сервер, так как система активно запрашивает множество вариаций URL. Медленные ответы или ошибки сервера могут помешать системе корректно проанализировать структуру сайта.
• Использование явных сигналов каноникализации: Внедрение rel=canonical на всех страницах остается лучшей практикой. Это снижает зависимость Google от ресурсоемкого механизма активного пробинга и страхует от ошибок автоматического определения правил.
• Консистентность структуры URL: Поддержание консистентности в порядке параметров на всем сайте облегчает системе процесс обучения и снижает вероятность ошибок каноникализации.

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

• Возврат ошибок при отсутствии необязательных параметров: Если сервер возвращает ошибку 404 или 500, когда Google тестирует URL без session ID, система сделает вывод, что session ID является обязательным параметром (Required Parameter), что приведет к индексации дубликатов.
• Использование параметров для минимальных изменений: Не используйте разные параметры URL для отображения контента, который лишь незначительно отличается. Система может посчитать эти версии дубликатами и канонизировать их на одну версию.
• Блокировка сканирования параметров через Robots.txt (Устаревшая практика): Блокировка URL с параметрами может помешать Google как обнаружить контент, так и изучить правила перезаписи. Если параметры неважные, лучше позволить сканирование и полагаться на каноникализацию.
• Генерация нестабильного контента: Избегайте чрезмерной рандомизации блоков контента. Если контент будет слишком сильно отличаться при каждой загрузке, система не сможет установить эквивалентность URL с помощью similarity hash.

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

Этот патент подчеркивает фундаментальную важность технического SEO и чистой архитектуры сайта. Он демонстрирует, насколько серьезно Google подходит к проблеме эффективности сканирования и борьбы с дубликатами. Для Senior SEO-специалистов это подтверждает, что управление URL-параметрами, особенно в сложных системах, таких как фасетная навигация в e-commerce, является критическим требованием для успешного индексирования и ранжирования. Понимание механизма Active Probing позволяет лучше диагностировать сложные проблемы каноникализации.

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

Сценарий: Определение канонического URL для страницы товара в E-commerce

Сайт генерирует сложные URL для отслеживания источников трафика и сессий.

1. Исходный URL (Образец): /product.asp?id=123&session=XYZ&ref=email
2. Комбинация параметров: id, session, ref.
3. Активное тестирование (Probing): Система запрашивает:
   • /product.asp?id=123&session=XYZ&ref=email (Эталон)
   • /product.asp?
   • /product.asp?id=123
   • /product.asp?session=XYZ
   • (и другие комбинации)
4. Сравнение контента:
   • Система обнаруживает, что /product.asp? возвращает главную страницу (Не совпадает).
   • Система обнаруживает, что /product.asp?id=123 возвращает тот же товар, что и эталон (Совпадает).
   • Система обнаруживает, что /product.asp?session=XYZ возвращает ошибку или главную страницу (Не совпадает).
5. Определение Канонической версии: Самый короткий URL, вернувший совпадение — /product.asp?id=123.
6. Генерация правила (После анализа выборки): Система подтверждает, что id является необходимым параметром, а session и ref — нет. Создается правило: "На этом сайте для URL по шаблону /product.asp удалять параметры session и ref".